功能分支是合并到主分支中，还是相反？答案

【问题标题】：Is a feature branch merged into the master branch, or the opposite?功能分支是合并到主分支中，还是相反？
【发布时间】：2017-04-21 16:06:29
【问题描述】：

在 GitHub 上，当我从我的功能分支创建拉取请求后，Github 显示了这一点

tim  wants to merge 5 commits into master from feature

然后我解决了一些合并冲突，GitHub 显示

Merge branch 'master' into feature

现在我很困惑，因为我创建的拉取请求是为了将我的功能分支合并到主分支。为什么 GitHub 说反了？ GitHub上这两个矛盾的说法我该如何理解？

谢谢。

【问题讨论】：

用 git 术语来说，没关系，AFAIK。它最终将是相同的两个父母的相同修订。
谢谢。如果分支 A 合并到分支 B 中，那么分支 B 继续存在而分支 A 停止存在，这是否正确？那么切换A分支和B分支的角色是不是不一样呢？
一般的想法是你有一个主分支，比如master和其他特性分支。您应该始终将功能分支合并到主分支。完成后，您通常应该删除功能分支，以便您始终拥有一个基本（主）分支，例如 master 来创建一个新的功能分支，而不是反过来。
@SaugatAcharya 我同意你所说的。但是我该如何理解 GitHub 上两个矛盾的说法呢？
我认为任何一个分支都不会不复存在。如果您正在处理分支 A 并合并 B，则会创建一个新修订版，并且将分支 A 引用移动到此新指针。如果您一直在 B 上工作，那么结果基本相同，只是分支 B 将指向新版本。

标签： git github

【解决方案1】：

您可能在与 github 合并时解决了一些合并冲突。 github显示了特性分支本身的合并冲突的解决（通常解决冲突的最佳实践是在特性分支中解决它们）然后将特性分支合并到master中。

这是一个图表：

master  A - B - C
         \   \ /
feature   E - F

F 提交（解决冲突的地方）是Merge branch 'master' into feature 提交。 C 提交（如果存在——github 可能会选择将你的特性分支快进到 master 上）是将特性分支合并到 master 中。 More information on what "fast forward" means

最后，主分支历史将如下所示：

master A - E - B - F - C

【讨论】：

我不同意最后的说法。非线性原始示例与线性最终版本不同。
我相信你知道一个分支只是一个提交的指针。您可以修改图表以显示每个分支指向的提交吗？所以在第一个图中，master 指向提交 C，feature 指向提交 F。 IMO，您现在拥有它的方式似乎具有误导性。（或者也许我只是习惯了类似于这些的图表中提交名称之后的分支名称......）
我不确定哪些部分具有误导性——时间从左到右，“分支上”的提交列在分支名称的行中
是的，可能只有我一个人。

【解决方案2】：

拉取请求是尝试将您的功能分支合并到项目的 master 分支中。通常，会有必须手动解决的合并冲突。当你这样做时，你应该将当前的master 合并到你的特性分支中。您看到的提交消息将准确地说明这一点。当拉取请求最终确定后，您还将看到一个带有消息“合并来自用户/分支的拉取请求#XYZ”的提交。

【讨论】：

谢谢。你的意思是解决冲突有两个步骤：第一个是将master合并到feature分支中，第二个是将feature合并到master中？如果在 GitHub 上解决冲突，我是否只需要执行第一步，然后 GitHub 会自动执行第二步，完成后会显示消息“Merge Pull Request #XYZ from user/branch”？该消息是否意味着功能与主控的合并完成？
如果解决冲突发生在我的本地机器上，我是否需要明确地执行这两个步骤，而不仅仅是第一步？我可以使用哪些命令来完成这两个步骤？
@Tim 在本地解决合并冲突后，您需要将新提交推送到您自己的 GitHub 存储库。这将使用合并提交自动更新拉取请求。然后你应该等待原始仓库所有者的反馈。他们很可能会要求进行一些改进，以使您的 PR 达到他们的标准。进行改进并再次推动。这个过程可以根据所有者的需要来回循环。
@Tim 一旦 PR 符合所有者的标准，他们会将 PR 合并到他们自己的 master 分支中，此时您将看到带有消息“Merge Pull Request #XYZ from user/branch”的提交.如果你想继续贡献，你应该始终保持你自己的本地 master 和你的 fork 的 master 与原始 repo 保持同步。详情请见this documentation。