CODEWITHSUNDEEP
gitrebase
user1772004
user1772004

Reputation: 163

git: Make a clean history after merging multiple times from a feature branch that is subsequently rebased

Suppose I am working on some feature in a branch B. My feature depends on another feature that my colleague works on in a branch A.

I work closely with my colleague, so during development he will often update A with new stuff that I need in B. The way I get his changes in is to just merge with his branch. So what I do in B is something like the following:

git checkout master
git checkout -b B
..
git commit Some work
..
git commit More work
..
git fetch origin
git merge origin/A
..
git commit Event more work
..
git fetch origin
git merge origin/A
..
git commit And even more work
..
git fetch origin
git merge origin/A
...

This works very well. The problem is that we want to get this into master and to have a nice clean history. In particular we want to:

  1. Clean up the history of A using some kind of rebase
  2. Clean up the history of B using some kind of rebase
  3. Commit first A and then B to master without all the extra merges above.

The only way I can come up with to do this is to:

  1. Rebase A into master in the usual way
  2. Cherry pick all the non-merge commits from B onto master.

One problem with this is that I manually have to cherry pick the non-merge commits.

Is there a better way?

Upvotes: 0

Views: 709

Answers (2)

Mad Physicist
Mad Physicist

Reputation: 114588

A common technique used in numpy development is to squash the feature branch into a single commit. This is probably not as effective as @Cimbali's answer for a smaller project, but it works really well for something the size of numpy, where the granularity of a single PR is very small with respect to the entire project. One advantage of doing the cleanup with a rebase is that you can move everything into a guaranteed fast-forwardable state well before doing any merging.

A standard command would be something like

git rebase -i master

Then select fixup for all commits except the first and let it roll.

Upvotes: 0

Cimbali
Cimbali

Reputation: 11415

Well instead of manually cherry-picking, you can automatically cherry-pick, i.e. rebase:

git rebase A B

git will automatically:

  • find out the parent commit between A and B
  • go over all commits in B to be applied on top of A
  • figure out that some commits are already in A and do not need to be applied again.

However, you potentially might run into a lot of conflicts along the way.

I suggest that, if a clean history at the moment of merging is import to you, you adjust your workflow to have git rebase origin/A instead of git merge origin/A, which means your history will remain clean. You may also want to read up on git rebase workflows a little.

Upvotes: 1

Related Questions