Code versioning

Reading time: 3 minutes

Have you ever heard about code versioning? Have you ever used it for SQL projects? Do you know GIT? I hope your answer is “Yes”, because you definitely should! If we are professionals need to version our code.

At first I recommend reviewing your code management strategy. First step to code versioning is to store your source code smart on your local machine.

At second, I recommend GIT.

 
What is GIT?

“Git is free and open source software for distributed version control: tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems).”

 

Why GIT for code versioning?

  • Traceability (we can connect changes in the code to the specific item on our project board)
  • Managing changes
  • Tracking every individual change by each contributor
  • Informing other developers about new changes in the code
  • A complete history of every file
  • Concurrent work on multiple branches

 

This all leads to increased work efficiency of the team by making changes more transparent and reducing the risk of conflicts. In the beginning, using GIT may be a little complicated, it requires changing a mindset, to start thinking about every change in a code as a commit, rebase, merge, etc. When using git becomes your daily basis for code versioning, you will know that there is no way back. Using code versioning is one of the basics for every professional developer. Those tools were created to help us in our work and they do it.

 

GIT basics

A GIT repository is just a folder in your filesystem initiated as a git repo. You can do it by using the “git init” command. After initiation, GIT creates the hidden subfolder “.git” which contains metadata inside and starts to track every change made to files inside the main folder.

GIT operates in four main “spaces”:

  • Working copy – your files, modified in your local machine
  • Staging area – logical space for files prior to being sent to the repository
  • Local repository – tracked and controlled folder with files inside in your local machine
  • Remote repository – a remote copy of the repository stored on the server

 

Code Versioning

Basic GIT commands

$git init – creates a new repository in the current path

$git config – configures repository

$git clone – “download” existing repository from remote to the local machine

$git add – add modified files from the working copy to the staging area

$git commit – “save” state of files added to the staging area

$git push – “send” your branch to the remote repository

$git pull – “get” the last state of the current branch from remote to the local repository

$git checkout – switch to another branch

$git branch – manage branches (create, delete, etc.)

$git diff – show changes in files, diff can be used to compare with previous commits or another branch

$git merge – merge one branch to another

$git log – show commits history

Branching strategy for code versioning

GIT as a distributed version control system gives you big flexibility in how you use it for code versioning. When you are working in a team, you need to choose how you will share and manage code. It is called branching strategy – how and when create branches, which branch is meant for what, when merge it, when rebase it, on which branch do changes. It also contains naming conventions and security settings. It must be fit for your team and the nature of your work. For example, the branching strategy will be different for delivery teams and for support teams. It depends on many aspects, for example, if you are using CI/CD or not. It should be “crafted” for your specific use. A wisely chosen branching strategy will help you keep the orderliness in your project, help process changes in code, minimize the number of conflicts, and minimize the effort needed to keep your repository alive.

 

Conclusion

If you are not using code versioning, you should start! You can start to use it by yourself and then propagate it in your teams. Developer live is easier with code versioning. This is a very important step on a way to be a professional developer.

Facebook
Twitter
LinkedIn

Contact

Nearshore Partner means for you:

Trusted us

Contact

Ola Wojdyła

Contact

Nearshore Partner means for you:

Trusted us