Use merge or rebase to maintain a deployment branch

Question

I host with AWS which means I cant use environment variables to control my production and staging deployments. I am therefore forced to use separate branches for deployment, and am wondering if there is a best practice approach towards their maintenance?

If I merge changes into my production branch, the commit that contains my production settings will get lost in the branches history, making it more difficult to tweak those settings.

However I have read that you shouldn't use rebase in this situation as it will make it more difficult to roll back changes.

Answer 1

I also faced many challenges to implement git in my latest project. After too much googling I found this blog and it is really a nice way of maintaining git branch model.

A successful Git branching model The central repo holds two main branches with an infinite lifetime:

• master
• develop

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.

We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

Supporting branches

The different types of branches we may use are:

• Feature branches
• Release branches
• Hotfix branches

Feature branches : Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release.

May branch off from: develop

Must merge back into: develop

Branch naming convention: anything except master, develop, release-, or hotfix-

Release branches : Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s.

May branch off from: develop

Must merge back into: develop and master

Branch naming convention: release-*

Hotfix branches : Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version.

May branch off from: master

Must merge back into: develop and master

Branch naming convention: hotfix-*

You can find more details about this Git branching model from the blog. The commands used for the branching model also listed in the blog. Check the blog for more details. I successfully implemented the branching model in my project with some changes from the model mentioned in the blog. Git is a powerful and flexible tool,and this is just one way of using Git.

Answer 2

There are a few links below that share some opinions on methodologies and the reasoning behind why you should choose rebase or merge.

• Merge is ideal for committing code to a shared branch among a team. Since Rebase rewrites the history of the commits, context of related commits (like feature branching) is lost since the commits become linear based on the timestamps.
• Rebase can be ideal for pulling code into your working branch before committing back to a shared branch. The linear results and historical changing can lead to more successful merging of the commits.

See:

• http://blogs.atlassian.com/2013/10/git-team-workflows-merge-or-rebase/
• http://www.derekgourlay.com/archives/428