Git commit squashing (rebase -i): how do commits actually work?
I don't quite understand how the commits are squashed with git rebase -i. There is one thing I was left wondering:
If my rebase -i produces this list:
pick A Last commit
pick B Commit
pick C Some other commit
Should I squash commits A and B or B and C? Problem is git said in this case that it would rebase D..A onto D (D being the last commit before this) rather than C..A onto C which would mak开发者_开发百科e sense to me. D is not shown at all, so why word it like that?
The thing is that D..A
in git terminology means "from D to A not including D itself". If you look into git-rev-list
manual page, you'll see that
notation "
<commit1>..<commit2>
" can be used as a short-hand for "^<commit1> <commit2>
"
which means "list all commits that are included in <commit2>
, but are not included in <commit1>
. And the changes made by D
itself are included in D
commit. So it's not included in list denoted as D..A
.
That's why it's correct to say that git rebase -i D
affects D..HEAD
.
精彩评论