假设我有一个名为feat-123
的特性分支,它比master提前24次提交,落后10次提交。
场景1
- 我用
master
重新设置这个分支并解决合并冲突,所以它现在提前24次提交,落后0次提交。 - 我把这个分支推到GitHub,打开一个pull request,然后点击
Squash and merge
。 - 所有工作浓缩为一次提交,并添加到
master
的提交历史中。 场景2
- 我在
feat-123
上做git pull origin master
并解决合并冲突 - 我把这个分支推到GitHub,打开一个pull request,然后点击
Squash and merge
。 - 所有的工作浓缩为一次提交,并添加到
master
的提交历史。
在上面的场景中,在这两个实例中,我最终都提交了一个包含所有工作的提交。我是在为自己增加额外的工作,还是有好处?
我是否通过重新定位为自己创造了额外的工作,或者仍然有好处?
根据冲突的数量和类型:是
是否合并或重基对存储库的结果状态无关紧要(假设冲突被正确地解决并且与这两个操作相同)。tip提交将包含两个场景中分支和主分支的所有更改。
如果你在重基分支和合并分支之间运行git diff
,你应该不会看到任何差异。
你甚至可以在具体的repo中尝试一下:
git branch test-merge feat-123
git branch test-rebase feat-123
git checkout test-merge
git merge master
# resolve conflicts
git rebase master test-rebase
# resolve conflicts
git diff test-merge test-rebase
# you should not see any output