Skip to content

Git merge branching good practices

María Arias de Reyna edited this page Jun 4, 2013 · 16 revisions

The leading principal is that master branch (trunk in SVN) has all the commits and the branches of the specific versions are a subset of commits. All commits on branches will eventually end up on master.

Basic Workflow

You start with the master. Then, you start a specific version branch: svbranch. In the beginning the master and svbranch are the same.

Then you start committing and pushing to svbranch. At the same time, there are other commits pushed to master. These commits are not for svbranch, but for a future version (maybe because they are unstable).

These commits pushed to master after creating svbranch will never be on svbranch.

git basic branching

At some point, you can merge svbranch to master, so the features pushed to this branch are also available on master. You can do it as often as you want. But you should never merge from master to svbranch.

Merge new feature/bug fix

When adding a new feature you should branch from the master or the specific version you are developing for. If you want to include your feature in an existing specific version, you have to clone that specific version.

Otherwise, if you merge your feature on master and then want to move that feature to a specific version, you will drag all the commits on master to the specific version.

Picture it as a flux. Once you push something to a branch, it is dissolved in that branch and you cannot remove it anymore.

I need to cherry pick something

You don't. If you want to cherry pick it's because someone (probably you) messed things up.

What does a normal pull request ask you to merge? You have to see only the commits you have done. If there are commits on your side that you don't want to merge, just create a new branch, cherry pick there and then pull request.

Merging to master and specific version

Just follow the guidelines described before. Work on the specific version branch and then, when the specific version has this commit pushed, merge with master.

What about commits on the specific version that should not be on branch (like changing the version number)?

Just do it first on the specific version, commit, push, merge with master and change it again on master.

A bit dirty, but better than breaking the flux.

Still have questions

Try here: http://nvie.com/posts/a-successful-git-branching-model/

Clone this wiki locally