Cherrypicking versus Rebasing

Question

The following is a scenario I commonly face:

You have a set of commits on master or design, that I want to put on top of production

Answer 1

You should make a rebase --interactive your design branch on top of production, where:

• you can reorder your commits, starting with the ones you need in production
• you can then merge production to the last commit of design you want to incorporate (fast forward)

    -x--x--x1--x--x2 (design)
      \
       p--p (production)

With x1 and x2 needing to be included in production:

git checkout design
git rebase --interactive production

-x
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (design)

Then:

git checkout production
git merge x2'
-x
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (design)

That allows you:

• to validate current design commits against the production commits (durung the rebase)
• reorder the design commits
• include the first ones in production
• allows subsequent merges from design to production to be a fast-forward one.

---

Lakshman Prasad adds:

I push the changes at the end of the day most of the time. So doesn't really help that much. How would your answer change for the pushed master branch

I would do the same, but with a private branch created just for the operation:

git checkout master
git checkout -b master-private

    -x--x--x1--x--x2 (master, master-private)
      \
       p--p (production)

, then the rebase, this time with the private branch (i.e. a branch you won't ever push).

git rebase --interactive production

-x--x--x1--x--x2 (master)
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (master-private)

Then:

git checkout production
git merge x2'

-x--x--x1--x--x2 (master)
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (master-private)

master won't benefit from the commit reordering (with a more logical order), but at least you can push master whenever you want.

And production can still include exactly what it needs.
If subsequent commits to master have the same issue (some need to be included to production, other will later), I would:

• delete master-private (we don't really care about those x', copy of x commits from master)
• make a master-private branch on top of master
• re-do the rebase --interactive, with a crude conflict resolution tactic (except for the first commits of that master-private branch, since those ones need to be integrated in the production branch)

    -x--x--x1--x--x2--x--x3--x (master)
      \
       p--p--x1'--x2'--x3' (production)
                   |     \
                   |      x''--x'' (master-private)
                    \
                     x'..x' (old x' from the first master-private)