What is GIT and why you need to use it
A few years ago I was introduced to Git version control. We were about to start a massive development project that would take the best part of a year and we wanted a way of working as a team, where we could split tasks between developers and work independently for a while and then easily bring everything back together (well that was the plan anyway).
We used to use SVN (subversion) for version control which seemed to work okay as long as one developer was working on one project at a time and there were no clashes (or merge conflicts) in the code. It was very useful as it provided the basic functionality of being able to roll back to a previous version if you wanted to remove an update that didn’t go as planned, but was not up to the task of having multiple developers working together on a single project, so we swapped to using Git.
The benefits of git were clear from the start. Rather than a linear version control, where the developer checks out the code, does their changes and then checks it back in again, git offers so much flexibility with branching.
Branching
When you create a repository (where you store your code, such as Github or Bitbucket) you start with a master branch. This is generally considered to be the stable version or production version of code. When you need to make a change you don’t edit this branch directly, instead you create a branch and then work on that branch, develop, test and then merge back into master when it is ready. This way, you are not affecting your production version of code until your development is completely finished.
If you have a project that many developers are working on together then you can create a branch off master and then create sub branches off that branch. This allows you to work together and test all of your sub branches together before they are merged into master.
Merging
Above, I mentioned merging a branch back into master, but didn’t really explain what merging is. Every file in your git repository is under version control. This means that any change will be identified by git, whether you add 100 lines of code, or add a missing semi-colon to a line of JavaScript.
When you come to merge your branch of code back in to master, git checks the differences between the branches and decides what will be replaced in master from the new branch. The majority of the time (well, depending on your project anyway) the changes are additive, adding new lines of code so git will let you add these new lines in no problem.
But life is not always this easy, as you can have multiple branches being worked on at the same time. This means that master could have been updated from another branch before you try and merge your changes in. This will result in a merge-conflict.
Git is clever, but it isn’t clever enough to read your code and resolve a merge conflict by itself. You have to manually resolve the merge conflict by telling which changes are needed out of the two available versions.
Pull Requests and Code Reviews
Back in the day, with SVN, you did your change and it was updated as being the latest version. This is fine if you are working on a project on your own, but its not great for other developers that need to be kept up to date on what you are doing.
Git offers you Pull Requests to announce to others what your change is before it is merged in. Rather than directly merging the branch you have been working on into master, you can create a pull request, where you can add relevant comments and add approvers. The approvers will be sent an email requesting that they review and approve (or decline) the changes.
As a reviewer, you are presented with a list of the files that have been changed and a view of the code within the files that has been changed, and you can read all the change notes provided. Provided you have permission, you can even fetch and checkout the branch on your local development environment and then test out the code yourself and report any bugs you find.
This allows other developers to review your code and encourages you to review their code as well, keeping everyone informed of changes before they are merged in.
I’ve only touched on a few of the benefits of git but hopefully you can see some of the reasons why you should use it.
