Git 将 master 合并到功能分支中

让我们说我们在 git 中有以下情况：

创建的存储库：
```
mkdir GitTest2
cd GitTest2
git init
```

主服务器中的一些修改发生并得到提交。

echo "On Master" > file
git commit -a -m "Initial commit"

Feature1 分支主，一些工作完成：

git branch feature1
git checkout feature1
echo "Feature1" > featureFile
git commit -a -m "Commit for feature1"

同时，在主代码中发现错误并建立了修补程序分支
```
git checkout master
git branch hotfix1
git checkout hotfix1
```
该错误在修补程序分支中修复并合并回主服务器（可能在拉取请求 / 代码审查之后）：
```
echo "Bugfix" > bugfixFile
git commit -a -m "Bugfix Commit"
git checkout master
git merge --no-ff hotfix1
```
feature1 的开发继续：
```
git checkout feature1
```

现在我的问题：说我需要我的功能分支中的修补程序，可能是因为那里也出现了错误。如何在不将提交复制到我的功能分支的情况下实现此目的？我想阻止在我的功能分支上获得两个与功能实现无关的新提交。如果我使用 Pull 请求，这对我来说尤其重要：所有这些提交也将包含在 Pull Request 中，并且必须进行审核，尽管已经完成（因为修补程序已经在主服务器中）。

我不能做一个git merge master --ff-only ：“致命：不可能快进，中止。” 但是我不确定这是否对我有帮助。

如何将主分支合并到功能分支？简单：

git checkout feature1
git merge master

在这里强制进行快速合并是没有意义的，因为它无法完成。您已将两者都提交到功能分支和主分支。快进现在是不可能的。

看看gitflow 。它是 git 的分支模型，可以遵循，你无意识地已经做到了。它也是 git 的扩展，它为新的工作流程步骤添加了一些命令，这些命令会自动执行，否则您需要手动执行这些操作。

那么你在工作流程中做了什么？你有两个分支可以使用，你的 feature1 分支基本上是 gitflow 模型中的 “develop” 分支。

您从 master 创建了一个修补程序分支并将其合并。现在你被卡住了。

gitflow 模型要求您将修补程序也合并到 devel 分支，在您的情况下为 “feature1”。

所以真正的答案是：

git checkout feature1
git merge --no-ff hotfix1

这会将修补程序内部所做的所有更改添加到功能分支，但仅包括这些更改。它们可能与分支中的其他开发更改冲突，但如果最终将功能分支合并回 master，它们将不会与主分支冲突。

变基础时要非常小心。只有在您所做的更改保留在存储库本地时才进行 rebase，例如，您没有将任何分支推送到其他存储库。重新定位是一个很好的工具，可以让你将本地提交安排到一个有用的顺序，然后再将其推向世界，但之后的重新定位会让像你这样的 git 初学者陷入困境。

你应该能够在 master 上重新分支你的分支：

git checkout feature1
git rebase master

管理出现的所有冲突。当你使用错误修正（已经在 master 中）进行提交时，git 会说没有任何更改，也许它们已经应用了。然后继续使用 rebase（同时跳过已在 master 中的提交）

git rebase --skip

如果您在功能分支上执行git log ，您将看到错误修正提交仅出现一次，并且在主要部分中。

有关更详细的讨论，请查看git rebase （ https://git-scm.com/docs/git-rebase ）上的 Git 书籍文档，其中涵盖了这个确切的用例。

================ 编辑其他上下文 ====================

这个答案专门针对 @theomega 提出的问题提出，考虑到他的特殊情况。注意这部分：

我想阻止我的功能分支上的提交与功能实现无关。

将他的私人分支重新绑定在主人身上正是产生这种结果的原因。相比之下，将 master 合并到他的分支中将准确地完成他特别不希望发生的事情 ：添加一个与他正在通过他的分支工作的功能实现无关的提交。

为了解决阅读问题标题的用户，跳过问题的实际内容和上下文，然后盲目地阅读最佳答案，假设它将始终适用于他们（不同的）用例，请允许我详细说明：

只改变私人分支机构（即只存在于您的本地仓库中并且未与其他分支机构共享）。重新分享共享分支将 “破坏” 其他人可能拥有的副本。
如果你想将分支（无论是主分支还是其他分支）的变化集成到一个公共分支中（例如，你已经推动分支打开一个拉取请求，但现在与 master 有冲突，你需要更新你的分支来解决这些冲突）你需要将它们合并（例如在 @Sven 的答案中使用git merge master ）。
如果这是您的偏好，您也可以将分支合并到您的本地私有分支，但请注意，它将导致您的分支中的 “外部” 提交。

最后，如果您对这个答案不是最适合您的情况这一事实感到不满意，即使它是 @theomega，在下面添加评论也不会特别有用：我无法控制选择哪个答案，只有 @theomega。

基于这篇文章你应该：

创建基于新版本 master 的新分支
将旧功能分支合并到新功能分支中
解决新功能分支上的冲突

这样，您的历史记录保持清晰，因为您不需要反向合并。而且你不需要如此超级谨慎，因为你不需要 git rebase