squash hundreds of commits and rebase kicks off a large conflict resolution

Question

I have a "long lived feature" branch that i have been working for last 2 months. It has 211 commits that i want to squash into single commit before this "long lived feature branch" can be merged with "origin master". When i run "git rebase -i HEAD~210" it kicks off a conflict resolution process of more than 500 conflicts.

What's the best way to squash commits and complete rebase ?

When i do:

git rerere
git rebase -i HEAD~210
# change all "pick" with "squash" and save and exit followed by single
# commit message

It will then present me with 500 or so conflicts to be resolved which is my problem. i.e. is there any way i can get away with it?

There are only 4 files that keep repeating and git rerere hasnt been of much help.

My other confusion is why i get more than 500 conflicts to be resolved when the commits are 211?

I have been reading on merge vs rebase and the difference seems to be only retaining history or not but in effect processes are quite different. merge works fine but rebase creates a lot of trouble. I have been thinking of creating another feature branch and run git merge --squash to get rid of commits but my colleagues have already committed on a PR based on my "long lived feature branch" and i would prefer a way to sort out this issue without creating another branch

Answer 1

Here is a recipe to create a branch which groups all the changes brought by your feature branch squashed in one single commit:

# from your feature branch:
git switch my-long-lived-branch

# create a working branch:
git switch -c my-squashed-branch

# bring all changes together, on top of the last sync point with master:
git reset --soft $(git merge-base HEAD master)
# and commit:
git commit   # all changes in one commit

You now have my-squashed-branch, which introduces the exact same changes as your initial branch, with only one commit. That commit is based on the last point in master where you synced master with your branch.

You may open a pull request directly from that squashed branch, or run git fetch; git rebase origin/master to rebase it on the latest version of master before opening that pull request.

Should there be conflicts in that last rebase, at least they will be contained to one single commit.

note: if the branch modifies 500 files, and that out of bad luck these same 500 files have also been modified on master, you may have 500 conflicts even though there is one single commit.

The number of conflicts is bound by the number of individual file changes (if you have 200 commits, you would have to sum the number of file changes in each commit), not by the number of commits alone.

Answer 2

If in the end you want to have a single commit to then merge into the main branch, then you can just as well merge with main branch and then do a soft reset.... "tomato/tomato", "potato/potato".

git checkout my-long-branch
git merge main-branch
# get that merge finished if there are conflicts....
# when the merge commit is finished:
git reset--soft main-branch
git commit -m "a single commit for my long branch"
# now if you try to merge that ibto main branch, it should be fine