我们发现执行git变基而不是Visual Studio（2019，Enterprise）变基时会得到不同的结果。请注意，我们是git的新手
我们有一个名为（例如）SomeFeature的分支，然后我们在该分支上工作的人有自己的分支：
Mike处理SomeFeature_mike，进行更改，发出拉取请求，然后将其工作添加到SomeFeature中，托尼现在想在SomeFeature的基础上改头换面，以便他获得Mike的更改
使用Visual Studio有时会出现合并错误，但是我们不确定为什么。如果相反，我们这样做
git checkout SomeFeature_tony
git rebase origin/SomeFeature
然后它似乎可以工作
怀疑是在重新设置基准并进行同步之后，我们并没有强行推动SomeFeature_tony分支，但这并不能回答核心问题，为什么Visual Studio所做的事情与git不同？
答案 0 :(得分：0)
在执行“ git merge”之前执行“ git rebase”并不完全等同于直接进行“ git merge”。特别是如果您与快进合并（这将使合并的[master]分支保持整洁：））。
a-b-c-d [master]
\x-y-z [feature]
直接合并
a-b-c-d--m [master]
\x-y-z/ [feature]
变基+合并
1) rebase
a-b-c-d [master]
\x-y-z [feature]
2) merge
a-b-c-d-x-y-z [master & feature]
在“直接合并”和“ rebase +合并”中看到合并约束的方式有些不同（即使最终状态为“应该”相同）。 在一种情况下，您将所有修改从两侧应用到公共点并检查冲突。 在另一种情况下，您将修改增量移动到新位置。
我建议使用最后一种解决方案，因为它可以在合并后进行测试，就像合并后一样。
我建议您阅读https://www.atlassian.com/git/tutorials/comparing-workflows
因此，即使在合并之前对IDE进行了基准调整，也可以获得与cmd行类似的结果。请注意，您的IDE可能设置了很多选项，可能会影响git命令。
答案 1 :(得分：0)
在我看来，我认为Visual Studio的“ rebase”选项和“ git rebase”之间没有区别。但是“ merge”与“ rebase”不同。
当您将SomeFeature_tony合并到SomeFeature时，它将合并SomeFeature分支与您在SomeFeature_tony中的当前提交并形成新的提交，就像下面的图片一样： enter image description here
重新设置基准时，它将在SomeFeature之后进行SomeFeature_tony的提交。就像下面的图片： enter image description here
将一个分支合并到另一个分支时，一个分支中提交的文件更改可能与另一个分支冲突。您可以像在Visual Studio中解析merge conflicts一样来解决它。您也可以执行'git添加”以暂存合并的更改，然后使用“ git rebase --continue”继续进行重新设置。
希望获得帮助，祝您愉快：）
