Use merge or rebase to maintain a deployment branch

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.

  • Git - Detect if rebased with conflicts
  • How to merge two branches without a common ancestor?
  • git autosetuprebase is not working?
  • `git svn rebase` vs `git rebase trunk`
  • How can I find out how many commits in master are not in my branch?
  • How can I save a git “rebase in progress”?
  • Git: how can git/linux maintainers maintain so many branches
  • git merge rename conflict
  • 4 Solutions collect form web for “Use merge or rebase to maintain a deployment branch”

    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
    enter image description here
    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:

    Must merge back into:

    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:

    Must merge back into:
    develop and master

    Branch naming convention:

    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:

    Must merge back into:
    develop and master

    Branch naming convention:

    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.

    You could version two settings files (one for dev and one for prod)

    Then you could leave to an “elasticbeanstalk/hook” script to write the actual settting file for you after a “git aws.push“.

    You can see an example of a similar issue in “How to get Elastic Beanstalk nginx-backed proxy server to auto-redirect from HTTP to HTTPS?”, about a Node app (which might not be your exact case), where a .ebextensions/config file will write a /opt/elasticbeanstalk/hooks/configdeploy/enact/

    That last script is a hook which can run on deployment, and could update the actual config file of your environment.

    On master, version both settings files (settings_master and settings_prod) and a symlink settings -> settings_master. Now, branch prod off master (or merge master into prod if it already exists), and, in prod, modify only the symlink settings to point to settings_prod.

    Commit this change to prod.

    Now do all development on master, and as long as you don’t modify the symlink itself (changing either of the settings files is fine), you will be able to merge master into prod as often as you like without affecting the target of settings. Your application should retrieve its configuration from settings.

    This will result in a commit history that looks like this:

    ... -o---o---o---o  master
          \       \   \
    ...  --o-------o---o  prod

    The diff from master to prod after each merge of master into prod will always be exactly:

    --- a/settings
    +++ b/settings
    @@ -1 +1 @@
    \ No newline at end of file
    \ No newline at end of file

    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.


    Git Baby is a git and github fan, let's start git clone.