我不确定这是否是正常的分支场景，但是...
假设我从 master 创建了一个分支，比如分支 C，然后将其他先前存在的分支，比如分支 A 和 B，合并回 master，然后我需要分支 C 中的 A 和 B 的一些代码我可以从 master 合并到分支 C 吗？
如果是这样，是否有任何理由说明这不是一个好主意？这是git中常见的操作吗？
【问题讨论】：
标签： git merge branch branching-and-merging
除非分支 C 被大量共享，即被其他用户从上游 repo 中提取，我仍然支持Alex 的answer 中提到的rebase 方法。
Rebase first (C on top of master), merge later (C on master)。
如果您在C 中只有一些A 和B 提交，cherry-picking 将是解决方案，但正如我在“Use GIT fork / branches”中提到的（在它的末尾)，cherry-pick 有缺点。
【讨论】：
是的，是的。
你可以在 git 中以任何你喜欢的方式合并。合并只是意味着“结合这些历史”。当 git 不能时，它的默认模式只是将更改转储给您，即“合并冲突”，但您也可以更改该行为以倾向于“我们的”或“他们的”。查看git-merge 文档，了解数百个选项的完整说明...
因此，根据您的解释，历史图表可能如下所示：
*-------*-------*------* master
|
*----*-----* A
|
*-------* B
|
*----* C
* 只是该分支上的一些提交，除了它们都被创建的地方。那么你如何解决这个问题呢？好吧，我会：
git checkout A
在 A 上，基本上我们要像这样将 A 合并到 master 中：
git merge master
这样做有充分的理由 - 当呈现给另一个开发人员时，假设合并是准确的，这对他们来说代表了一个简单的快进合并。换句话说，将 A 合并到其他人存储库中的实际主服务器中，这变得更容易了。现在，您或其他开发人员可以执行的下一步：
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，所以如果你没有跟踪别人的分支，你仍然可以像这样应用合并：
他们可以使用git merge leaddeveloper/master，其中leaddeveloper 是一个远程名称。然后他们可以纠正任何冲突，向首席开发人员发送电子邮件说“请拉”，然后首席开发人员可以输入 git fetch && git merge juniordeveloper1/somebranch 或更可能是 git fetch && git diff master..juniordeveloper1/somebranch 来确定他们首先做了什么。
简而言之，我认为这是管理项目的一种非常好的方式。它使每个人都保持最新状态，并确保处理主要 master 的人也没有集成代码的工作。
关于 git rebase 的问题，this question 处理得非常巧妙。
【讨论】：
绝对是正常情况。这就是你想要做的：
$ git checkout your-branch
$ git rebase master
为了更好地理解变基，这里有一个例子。假设这是您的提交历史记录：
H--I--J [branch C]
/
A--B--C--D--E--F--G [master]
如您所见，自您创建分支以来，master 已经进行了多次新提交。
如果您根据 master 重新定位您的分支，那么该历史现在将如下所示：
H'--I'--J' [branch C]
/
A--B--C--D--E--F--G [master]
现在分支 C 是最新的，并且包含了自您最初创建分支以来的所有更改。
资源：
【讨论】：
这是一个很正常的操作。
git checkout C
git merge master
是否会采用通常的方式来执行此操作（如果您已经在此分支上，则可以省略第一个）。
Alex 提到的rebase 命令是一种替代方法，但这有其他结果。 （实际上，您的分支获得了更线性的历史记录，但是在变基之前（以及在原始分支之后）在 C 上的所有旧提交现在都有其他名称（提交 ID），因为它们在 A 和 B 中都有提交他们的祖先。）
【讨论】：