Question

我有两个开发人员同时工作，一个在master（dev1）上，另一个在另一个分支上（dev2）。主人被视为“主线”。 Dev1定期合并dev2分支的更改，如下所示：

git checkout master
git merge origin/branch1
git push origin master

这会将分支与主服务器合并以进行部署，但dev2也希望在合并完成后从主服务器获取最新更改。我认为这是最好的方法：

git checkout branch1
git rebase master

这是对的吗？

在Github中，我注意到他们正在处理的分支不再出现，也没有人删除它。我非常确定rebase或merge不会删除分支，除非你告诉它。别的我知道了。

基本上，图表看起来像：

     b1  b2   b3 b4...
    /      \ /     \
   m1   m2  m3  m4  m5...

m3和m5分别是dev1将合并b2和b4的地方。

Answer 1

只有在dev2重新定位未发布的提交时，才会生效。

但dev2已重新提交的提交已经推送到原点（并且可能已经由dev1合并到master），那么这不是正确的方法，因为SHA1已更改，并且branch1 dev1的下一次合并不仅会合并新的提交，还会所有提交，即使是那些已合并的提交。

在这种特定情况下，dev2需要合并 master与git merge master - 这样可以避免这些问题。

Answer 2

Github没有向您展示合并的分支机构使用：

git branch --merged

列出所有合并的分支

您可以使用

git log --graph

查看提交图以查看每个分支的合并位置

Answer 3

在对此进行了一些研究后，我确实发现了一篇博文，似乎完全涵盖了我最初在问题中提出的问题：http://mettadore.com/analysis/a-simple-git-rebase-workflow-explained/。也就是说，不合并，而是将主分支与主分支重新组合，反之亦然。主要区别在于您不会推送本地分支。

这种方法的主要原因是它会在主服务器中保留您的分支历史记录，并在“当一个以上的人在分支机构上工作时防止出现问题”，因为如果其他人将合并的主分支拉为你正在拉动主分支进行合并吗？“

我将此添加为另一种可能的选项，但如果有人发现博客中描述的问题，我会很好奇。

Git Merge：2名开发人员合并彼此的变化

3 个答案: