本文翻译自：Git merge master into feature branch
Let's say we have the following situation in Git: 假设我们在Git中有以下情况：
A created repository: 创建的存储库：
mkdir GitTest2 cd GitTest2 git initSome modifications in the master take place and get committed. 在主服务器中进行一些修改并落实。
echo "On Master" > file git commit -a -m "Initial commit"Feature1 branched off master and some work is done: Feature1从master分支出来，并完成了一些工作：
git branch feature1 git checkout feature1 echo "Feature1" > featureFile git commit -a -m "Commit for feature1"Meanwhile, a bug is discovered in the master-code and a hotfix-branch is established 同时，在主代码中发现一个错误并建立了一个热修复分支。
git checkout master git branch hotfix1 git checkout hotfix1The bug is fixed in the hotfix branch and merged back into the master (perhaps after a pull request/code review): 该错误已在hotfix分支中修复，并重新合并到master中（可能在请求请求/代码审查之后）：
echo "Bugfix" > bugfixFile git commit -a -m "Bugfix Commit" git checkout master git merge --no-ff hotfix1Development on feature1 continues: 继续对feature1进行开发：
git checkout feature1
Say I need the hotfix in my feature branch, maybe because the bug also occurs there. 假设我在功能分支中需要此修补程序，也许是因为该错误也发生在这里。 How can I achieve this without duplicating the commits into my feature branch? 如何在不将提交复制到功能分支的情况下实现此目标？
I want to prevent to get two new commits on my feature branch which have no relation to the feature implementation. 我想防止在功能分支上获得两个与功能实现无关的新提交。 This especially seems important for me if I use pull requests: All these commits will also be included in the pull request and have to be reviewed although this has already been done (as the hotfix is already in the master). 如果我使用拉取请求，这对我来说尤其重要：所有这些提交也将包含在拉取请求中，尽管已经完成（因为此修补程序已在主服务器中），但必须进行审查。
I can not do a git merge master --ff-only : "fatal: Not possible to fast-forward, aborting.", but I am not sure if this helped me. 我不能做一个git merge master --ff-only ：“致命的：不可能快速前进，中止。”但是我不确定这是否对我有帮助。
#1楼
参考：https://stackoom.com/question/1991Y/Git将主合并到功能分支
#2楼
You should be able to rebase your branch on master: 您应该能够基于master重新建立分支：
git checkout feature1
git rebase master
Manage all conflicts that arise. 处理所有出现的冲突。 When you get to the commits with the bugfixes (already in master), Git will say that there were no changes and that maybe they were already applied. 当您获得带有错误修正的提交（已经在master中）时，Git会说没有任何更改，并且也许它们已经被应用。 You then continue the rebase (while skipping the commits already in master) with 然后，您可以继续进行变基（同时跳过已在主数据库中的提交）
git rebase --skip
If you perform a git log on your feature branch, you'll see the bugfix commit appear only once, and in the master portion. 如果在功能分支上执行git log ，您将看到bugfix提交仅出现一次，并且出现在master部分中。
For a more detailed discussion, take a look at the Git book documentation on git rebase ( https://git-scm.com/docs/git-rebase ) which cover this exact use case. 有关更详细的讨论，请参阅有关git rebase的Git书籍文档（ https://git-scm.com/docs/git-rebase ），其中涵盖了此确切的用例。
================ Edit for additional context ==================== ===============编辑其他上下文====================
This answer was provided specifically for the question asked by @theomega, taking his particular situation into account. 考虑到他的特殊情况，专门针对@theomega提出的问题提供了此答案。 Note this part: 注意这一部分：
I want to prevent [...] commits on my feature branch which have no relation to the feature implementation. 我想防止我的功能分支上的提交与功能实现无关。
Rebasing his private branch on master is exactly what will yield that result. 将他的私人分支机构重新建立在master上正是产生此结果的原因。 In contrast, merging master into his branch would precisely do what he specifically does not want to happen : adding a commit that is not related to the feature implementation he is working on via his branch. 相反，将master合并到他的分支中将恰好完成他明确不希望发生的事情 ：添加与他正在通过其分支进行的功能实现无关的提交。
To address the users that read the question title, skip over the actual content and context of the question, and then only read the top answer blindly assuming it will always apply to their (different) use case, allow me to elaborate: 要解决阅读问题标题的用户的问题，请跳过问题的实际内容和上下文，然后仅假设其将始终适用于他们的（不同）用例，而盲目阅读最高答案，请允许我详细说明：
- only rebase private branches (ie that only exist in your local repository and haven't been shared with others). 仅对私有分支重新设置基础（即仅存在于本地存储库中且未与其他分支共享）。 Rebasing shared branches would "break" the copies other people may have. 重新分配共享分支机构将“破坏”其他人可能拥有的副本。
- if you want to integrate changes from a branch (whether it's master or another branch) into a branch that is public (eg you've pushed the branch to open a pull request, but there are now conflicts with master, and you need to update your branch to resolve those conflicts) you'll need to merge them in (eg with
git merge masteras in @Sven's answer). 如果您要将更改从分支（无论是主分支还是其他分支）集成到公共分支（例如，您已推送分支以打开拉取请求，但现在与主冲突，则需要更新）您的分支机构来解决这些冲突），您需要将其合并（例如，使用@@ Sven的答案中的git merge master）。 - you can also merge branches into your local private branches if that's your preference, but be aware that it will result in "foreign" commits in your branch. 如果您愿意，也可以将分支合并到本地私有分支中，但是请注意，这将导致分支中的“外部”提交。
Finally, if you're unhappy with the fact that this answer is not the best fit for your situation even though it was for @theomega, adding a comment below won't be particularly helpful: I don't control which answer is selected, only @theomega does. 最后，如果您对这个答案并非最适合您的情况感到不满意，尽管它适用于@theomega，则在下面添加评论不会特别有帮助：我不控制选择哪个答案，只有@theomega。
#3楼
How do we merge the master branch into the feature branch? 我们如何将master分支合并到feature分支？ Easy: 简单：
git checkout feature1
git merge master
There is no point in forcing a fast forward merge here, as it cannot be done. 在此处强制快速向前合并没有意义，因为它无法完成。 You committed both into the feature branch and the master branch. 您已同时提交到功能分支和主分支。 Fast forward is impossible now. 现在快进是不可能的。
Have a look at GitFlow . 看看GitFlow 。 It is a branching model for git that can be followed, and you unconsciously already did. 它是git的分支模型，可以遵循，而您不知不觉已经做到了。 It also is an extension to Git which adds some commands for the new workflow steps that do things automatically which you would otherwise need to do manually. 它也是Git的扩展，它为新的工作流程步骤添加了一些命令，这些命令会自动执行您原本需要手动执行的操作。
So what did you do right in your workflow? 那么您在工作流程中做了什么呢？ You have two branches to work with, your feature1 branch is basically the "develop" branch in the GitFlow model. 您有两个分支可以使用，feature1分支基本上是GitFlow模型中的“ develop”分支。
You created a hotfix branch from master and merged it back. 您从master创建了一个修补程序分支，并将其合并回去。 And now you are stuck. 现在你被困住了。
The GitFlow model asks you to merge the hotfix also to the development branch, which is "feature1" in your case. GitFlow模型要求您还将修补程序也合并到开发分支，在您的情况下为“ feature1”。
So the real answer would be: 因此，真正的答案将是：
git checkout feature1
git merge --no-ff hotfix1
This adds all the changes that were made inside the hotfix to the feature branch, but only those changes. 这会将在修补程序内部进行的所有更改添加到功能分支，但仅添加那些更改。 They might conflict with other development changes in the branch, but they will not conflict with the master branch should you merge the feature branch back to master eventually. 它们可能与分支中的其他开发更改冲突，但是如果最终将功能分支合并回master，则它们不会与master分支冲突。
Be very careful with rebasing. 重新定基时要非常小心。 Only rebase if the changes you did stayed local to your repository, eg you did not push any branches to some other repository. 仅当您所做的更改仍位于存储库本地时（例如，您没有将任何分支推送到其他存储库），才重新设置基准。 Rebasing is a great tool for you to arrange your local commits into a useful order before pushing it out into the world, but rebasing afterwards will mess up things for the git beginners like you. Rebasing是一个很棒的工具，可让您在将本地提交提交到世界之前将其本地排列成有用的顺序，但是事后重新打包将使像您这样的git初学者感到困惑。
#4楼
You might be able to do a "cherry-pick" to pull the exact commit(s) that you need in to your feature branch. 您可能可以执行“选择”操作，以将所需的确切提交拖到功能分支中。
Do a git checkout hotfix1 to get on the hotfix1 branch. 进行git checkout hotfix1进入hotfix1分支。 Then do a git log to get the SHA-1 hash (big sequence of random letters and numbers that uniquely identifies a commit) of the commit in question. 然后执行git log以获取相关提交的SHA-1哈希值（包含唯一标识提交的随机字母和数字的大序列）。 Copy that (or the first 10 or so characters). 复制该字符（或前10个左右的字符）。
Then, git checkout feature1 to get back onto your feature branch. 然后， git checkout feature1返回到您的功能分支。
Then, git cherry-pick <the SHA-1 hash that you just copied> 然后， git cherry-pick <the SHA-1 hash that you just copied>
That will pull that commit, and only that commit, into your feature branch. 这将把那个提交，并且只有那个提交，拉到你的功能分支中。 That change will be in the branch - you just "cherry-picked" it in. Then, resume work, edit, commit, push, etc. to your heart's content. 所做的更改将在分支中-您只需“选择”它即可。然后，恢复工作，编辑，提交，推送等内容。
When, eventually, you perform another merge from one branch into your feature branch (or vice-versa), Git will recognize that you've already merged in that particular commit, know that it doesn't have to make it again, and just "skip over" it. 最终，当您执行从一个分支到功能分支的另一次合并时（反之亦然），Git将识别出您已经在该特定提交中进行了合并，知道它不必再次进行合并，而只是“跳过”它。
#5楼
Based on this article , you should: 根据本文 ，您应该：
create new branch which is based upon new version of master 创建基于主版本的新分支
git branch -b newmastermerge your old feature branch into new one 将您的旧功能分支合并到新分支
git checkout newmasterresolve conflict on new feature branch 解决新功能分支上的冲突
The first two commands can be combined to git checkout -b newmaster . 前两个命令可以合并到git checkout -b newmaster 。
This way your history stays clear because you don't need back merges. 这样，您的历史记录就很清晰，因为您不需要回溯合并。 And you don't need to be so super cautious since you don't need to do a Git rebase. 而且，您不需要非常谨慎，因为您不需要执行Git重新设置。
#6楼
Zimi's answer describes this process generally. Zimi的回答大致描述了此过程。 Here are the specifics: 具体细节如下：
Create and switch to a new branch. 创建并切换到新分支。 Make sure the new branch is based on
masterso it will include the recent hotfixes. 确保新分支基于master因此它将包括最新的修补程序。git checkout master git branch feature1_new git checkout feature1_new # Or, combined into one command: git checkout -b feature1_new masterAfter switching to the new branch, merge the changes from your existing feature branch. 切换到新分支后，请合并现有功能分支中的更改。 This will add your commits without duplicating the hotfix commits. 这将添加您的提交，而不复制修补程序提交。
git merge feature1On the new branch, resolve any conflicts between your feature and the master branch. 在新分支上，解决功能部件与主分支之间的所有冲突。
Done! 做完了！ Now use the new branch to continue to develop your feature. 现在，使用新分支继续开发您的功能。
