Where to store differences between dev and production branch in git?

Question

I have a project I manage out of a git repository. We use the progit branching strategy (as described in the accepted answer, here: Git branch strategy for small dev team) where one branch is the production branch and another branch is the development/testing branch. We deploy the code using fabric.

When we're ready to make a new production release with git, we merge the development/testing branch into the production branch and then deploy the production branch using fabric. The problem is that there are code differences between development and production -- some logos change, some different DB hosts/credentials, that sort of thing. I've been keeping a .patch file containing the differences and having fabric apply the patch when it deploys the production environment, but this doesn't work that well. In particular, it totally fails if some of the code around the patch has changed -- the patch fails to apply and my deploy aborts.

I've been wondering if I shouldn't just apply all my changes to the production branch directly? What are the drawbacks of this?

One particular use case I'm concerned about is if we need to make a hotfix. We currently do this by branching from the production environment, making changes, and then merging that branch back into both development and production. If the production branch is different from the development one, can those changes get pulled into the development branch when the hotfix is merged into development?

Answer 1

Your question basically boils down to "how do I make a change in one branch, and then have that change not propagate when I merge into another?". This is reasonably simple. At this point I'm assuming your production branch is basically just a series of merges, either from the dev branch, or from a hotfix branch. So presumably doing a git merge production from your development branch won't make any changes. Given that, go ahead and make your changes to the production branch. Now commit them. Now checkout the development branch and run git merge -s ours production. This basically means "merge from production, but reject all of their changes". This will create the merge commit, but won't actually touch your development branch.

Once this merge is made, you can now merge your production branch into development (or rather, merge hotfix branches) without worry, because your production-only commit is now already "merged" into development (despite the fact that the code changes itself were rejected). So merging your hotfix branches won't pull in the production-only code.

Once you've done this, the only time you ever need to go back and reapply this trick is if you make any more production-only changes. If you make changes on the development branch that conflict with your production-only changes, when merging development into production you can go ahead and accept the production side of the conflicts without problem.