Question

I’ve got a git repository with two branches, master and amazing_new_feature. The latter branch contains the work on, well, an amazing new feature. A colleague and me are both working on the same repository, and the two of us commit to both branches.

Now the work on the amazing new feature finished, and a bit more than 100 commits were accumulated in the amazing_new_feature branch. I’d like to clean those commits up a bit (using git rebase -i) before merging the work into master.

The issue we’re facing is that it’s quite a pain to rewrite/reorder all 100 commits in one go. Instead, what I’d like to do is:

1. Rewrite/merge/reorder the first few commits in the amazing_new_feature branch and put the result into a dedicated branch which contains the ‘cleaned up’ history (say, a amazing_new_feature_ready_for_merge branch).
2. Rebase the remaining amazing_new_feature branch on the amazing_new_feature_ready_for_merge branch.
3. Repeat at 1.

My idea is that at some point, all the work from amazing_new_feature should be in amazing_new_feature_ready_for_merge and then I can merge the latter into master.

Is this a sensible approach, or are there better/easier/more fool-proff solutions to this problem? I’m especially scared about the second step of the above algorithm since it means rebasing a published branch. IIRC it’s a dangerous thing to do.

Answer 1

How can I rewrite the history of a published git branch ?

Normally you cannot, especially if that branch has been widely distributed.
If you are only two developers pulling/pushing that branch, you can agree to modify it and then the other developer can reset his/her local branch to reference the remote one he/she just pulled (as in this SO answer).

In that case (limited distribution), the steps you describe in your question are sound.