在git中，在新代码添加到master后，是否可以从master合并到最初从master创建的分支？

Question

我不确定这是否是正常的分支场景，但是......

假设我从 master 创建一个分支，比如分支 C，然后将其他先前存在的分支，比如分支 A 和 B，合并回 master，然后我需要分支 C 中 A 和 B 的一些代码，那么我可以从 master 合并到分支 C 吗？

如果是这样，是否有任何理由表明这不是一个好主意？这是git中的常见操作吗？

Answer 1

是的，是的。

您可以在 git 中以任何您喜欢的方式进行合并。合并简单的意思是“合并这些历史”。当 git 不能时，它的默认模式是仅将更改转储给您，这是“合并冲突”，但您也可以更改该行为以倾向于“我们的”或“他们的”。看看 git-merge文档以获取数百个选项的完整解释...

因此，根据您的解释，历史图可能如下所示：

*-------*-------*------* master
        |
        *----*-----* A
        |
        *-------* B
        |
        *----* C

其中 * 只是该分支上的一些提交，除了它们'重新创建。那么如何解决这个问题呢？好吧，我会：

git checkout A

在 A 上，基本上我们将像这样将 A 合并到 master 中：

git merge master

这样做有一个很好的理由 - 当呈现给另一个开发人员时，假设合并是准确的，这代表了一个简单的快速-为他们进行前向合并。换句话说，将 A 合并到其他人存储库中的实际 master 中，这会变得更容易。现在，下一步，您或其他开发人员可以执行以下操作：

git checkout master && git merge A

引入 A。它基本上应该完全没有合并冲突，因为将 master 合并到 A 的过程解决了这些冲突，并且负责集成 A 的开发人员处理了它。

所以

git checkout B && git merge master

话又说回来，解决合并问题，然后 git checkout master && git merge B

最后，你是说我可以将 master 合并到 C 中吗？绝对地。我们刚刚完成了这个过程两次。

我们在工作中使用这种特殊的做事方式。基本上，我让其他开发人员让我知道他们的分支何时准备好，然后我将它们合并，然后每个人将 master 合并到他们的分支中，然后重复该过程。您甚至可以使用远程存储库来执行此操作。如果您在远程有跟踪分支，git pull 会拉取您的更改。这实际上是一个 git fetch 后跟一个 git merge，因此，如果您没有跟踪其他人的分支，您仍然可以像这样应用合并：

他们可以这样做 < code>git merge Leaddeveloper/master 其中 leaddeveloper 是远程名称。然后他们可以纠正任何冲突，向首席开发人员发送电子邮件说“请拉取”，然后首席开发人员可以输入 git fetch && git merge Juniordeveloper1/somebranch 或更可能的是 git fetch && git diff master..juniordeveloper1/somebranch 来弄清楚他们首先做了什么。

简而言之，我认为这是管理项目的一种非常好的方法。它让每个人都了解最新情况，并确保处理主要主控的人员不必承担集成代码的工作。

关于 git rebase 的主题，这个问题 处理得非常巧妙。

Answer 2

这是一个很正常的操作。

git checkout C
git merge master

通常的方法是这样做（如果你已经在这个分支上，你可以省略第一个）。

Alex 提到的 rebase 命令是一种替代方法，但这有其他结果。 （实际上，您的分支会获得更线性的历史记录，但是在变基之前（以及原始分支之后）C 上的所有旧提交现在都有其他名称（提交 ID），因为它们在 A 和 B 中都有提交他们的祖先。）

Answer 3

绝对是正常情况。这就是您想要做的：

$ git checkout your-branch
$ git rebase master

为了更好地理解变基，这里有一个示例。假设这是您的提交历史记录：

        H--I--J [branch C]
       /
A--B--C--D--E--F--G [master]

如您所见，自从您创建分支以来，master 已有多个新提交。

如果您根据主分支重新调整分支的基础，那么历史记录现在将如下所示：

                    H'--I'--J' [branch C]
                   /
A--B--C--D--E--F--G [master]

现在分支 C 是最新的，并且包含自您最初创建分支以来的所有更改。

资源：

http://book.git-scm.com/4_rebasing。 html

http://kernel.org/pub/software/scm/git/docs/git-rebase.html

Answer 4

除非分支 C 被大量共享，即由其他用户从上游存储库中提取，否则我仍然倾向于 Alex 的答案。
首先变基（C 位于master），稍后合并（master 上的 C）。

如果您只有 C 中需要的 A 和 B 提交，cherry-picking 是解决方案，但正如我在“使用 GIT 分支/分支"（在最后），cherry-pick 有缺点。