Git-Flow Implementation

Attending a conference can open your eyes to new processes that will make your day-to-day workflow more enjoyable. Recently, our interactive team took time off to attend the Lone Star PHP Conference in Addison. Many of the presentations appealed to us, and we tried to retain as much information as possible throughout the two days. Our favorite presentations revolved around creating efficiencies in our processes and implementing more automation to allow us to focus on actual development, with less worry about cursory items. With our newfound excitement, we set out to work smarter, and in doing so, found git-flow.

For those who are unfamiliar, Git is a version control system that is used to track changes in a piece of software. For each web project that we build, we have a folder containing the code for it and we use Git to create a repository in each folder that will store all changes made throughout the project’s lifetime. Git is also a non-linear versioning system, which means that a developer can create a branch from a version of the code and work on that branch without affecting the original trunk. When the developer is finished making changes on the new branch, he or she can merge the branch back into the original trunk and either work from there or create a new branch. This is a very basic description of Git, and when it is set up correctly and multiple developers are working on it concurrently, the branching model can become very complex. This is where git-flow saves the day.

Before the conference, we used plain Git to track our repositories, which meant we had to write every command in order to implement a hotfix or feature for the software that we created. For instance, when a branch is merged, that branch needs to be deleted, and it is easy to forget to run that command. Also, having to enter multiple commands can get tedious throughout a project, and allows for errors. With git-flow, our worries about tracking code correctly have all but disappeared. With one command we can easily create a new feature branch, and once the code is complete, we run another command to have git-flow handle all of the merging, cleanup and switching back to the main branch. When we need a hotfix, the new code will have to be tracked in both the production and development branches (two main branches that never get deleted), and again git-flow makes this easy. We run one command for creating the new branch and another when we are finished, and we no longer have to worry about missing code in either main branches since git-flow handles it all for us. What makes git-flow special is that it is just a tool built on top of Git, which means we can still use the normal commands when necessary, but why would we do that when it is so helpful to use git-flow?

This is just one of many time saving changes we have learned from our conference outing. When we put all of the new workflows into practice we will be able to spend time doing what we love most, writing code!