4

So, I've been using git cherry-pick for this but it's getting cumbersome and I wanted to know if there's a simpler way (or another approach).

Say I have 3 branches: master (stable, candidate for production), develop (working branch) and production.

Now, beside the stable milestones, production has some production-specific settings. Things I don't want to change every time I merge into it. I can't simply merge develop into master and then master into production, nor develop straight into production, because this would create a conflict with the production settings.

So far issuing git cherry-pick commitA^..commitB in production has worked, but I don't want to keep doing this every time.

Am I missing something obvious? Is there a simpler way to merge just the commits of a single branch?

imiric
  • 8,315
  • 4
  • 35
  • 39

2 Answers2

3

It sounds to me like you should look at Git Attributes. Make a .gitattributes file containing rows like:

settingsfile merge=ours

This will stop the settingsfile from being overwritten by merges. Instead of conflicting, this will silently resolve the merge by accepting the current state of the file.

For more details, see this answer about how to create a custom merge driver

Community
  • 1
  • 1
Klas Mellbourn
  • 42,571
  • 24
  • 140
  • 158
  • Thanks, I think I'll go with this. I've seen the `ours` merge strategy before, but wasn't aware it could be defined per-file like this. There are still instances where I'd want to merge in changes to this file, but I guess I'll do that manually. Thanks again! – imiric May 26 '13 at 19:29
3

Consider using separate settings files for dev and production environments

cherry-pick is usually the best and easiest option to merge only specific commits into a line of development. If you have to constantly cherry-pick commits from your development branches into master/release branches, instead of using the usual merge command, just in order to avoid overriding a settings file, you might want to consider having the production, deployed version of the settings file generated by some kind of script during deployment, and/or having separate settings files for your development and production environments, e.g. dev.settings and production.settings.

Alternatives to cherry-pick

You could also achieve the same effect of a cherry-pick by using rebase --onto or using patches, but using rebase --onto can be more cumbersome to use if you're only trying to pick a single commit, and using patches takes more steps.

rebase vs cherry-pick to pick a single commit

As an example of how cumbersome rebase --onto can be sometimes vs. cherry-pick, say you have the following commits on a develop branch:

               develop
A <- B <- C <- D

Let's say you just want to merge C into your master branch. Using cherry-pick, you simply use this (while on master)

git cherry-pick C

To pick just a single commit with rebase --onto however, you would need to go

git rebase --onto master B C

With the above, you're saying that you want to use the current position of master as the new base commit/parent for C, and B is the old base/parent.

rebase vs cherry-pick to pick a range of commits

Picking a range of commits becomes very similar between the two commands though. For example, say you want to merge both B and C. Then

git cherry-pick A..C
git rebase --onto master A C

are equivalent, though the cherry-pick needs to be done while master is checked out, but rebase --onto does not, because it will check out master for you.

Using patches

If you want to see how much more work it would be to use patches, you can read about using them in the Pro Git book.

  • Thanks for your answer. Re: using separate files, I do something similar, but I still need to keep the file I declare which settings file to use untouched by the merge. In other situations I've seen this file go untracked by the repo, but that's not an option in my case. Thanks for suggesting rebase, but its usage is very similar to cherry-pick, which I'm trying to avoid. And approaching it with patches seems more work than cherry-picking. Thanks again for your thorough answer! – imiric May 26 '13 at 19:27