Menu
I have a 'master' branch and several topic branches. Assume that the master branch is used primarily as a release candidate and no development work happens on this branch.
The topic branches are several and are shared by the team. Some of the branches have more than one developer working on them. All topic branches are rebased from the master branch regularly.
To clean up the history in the 'master' branch, I did a 'git merge --squash' when merging code from topic to master branches. This worked perfectly fine.
Now - when topic branches are rebased -- the commits are getting duplicated. Is there a way to clean up the commits on the topic branches after the 'git merge --squash' has been successful?
448
What is the squash rebase workflow? It's simple – before you merge a feature branch back into your main branch (often master or develop ), your feature branch should be squashed down to a single buildable commit, and then rebased from the up-to-date main branch.
Before rebasing such branches, you may want to squash your commits together, and then rebase that single commit, so you can handle all conflicts at once. Here's how to do that. Imagine you've been working on the feature branch show_birthday , and you want to squash and rebase it onto main .
When should I rebase and when should I squash? It does not matter which you use but I recommend rebase. Rebase changes the parent node of the feature branch but merge does not and I recommend it because it keeps the commit structure simpler but as a git user, it makes not different.
Squash merging is a merge option that allows you to condense the Git history of topic branches when you complete a pull request. Instead of each commit on the topic branch being added to the history of the default branch, a squash merge adds all the file changes to a single new commit on the default branch.
Lets assume you have the following scenario:
A - B - C (master)
\
D - E (topic)
If you merge topic into master with --squash you will get something like
A - B - C - F (master)
\
D - E (topic)
Where F contains all changes from D and E. Rebasing topic on master makes no sense since the topic branch is already in master (through F). Instead of rebasing you could move the topic branch to F, e.g.
git checkout master
git branch -f topic F
Which yields:
A - B - C - F (master/topic)
All you need to do now is to push up the moved topic branch:
git push -f origin topic
I used to do same thing as Magnus just with couple more commands:
git checkout master
git merge --squash topic
git commit -m "Add topic feature"
git branch -D topic
git checkout -b topic
git push -f origin topic
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
