Clean up branch's commit history by omitting commits which are now on master-CodePudding

I have a feature branch, and I want to clean up its commit history so it's easier to review. Many of the old commits are actually from other branches which have since been squash-merged into master.

I'd like to somehow delete all of those commits which have now been (squash-)included in master, and rebase(?) to the current master branch. (The goal is just cleaning up the history for review, so it doesn't need to actually involve "deleting" or "rebasing" as long as it achieves this goal.)

There are many old commits and it would take a long time to go through them individually, so I'm looking for an automatic method if possible. (I'd guess it's possible somehow to see if a commit's changes are already present in master, and to then ignore it if so, right?)

I looked through the commands given in git -h and git rebase -h, but I wasn't sure which, if any, would accomplish this; I'm a little hesitant to play around without knowing what I'm doing here, since I don't want to mess up my working directory too badly.

Thanks in advance! :)

CodePudding user response：

I believe the first half of the answer is isolating the "leftovers" which haven't been merged in yet. This can be done a few different ways, but one of the simplest is to just test the merge:

git fetch

# create a temp branch for testing the merge
git switch -c test-merge origin/master --no-track # create a branch name test-merge
# OR, if you know you will throw this away, then don't bother with a branch
git switch --detach origin/master # checkout master but detached

# Merge in the feature branch
git merge my-feature-branch
# OR, if you want to squash all of the changes on the feature branch into a single commit
git merge --squash my-feature-branch # make a single commit with all changes
# resolve conflicts if necessary, and commit

git diff @~1 @ # this is what would actually change if you PR my-feature-branch into master

By inspecting the diff (or what's in the squashed commit), you may be able to decide how important it is to keep all of the commits that led to these changes, or if you can just keep the squashed commit. If you're OK with the squashed commit, then simply push out your branch and create the PR.

If you wish to try to rewrite the history of the feature branch to keep the still relevant commits in the repo, at least now you have an end state to try to reach.

Side Note: although having history is nice, occasionally I've found myself in situations where I wish to rebase so I can remove some commits, but there are so many conflicts on my branch that rebasing would not be a good option. Sometimes in this position I'll make sure to create the PR first, then do the squash merge and force push, with the understanding that if I ever want to see the history prior to the squash merge, I can just go look at the PR history in the UI tool.