我有一个git分支(例如主线),我想合并到另一个开发分支中。还是我?
为了决定我是否真的想合并这个分支,我想看一些合并将做什么的预览。最好能够查看正在应用的提交列表。
到目前为止,我能想到的最好的是合并-no-ff -no-commit,然后diff HEAD。
我有一个git分支(例如主线),我想合并到另一个开发分支中。还是我?
为了决定我是否真的想合并这个分支,我想看一些合并将做什么的预览。最好能够查看正在应用的提交列表。
到目前为止,我能想到的最好的是合并-no-ff -no-commit,然后diff HEAD。
当前回答
如果你已经获取了更改,我最喜欢的是:
git log ...@{u}
这需要git 1.7。x我相信。@{u}符号是上游分支的“速记”,因此它比git log…origin/master更通用。
注意:如果你使用zsh和扩展的glog,你可能需要做一些类似的事情:
git log ...@\{u\}
其他回答
Git日志..将被合并到当前分支的变更的其他分支列表。 Git差异…Otherbranchdiff从共同祖先(合并基)到将要合并的对象的头部。注意这三个点,与两个点相比,这三个点具有特殊的意义(见下文)。 gitk……上次合并后的分支的其他分支图形表示。
空字符串意味着HEAD,所以这就是为什么…而不是HEAD..otherbranch。
两点和三点对于diff和列出修订的命令(log、gitk等)的含义略有不同。对于log和其他两个点(a..b)意味着所有在b中但不是a的东西,三个点(a..b)意味着所有在a或b中只有一个的东西。但diff工作有两个修订,其中由两个点(a..b)表示的更简单的情况是a到b的简单差异,三个点(a..b)意味着共同祖先和b之间的差异(git diff $(git merge-base a b)..b)。
我发现最适合我的解决方案是只执行合并并在发生冲突时中止它。在我看来,这种特殊的语法干净而简单。这就是下面的策略2。
然而,如果你想确保你不会弄乱你当前的分支,或者你只是没有准备好合并而不管冲突的存在,简单地创建一个新的子分支并合并它:
策略1:安全的方法——合并一个临时分支:
git checkout mybranch
git checkout -b mynew-temporary-branch
git merge some-other-branch
这样,如果您只是想看看冲突是什么,您可以简单地丢弃临时分支。您不需要麻烦地“中止”合并,并且您可以回到您的工作—只需再次签出'mybranch',您将不会在分支中有任何合并的代码或合并冲突。
这基本上是一次演练。
策略2:当你确实想要合并时,但前提是没有冲突
git checkout mybranch
git merge some-other-branch
如果git报告冲突(且仅当存在冲突时),你可以这样做:
git merge --abort
如果合并成功,则不能中止它(只能重置)。
如果您还没有准备好合并,请使用上面更安全的方法。
[编辑:2016年11月-我把策略1换成了策略2,因为似乎大多数人都在寻找“安全的方式”。策略2现在更多的是说明,如果合并有您还没有准备好处理的冲突,您可以简单地中止合并。请记住,如果阅读评论!]
如果你已经获取了更改,我最喜欢的是:
git log ...@{u}
这需要git 1.7。x我相信。@{u}符号是上游分支的“速记”,因此它比git log…origin/master更通用。
注意:如果你使用zsh和扩展的glog,你可能需要做一些类似的事情:
git log ...@\{u\}
Pull Request——我已经使用了大部分已经提交的想法,但我也经常使用的一个想法是(尤其是来自其他开发人员的想法)做一个Pull Request,它提供了一种方便的方法,可以在合并发生之前检查所有的更改。我知道这是GitHub不是git,但它肯定是方便的。
除了以一种丢弃的方式实际执行合并之外(参见Kasapo的回答),似乎没有一种可靠的方式来看待这一点。
话虽如此,这里有一个稍微接近的方法:
git log TARGET_BRANCH...SOURCE_BRANCH --cherry
这很好地说明了哪些提交将进入合并。要查看diff,请添加-p。要查看文件名,可以添加——raw、——stat、——name-only、——name-status中的任意一个。
git diff TARGET_BRANCH的问题…SOURCE_BRANCH方法(参见Jan Hudec的回答)是,如果您的源分支包含交叉合并,则您将在目标分支中看到已经发生的更改的差异。