GIT: What happens to previous merges from master if I squash all commits on a branch and then merge it onto master?

Question

I have a branch I've been working on for a long time, regularly merging the main branch into it. So the history of this branch contains all of the commits from the main branch as well. I want to squash all of the commits into one commit on the branch, and then merge this branch back onto master. Will this affect the commit history on master?

Answer 1

The general idea is that the history in a VCS is kept. So, there's no outcome if you simply add yet another commit.

But in git you may rewrite a history if you wish. If you have already published the original history, and some other persons have relied on it (that is, they have created their own commits on top of yours), then such a history rewrite would cause some pain for them - they will have to rebase their changes on top of the new history.

But if the history is still unpublished, or you can negotiate with your peers, and they're agree with the change, then you're free in your actions.

Update : Since the altered branch has some merges from the master, I suppose that the initial picture of commits looks somewhat like this:

 A ---> B ---> C ---> D ---> E --> F (master)
  \             \            \
    --> BA --> BM1 -> BB --> BM2 --> BC (branch)

where <letter> s are master commits, B<letter> s are "own" branch commits, and BM<number> s are merges of master to branch .

Now you want to squash commits in the branch, so that the final picture would look like this:

 A ---> B ---> C ---> D ---> E --> F (master)
  \                          \
    -----------------------> BZ (branch)

and the file tree of BZ commit to be exactly the same as BC file tree.

The default behaviour of git rebase regarding merge commits is to flatten the history dropping merge records but replaying changes introduced by corresponding merges. Thus, if you simply issue git checkout branch; git rebase -i A git checkout branch; git rebase -i A and squash the commits to a single one, you will receive something like this:

 A ---> B ---> C ---> D ---> E --> F (master)
  \                          
    -----------------------> BZ (branch)

(notice the missing link between E and BZ )

So we need to perform some magic on rebasing. To simplify the task create tags tagA marking commit A , tagE marking commit E , and tagBC for BC . These tags could be safely deleted later when the job is done.

Now we're ready to proceed. Issue git rebase -i tagA . You'll be presented with a list like this:

pick 515de5f commit BA
pick 1c749c6 commit B
pick 4490402 commit C
pick 4da9e96 commit BB
pick 6d9dc01 commit D
pick 7e469d6 commit E
pick 861038b commit BC

Insert fake merge at the top of the list and replace all pick s with fixup s, so you'll get something like this:

exec git merge -s ours -m "The resulting commit" tagE
fixup 515de5f commit BA
fixup 1c749c6 commit B
fixup 4490402 commit C
fixup 4da9e96 commit BB
fixup 6d9dc01 commit D
fixup 7e469d6 commit E
fixup 861038b commit BC

Now save the file and quit. After the sequence is applied you'll get the desired commit structure. Test if BZ (head of the rewritten branch ) is the same as the previous one (marked as tagBC ), — it should be, — and you've done.

All standard practices for git rebase are applied: if something goes wrong you can always restart with git rebase --abort . If some conflicts occurred, you need to resolve them, and to continue with git rebase --continue and so on.

Answer 2

You could definitely do that. You can do a squash off all commits on your branch. Do a git pull --rebase origin master to make sure everything is in order. Resolve all conflicts and then merge to master.

Note :Typically when you are working on a branch say branch_a based of off say master it is recommended that you rebase off master rather than merge master in each time there is a change on master.