You should look at leveraging the squash merge capability of git i.e. git merge --squash
, so that you do not rewrite history unnecessarily.
Both git merge --squash
and git rebase --interactive
can be used to produce a squashed commit with the same resultant work-tree, but they are intended to serve 2 totally different purposes. Your tree eventually ends up looking different in both the cases.
Initial tree:
a -- b -- c -- d master
\
\-- e -- f feature1
After git checkout master; git merge --squash feature1; git commit
:
a -- b -- c -- d -- F master
\
\-- e -- f feature1
After git checkout master; git rebase -i feature1
and choosing to pick c
and squash d
:
a -- b /-- F master
\ /
\-- e -- f feature1
As you can see from the difference, you do not rewrite the history of any branch when using git merge --squash
but you end up rewriting the history of master
when using git rebase -i
.
Also note that the actual commits (for the ones which got squashed) would be present in your git history in both the cases, only as long as you have some branch or tag reference through which those commits are reachable.
In other words, in the above example, if you delete feature1
after doing merge --squash
, you would not be able to actually view the commits e
or f
in the future (especially after the 90 days reflog period). The same applies to the commits c
and d
in the rebase
example.