Recently I’ve spent time to study a good way to manage a software projects with GIT.
I really read a lots of blog post to check different points of view and to find out which is the best technique to use in different situations.
The principals ways to manage a software in GIT are: the Git Flow and the Github Flow.
These 2 methods can really help you to manage your project and optimise your workflow in the team.
Let’s see the differences between them.
Git Flow
Git flow works with different branches to manage easily each phase of the software development, it’s suggested to be used when your software has the concept of “release” because, as you can see in the scheme above, it’s not the best decision when you work in Continuous Delivery or Continuos Deployment environment where this concept is missing.
Another good point of this flow is that fits perfectly when you work in team and one or more developers have to collaborate to the same feature.
But let’s take a look closer to this model.
The main branches in this flow are:
- master
- develop
- features
- hotfix
- release
When you clone a GIT repository in your local folder you have immediately to create a branch from the master called develop, this branch will be the main branch for the development and where all the developers in a team will work to implement new features or bug fixing before the release.
Every time a developer needs to add a new feature he will create a new branch from develop that allow him to work properly in that feature without compromise the code for the other people in the team in the develop branch.
When the feature will be ready and tested it could be rebased inside the develop branch, our goal is to have always a stable version of develop branch because we merge the code only when the new feature is completed and it’s working.
When all the features related to a new release are implemented in the develop branch it’s time to branch the code to the release branch where there you’ll start to test properly before the final deployment.
When you branch your code from develop to release you should avoid to add new features but you should only fix bugs inside the release branch code until to you create a stable release branch.
At the end, when you are ready to push live deploy live your project, you will tag the version inside the master branch so there you can have all the different versions that you release week by week.
Apparently it could seem to much steps but it’s for sure quite safe and helps you to avoid mistakes or problem when you release, obviously to accomplish all this tasks you can find online a lots of scripts that could help you to work with Git flow in the command line or if you prefer you can use visual tools like SourceTree by Atlassian that make the dirty work for you, so you have to follow only the instructions inside the software to manage all the branches, for this reason I’ve also prepared a short video to see how use this flow with SourceTree
You can go more in deep about this flow reading these 2 interesting articles: nvie blog or datasift documentation.
Github Flow
So now, do you think that Github is working with Git Flow? Of course no! (Honestly I was really surprised when I read that!)
In fact they are working with a continuos deployment environment where there isn’t the concept of “release” because every time they finish to prepare a new feature they push live immediately (after the whole automation chain created in the environment).
The main concepts behind the Github flow are:
- Anything in the
masterbranch is deployable - To work on something new, create a descriptively named branch off of
master(ie:new-oauth2-scopes) - Commit to that branch locally and regularly push your work to the same named branch on the server
- When you need feedback or help, or you think the branch is ready for merging, open a pull request
- After someone else has reviewed and signed off on the feature, you can merge it into master
- Once it is merged and pushed to ‘master’, you can and should deploy immediately
I found an amazing interactive page where you can deepen the knowledge of this method, but I see it’s very common when you work in QA teams, small teams or you are working as freelance because it’s true that is a lightweight flow to manage a project but it’s also quite clear and secure when you want to merge your code in the master branch.
Another good resource about Github Flow is the blog post made by the Github evangelist Scott Chacon.
I recorded also a video on how to use Github flow with SourceTree:
If you have any other method to manage your project in GIT feel free to share because I’m quite interesting to see how you usually work with GIT and if there are better ways to work with and if you have any other feedback or question I’m here for you!
lucamezzalira.com 
Thank you Luca for the post!!
I (and I push it to my colleagues) use the first one, it could be a little complicated at the first approach but it ensures you to have everything tracked. I haven’t found difficulties because my mind already thinks in the same way. We use SmartGIT and it’s embraced the same workflow doing the dirty job for you.
The ‘release’ approach is also useful in case of publishing tools where you to have to make some steps before publish the project (think about Grunt, the ‘build’ process is done in the release commit, not in the develop one nor in the master one).
More: the master branch remains clear, tagged, easy to understand and everyone that clones the repo could deploy the latest master commit without worrying about it. But reading the post that approach is moreless the same for the GitHub flow.
The evolution is having GIT installed on the server too, we’re working for it 🙂
To give a contest to my comment: we are a web agency with 4/5 developers, usually 2 developers working on the same project.
Thanks for sharing your thoughts and experience I think it’s very useful have this kind of discussions in blogs and forums
Looks like GitHub tweaked github flow a bit so that you deploy your feature branch to production before merging to master. Any thoughts on the changes? Didn’t see any place where they explain their reason for the change, or how the implement it.
I think that the main motivation would be a merge into master requires a new build and QA because of being a new build.
thanx really this article is very helpful !!!
Hi Luca,
In my Company we have adopted a sort of modified GitFlow workflow, becasuse we had wanted to integrate the continuous integration/delivery approach still keeping each development stream isolate into a feature branch. I also started using the Jenkins CI as the build automation tool, specifically the Delivery Pipeline feature, to automate all the building steps from source code to production deployment.
As you are saying Continuous Integration/delivery doesn’t really fit with the GitFlow approach, and I must agree on that, although I must say that if you accept lossing something from both approach, it may be working quite well.
One thing that you necessarly loose is testing. I’m not saying that you can’t run automated test suites, but you have to focus the testing jobs only on few branches – at least to reduce the CI server’s load – like the “develop” or “master” branch.
A second thing that you loose is high fre
Sorry, I posted my reply before reaching the end and reviewing (few typos still there)
As I was saying,
A second thing that you lose is high frequency deployment, because you still need to wait for merging of each feature into the develop branch before start any unit or integration testing session. Finally, of course, what you lose is the release-fixing task, because your automated worklow is no more able to jump-back to an older release to start again the pipeline – I’m not completely sure that “it can’t” but in my experience I haven’t been able to –
I’m still trying to tune our pipeline two speed but the development-testing-delivery cycle, if someone has suggestion it’ll be great to talk about!
Thank you!
Thank you, this is very helpful to me.
About http://softwareengineering.stackexchange.com/questions/312022/the-trend-of-the-develop-branch-going-away
You can switch GH default branch from the master to dev and problem solved.
We have adopted GH Flow + Git Flow.
master is a default branch for tags, builds, and our library clients
dev is a default branch for developers and github: CI, merge pull-requests, code reviews, etc.
What am I doing wrong?
it depends if you work in continuous deployment or with releases, git flow suits better the releases because it handles also the hotfixes and the release branch, instead the github flow is more focused on continuous and small improvement.
Hi Luca,
Thank you for this post.
I’m trying to use git flow, for that I’am using git-flow command lines tool (http://danielkummer.github.io/git-flow-cheatsheet/)
I figure-out that with this tool we can’t publish a “develop branch”, that means developers can’t share this branch.
What do you thinking about that?
Did you try to use: https://github.com/nvie/gitflow
Yes, the same limit, no way to publish the develop branch
Hi, I’m trying to watch your videos on this page but there is not sound. I’ve checked other YouTube videos and I have sound for them. Do these videos have sound?
Thanks,
Brett
No sound at all, sorry Brett