7

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?

Community
  • 1
  • 1
Igor Serebryany
  • 3,307
  • 3
  • 29
  • 41

2 Answers2

10

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.

Lily Ballard
  • 182,031
  • 33
  • 381
  • 347
  • ok, so, this doesn't work: when i go to `git merge development` from production whenever i do a release, the differences in the development branch overwrite the production-only changes in the production branch. i need to keep changes that don't leave the production branch -- they neither go into any other branch, nor are they overwritten by any other branch. – Igor Serebryany Feb 01 '12 at 06:06
  • @IgorSerebryany: If you're making changes on development to the exact same lines that you're trying to preserve in Production, then yes, you're going to have problems. Every time you make such a change you have to do the dummy merge to basically "bake in stone" how the Production branch is supposed to look with respect to those lines. – Lily Ballard Feb 01 '12 at 06:41
  • 2
    i did the following delicate ballet: (1) made sure the two branches were in sync; (2) i applied my changes to the production branch (3) `git merge -s ours production` from development branch; (4) `git merge -s ours development` from the production branch. as a result, i think i've reached the state i wanted, where my changes don't get clobbered and don't get transfered out of production. – Igor Serebryany Feb 02 '12 at 21:08
  • @IgorSerebryany: Yes, as long as you don't touch those lines again on either branch, you should be good to go. – Lily Ballard Feb 02 '12 at 21:10
0

I also has this request in dev branch and production branch. I don't think git merge -s ours ** is a good solution because it can just ensure the later one merge won't be overwrite, and after that it will be cause a parent relation between dev and production. You have to use git merge -s ours ** each time and that would make log graph really ugly and meaningless.

So I recommend using

git cherry-pick

. That ensures the content you want pull.

peacepassion
  • 1,918
  • 2
  • 15
  • 19