# Popular Git branching model **URL:** \ **Category:** Misc\ **Created:** [June 19, 2016, 1:08pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440 "2016-06-19T13:08:21Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 19, 2016, 1:08pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/1 "2016-06-19T13:08:22Z")
> **[A successful Git branching model](https://nvie.com/posts/a-successful-git-branching-model/)** > > In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful. And a video: [![](https://canada1.discourse-cdn.com/flex007/uploads/dgraph/original/2X/a/ad6bdd09fd64400894cbe4a6dc76db10dab00303.webp "A short introduction to Git Flow") ](https://vimeo.com/16018419) ---
**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\ **Post date:** [June 19, 2016, 3:00pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/2 "2016-06-19T15:00:38Z")
Yeah, used to follow this at my previous company. Let’s follow this from now on for future features. ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 20, 2016, 5:04am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/3 "2016-06-20T05:04:27Z")
What’s your opinion about it? Useful? ---
**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\ **Post date:** [June 20, 2016, 5:25am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/4 "2016-06-20T05:25:31Z")
Actually not really sure about having develop and master both. Read this interesting article about some criticism of Git flow [http://endoflineblog.com/gitflow-considered-harmful](http://endoflineblog.com/gitflow-considered-harmful). Naming branches with the `feature`, `release`, `hotfix` gives more context so I like that. ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 20, 2016, 5:27am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/5 "2016-06-20T05:27:27Z")
Funny he doesn’t like `--no-ff`, which to me was pretty convincing. It would avoid us having to squash our commits explicitly, from what I understand. > The --no-ff flag causes the merge to always create a new commit object, > even if the merge could be performed with a fast-forward. ---
**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\ **Post date:** [June 20, 2016, 5:31am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/6 "2016-06-20T05:31:05Z")
> [@mrjn](#): > > It would avoid us having to squash our commits explicitly, from what I understand. I don’t think it will do that. All the commits made in the feature branch would be retained in the master branch on merge if we don’t squash our commits explicitly. Btw merges on Github are -no-ff. Hence they always end up creating a merge commit even if fast forwarding is possible. ---
**Author:** ![mohitranka](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mohitranka/32/1005_2.png) [@mohitranka](https://discuss.dgraph.io/u/mohitranka)\ **Post date:** [June 20, 2016, 2:17pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/7 "2016-06-20T14:17:51Z")
I have been using this model for last couple of years. Only issue is handling codereviews as there is no explicit step for it, especially if you use a third party tool (eg. Github PRs) for doing them, so you end up tweaking it to incorporate the additional step. ---
**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\ **Post date:** [June 21, 2016, 6:27am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/8 "2016-06-21T06:27:12Z")
I think it’s a norm to create PR’s for pull requests to the `develop` branch from `feature` branches. Develop has stable code always, which can be merged to master by creating a release. Do you follow something else? Not sure of the benefit of having the develop/master split. ---
**Author:** ![mohitranka](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mohitranka/32/1005_2.png) [@mohitranka](https://discuss.dgraph.io/u/mohitranka)\ **Post date:** [June 21, 2016, 9:37am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/9 "2016-06-21T09:37:58Z")
This is mostly correct. Typically this is how it goes with different kind of branches. `feature/hotfix` - They contain a unit of work, either new functionality or refactoring or a bugfix. At the completion, the work is developer tested and code reviewed. `develop` - This is the baseline of all development work (except `hotfix`es), not stable and used for integration of ALL development work. All feature branches are forked from this, and merged back to develop. QA testing happen here and automated nightly builds can be made from this branch. `release` - This branch is optional based on the release philosophy and bandwidth of the team. To keep the release process not block the usual development process, a release fork is taken from the `develop` (which is being continuously altered with new features) and a final round of functional and performance testing done here. `master` - This is the pristine, stable production branch, which is used by the clients/users. All work related to QA testing, automated builds etc. on `develop` and `release` branches are done to ensure that the quality of `master` stay high. @pawan, I hope this clears a few bits about traditional release process. ---
**Author:** ![mrjn](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/mrjn/32/775_2.png) [@mrjn](https://discuss.dgraph.io/u/mrjn)\ **Post date:** [June 25, 2016, 11:41pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/10 "2016-06-25T23:41:27Z")
This process looks like an interesting approach – and seems very relevant to Dgraph. Just yesterday, `nii236` sent me this PR: > > > This change is \[\Reviewable\](https://reviewable.io/reviews/dgraph-io/dgraph/119) Because our master has moved on to new binary name `dgraph`, while our _release_ still uses the old binary name `server`. Using Git flow would avoid this particular problem - and also make releases easier. Also came across this nice intro: [Workflows with git-flow | Learn Git Ebook (CLI Edition)](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/git-flow) ---
**Author:** ![pawan](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/pawan/32/1946_2.png) [@pawan](https://discuss.dgraph.io/u/pawan)\ **Post date:** [June 26, 2016, 3:04am UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/11 "2016-06-26T03:04:11Z")
Yeah right , things would only be merged to master when a release is done. Develop would contain the latest code , so yeah git flow would have avoided the wastage in effort in this case. It could also have avoided the issue other day where a bug was pushed to master after the `net/trace` PR. ---
**Author:** ![bitmalloc](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/bitmalloc/32/1015_2.png) [@bitmalloc](https://discuss.dgraph.io/u/bitmalloc)\ **Post date:** [June 26, 2016, 7:46pm UTC](https://discuss.dgraph.io/t/popular-git-branching-model/440/12 "2016-06-26T19:46:19Z")
I’ve used the git-flow branching model before and I found it very useful, specially because it keeps things organized. Having `master` containing the release versions, `develop` is the source for new/current work. It adds an extra layer for checks where your CI could be running every time there’s a change in the current `develop`, before making it to `master` for a release.