Oct 10, 2012
Table of contents:
Git is a distributed revision control and source code management system that allows you to quickly and easily track the history of a development project and collaborate with other developers without stepping on each others toes.
If you are new to the idea of revision control as a developer, all this basically means is that Git is like an invisible layer that sits in your project folder and will constantly monitor and manage your work effortlessly in the background.
This post is really aimed at people who have heard of Git, but have yet to make the leap into using it full time during their work. I can honestly say, Git is brilliant, and it will revolutionise the way you work.
So what’s the skinny on Git? Why should you use it and what are the benefits? Here are just some of the reasons and use cases for Git that will streamline and improve your workflow.
Have you ever wanted to roll back time to a previous state of your code? Git makes it easy to roll back to any version of your code so you can see exactly how something previously worked. This is also probably the best way to understand someone else’s code without actually having to speak to them. The Git log will record all the changes the developer has made in a continuous stream of consciousness that you can follow up until the current latest version. This allows you to track why the developer has made each incremental change, and it allows you to retrace their footsteps to see how they arrived at your current location.
Whilst Git is extremely beneficial whilst developing alone, the real power of Git comes to play when working with other developers. Git allows you to have a repository of code which acts as the code base for your project. Whenever someone wants to work on the project, they can just grab a copy of the repository and start working. When they have finished their work, they can then push it back to the repository to be merged back into the original copy. This allows multiple developers the ability to work on the same set of code at the same time on their own. When it comes to merging the changes back together, Git is able to merge the changes back into the original code and resolve any conflicts that may arise.
Have you ever had a brainwave overnight where you think of a potential way to refactor your code to make it better? Or perhaps you have had an idea for an experimental new feature, but you need to make a working copy of it to show your colleagues?
Git allows you to recklessly go off on a tangent when an idea strikes. You can make dramatic changes to any of the files in your project, delete them or add new files, safe in the knowledge that at any moment you can revert back to where you began.
This safety net for development allows you to experiment with new ideas without having to leave a crumb trail to get back to the previous state of your code.
Everyone knows they should be backing up their work, but it’s easy to neglect it. When you use Git you can very easily push your code to a remote repository on a Server or to a service like GitHub. This means that should your computer fail, you will still have a back up of your work.
Even better, if you are collaborating with other developers, there will be multiple copies of your code base stored on multiple different machines.
When you are developing a commercial website or online application, you don’t want to be making changes to a live site that could break something. A good setup is to have a Development site, a Staging site and a Live site. However, managing these three different versions of your codebase can be a nightmare if you just keep three separate versions of your project. What’s more, moving updates across the different environments will be time consuming and could potentially lead to errors if all the changes aren’t completely replicated. Git completely gets rid of this headache all together by allowing you to keep different versions of the environment within the same set of files.
If you’ve ever had to roll out a major change to a website or web application, you will know that it is unlikely that every updated file will be in the same directory. This means that updating through FTP can be potentially disastrous. For example, a user to your website could request a file that is depending on another file that you are about to upload.
Git allows you to deploy your changes too, so all you have to do is run a command and Git will ensure all the changes are automatically made at the same time, no matter where they occur in your files.
To fully understand how Git works, it’s important to understand the terminology that is used to describe it.
I’ll try to keep this as clear and concise as I can.
A repository is basically just a copy of a code project.
When you want to grab a copy of the a repository, you clone it, or in other words, you make a complete copy of the entire repository and save it to your local machine to work on.
When you clone a copy of a repository and begin to develop the code yourself, you are setting an alternate path for the future of the codebase, a “fork in the road”. At some point in the future you may want to submit a “pull request” to the owner of the original repository to merge your work back into the original source.
When you want to make changes to a repository, you make a new branch to work on. If you imagine that the master version of the code is the main branch, whenever you want to make changes, you would create a new branch to work on to allow you to separate your work from the clean working version of the code.
When other people are working on the same code base, you need to know when they have been changes made to the original repository. To do this you fetch all new and changed branches.
When there have been changes made to the original repository, you can pull them in to your local copy so you are working with the most up-to-date code.
When you are ready to share your changes with your colleagues or incorporate them back into the original repository, you push them.
Checkout is the term used for creating new branches or moving between existing branches.
A commit is a snapshot of your project. In order to create your timeline of changes you make a new commit whenever you complete a piece of work.
Before committing your work, you first add it to the staging area. The staging area is where you add all of the files that have changed before you commit them.
So hopefully you can see the benefit that Git can bring to your workflow. Git can seem a bit daunting at first, especially if you are not familiar with the Command Line. However it really is easy to pick up because for 90% of the time you are only using a couple of commands.
Look out for my future Git tutorials on how to use Git.
For now, I’m going to describe how you can use Git to manage an enterprise web application. Hopefully if you are not already convinced to try Git, you will be after you see how it can manage a large scale application.
As I mentioned above, when developing a web application, you need to be able to manage the different versions of the code, track new features, fix bugs and make changes without blurring the lines between these versions or accidentally shipping code that is not ready for prime time.
Git allows you to manage a complicated set up like this through the use of different branches.
Our basic Git setup is 3 infinite branches, and many finite branches. Our infinite branches are “Production”, “Staging” and “Development” and represent our three very separate versions of code. The finite branches represent new features, hot fixes, and changes.
By default, the main branch of your Git repository will be the Master branch. We will use the Master branch as the Production version of our code. Only code that is ready to go live will be merged into the Master branch, this ensures we will never put code live that is not ready to be set live.
Once a new version of code has been fully developed, or a new feature is ready to ship, it needs to be tested in a Staging environment. The Staging branch should reflect the bleeding edge version of your code that is ready to ship. Only last minute checks should be made on the Staging branch as all development should have been made before it has reached this stage.
Once the latest Staging code is ready to ship, it gets tagged and merged into the Master branch. Tagging is a feature of Git that allows you to give a commit a specific name to quickly move back in time. By tagging our code with “V1.1” we will be quickly be able to revert back or review code from any release.
The Development branch is the version of code that is used to develop future features, enhancements and make changes. The Development branch is used as the base to create new branches. Once a new feature, change of bug fix has been finished, it is merged into the Development branch ready to move to the Staging environment.
Each new feature is branched from the Development branch to allow for experimental development that will not adversely effect the rest of the code or the work of others. When changes are required to the structure, design or any other feature of the codebase, they are also treated the same way as new features. If a features needs to be further broken down, subsequent branches can be branched from a feature branch.
Hot fixes are special changes that are required to the live production code, but do not concern any of the new code that is present in the Staging or Development branches. To create a new hot fix we branch from the Production code and merge back into this branch when the work has been completed.
This strategy is based upon the excellent Git Flow model.
As you can see, Git is an invaluable tool for your workflow that will allow you to better manage your code, collaborate with others and give you the ability to travel back in time or experiment with reckless abandonment whenever you like. Git can seem daunting at first, but it really is so simple to pick up, and the advantages are worth the effort to learn it.
Check back in a couple of weeks for tutorials on setting up Git, using Git, and deploying to a server.