Git Workflows: Centralized, Featured Branch and Git Flow
You will not found a solution for all your problems with only one of these workflows, instead you will see very important options to work with Git in your team.
Patterns are always important. We’ve been used to it since we were born. Patterns facilitates to recognize what is and how something works… In development we are officially using it since Erich Gamma, Ralph Johnson and others wrote the book Design Patterns: Elements of Reusable Object-Oriented Software. This book describe a lot of patterns for development to organinzing code, create responsabilities between resources (a.k.a code), decomposition, inheritance, polymorphism and others benefits.
When we thought about version control Git is the most popular VCS nowadays. It was created in 2005 and since then he is marked by his flexbility, facility and a lot of options to work in a team on the same repository of code. Git has patterns (good ones) to work with, they are: Centralized Workflow, Featured Branch Workflow, Gitflow Workflow and Forking Workflow. I will talk a bit more about the first three.
Centralized Workflow
This is the “troublemaker”, the cause of discords. The Centralized Workflow uses a central repository to serve as the entry for all changes to the project. The default development branch is called master and all changes are committed into this branch. This workflow doesn’t require any other branches besides master. The client starts by cloning the central repository and in their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point. It is the most simple way to work with Git, you work directly on the master locally and when you finish doing changes you commit to the central repository, simple right? Not too simple, let’s see the big picture.
Imagine that you have a team and everyone is working on your local copy of master and one of your teammates, John, push all his changes about the feature B to the central repository but you are working on feature A locally yet. Friday’s you finish your feature and your leader tells you to deploy on production this feature as soon as posible, BUT the John’s feature cannot be deployed together. See the big picture? You have to sincronize your local repository with master to deploy something but in master you have code who is not applicable to be deployed. It will be cool if you can work on “another copy of central repository”, right? Featured Branch and Git Flow solve your problem, let’s see more.
Featured Branch Workflow.
The Feature Branch Workflow still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names as login-template-header, login-http-resource, refactoring-login-service, etc.
Now youre team is working alongside of the remote master branch, everyone is working on a feature branch. When each feature is done and are up to put on development the branch should be merged with remote master by a Pull Request.
Pull Request.
Pull requests are a feature that makes it easier for developers to collaborate using a git client (GitHub, Bitbucket, Stash, etc.). They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project. Pull request is a dedicated forum for discussing the proposed feature. If there are any problems with the changes, teammates can post feedback in the pull request and even tweak the feature by pushing follow-up commits. All of this activity is tracked directly inside of the pull request.
Essentially a PR should be closed after a Code Review with others developers. Code review is a major benefit of pull requests, but they’re actually designed to be a generic way to talk about code. You can think of pull requests as a discussion dedicated to a particular branch. This means that they can also be used much earlier in the development process. For example, if a developer needs help with a particular feature, all they have to do is file a pull request. Interested parties will be notified automatically, and they’ll be able to see the question right next to the relevant commits. After the Code Review is finished your code will be able to become part of the remote master code.
Git Workflow.
This is the most complete workflow on git, you have many possibilites. I always thought this is the exactly workflow which big teams work on the same repository would adopt and the small teams should avoid.
Git Flow was presented by Vincent Driessen in the article A successful Git branching model in 2010 and looks like this.
Looking the big picture you can see the possibilities you can do with this flow. You have hotfixes branch that should be solved as soon as posible on the minor “distance” of master, to simplify and do the change as faster as can, you have release branchs which are the preparation to the next release on production, develop branch and as you can note by the name is on the code merged from release branch are, nothing directly on master anymore, which now is only tags.
I guess this is the most “beautiful” workflow on git, you have a big consistency working with a big team but is an overengineering when you are working in a small or medium (maybe) team, because you have more control to manage the changes.
Git Flow is an evolution of Featured Branch Workflow, so it reuse all principles of each pattern and include more as develope, hotfixes and release branchs.
These patterns are very important and I guess for each team you will use one of them. One isn’t better them another in every case, forget it! You will not found a solution for all your problems with only one of them instead you will have more options to work with small, medium and big teams and see how any of these patterns works better.
I hope you have enjoyned! If not comment or send me private message on Twitter with suggestions. Below has some useful links of this topics.
A successful Git branching model by Vincent Driessen
