Skip to content

Git merge branching good practices

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

The main idea is that master branch have all the commits and the branches of the specific versions are a subset of commits. All commits on branches will end up, eventually, on master:

Basic Workflow

Imagine you start with a master branch. Then, you start a specific version branch. On the beginning, master and specific version are the same.

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

This commits pushed to master will never be on the specific version already created.

At some point, you can merge the specific version to master, so the features pushed to this specific version are also available on master. You can do it as much as you want. But you will never merge from master to specific version.

git basic branching

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 on an existing specific branch version, you have to clone that specific branch version.

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

Picture it as a flux. Once you push something to a branch, it is dissolved on that branch and you cannot take it away again.

I need to cherry pick something

You don't. If you want to cherry pick it's because someone (probably you) mess 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 have 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 breacking the flux.

Clone this wiki locally