开发者

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜