将 Git 分支合并到 master 的最佳（和最安全）方法是什么？

What is the best (and safest) way to merge a Git branch into master?

提问by moe

A new branch from masteris created, we call it test.

master创建了一个新分支，我们称之为test。

There are several developers who either commit to masteror create other branches and later merge into master.

有几个开发人员提交master或创建其他分支，然后合并到master.

Let's say work on testis taking several days and you want to continuously keep testupdated with commits inside master.

假设工作test需要几天时间，并且您希望不断test更新内部的提交master。

I would do git pull origin masterfrom test.

我会git pull origin master从test.

Question 1:Is this the right approach? Other developers could have easily worked on same files as I have worked btw.

问题 1：这是正确的方法吗？顺便说一句，其他开发人员可以轻松地处理与我工作相同的文件。

---

---

My work on testis done and I am ready to merge it back to master. Here are the two ways I can think of:

我的工作test已完成，我准备将其合并回master. 以下是我能想到的两种方法：

A:

A：

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

乙：

git checkout test
git pull origin master
git checkout master
git merge test

I am not using --rebasebecause from my understanding, rebase will get the changes from masterand stack mine on top of that hence it could overwrite changes other people made.

我没有使用，--rebase因为根据我的理解，rebase 会从中获取更改master并将我的更改叠加在其上，因此它可能会覆盖其他人所做的更改。

Question 2:Which one of these two methods is right? What is the difference there?

问题2：这两种方法哪一种是正确的？有什么区别？

The goal in all of this is to keep my testbranch updated with the things happening in masterand later I could merge them back into masterhoping to keep the timeline as linear as possible.

所有这些的目标是让我的test分支更新发生的事情，master然后我可以将它们合并回来，master希望尽可能保持时间线的线性。

回答by KingCrunch

How I would do this

我将如何做到这一点

git checkout master
git pull origin master
git merge test
git push origin master

If I have a local branch from a remote one, I don't feel comfortable with merging other branches than this one with the remote. Also I would not push my changes, until I'm happy with what I want to push and also I wouldn't push things at all, that are only for me and my local repository. In your description it seems, that testis only for you? So no reason to publish it.

如果我有一个来自远程分支的本地分支，我不喜欢将除此分支之外的其他分支与远程分支合并。此外，我不会推送我的更改，直到我对我想要推送的内容感到满意并且我根本不会推送仅适用于我和我的本地存储库的内容。在您的描述中，似乎test只适合您？所以没有理由发布它。

git always tries to respect yours and others changes, and so will --rebase. I don't think I can explain it appropriately, so have a look at the Git book - Rebasingor git-ready: Intro into rebasingfor a little description. It's a quite cool feature

git 总是试图尊重你和其他人的变化，所以--rebase. 我不认为我可以适当地解释它，所以看看Git 书 - Rebasingor git-ready: Intro to rebaseing以获得一些描述。这是一个很酷的功能

回答by John Yin

This is a very practical question, but all the answers above are not practical.

这是一个很实际的问题，但是上面所有的答案都不实际。

Like

喜欢

git checkout master
git pull origin master
git merge test
git push origin master

This approach has two issues:

这种方法有两个问题：

1. It's unsafe, because we don't know if there are any conflicts between test branch and master branch.

2. It would "squeeze" all test commits into one merge commit on master; that is to say on master branch, we can't see the all change logs of test branch.

1. 这是不安全的，因为我们不知道 test 分支和 master 分支之间是否存在冲突。

2. 它会将所有测试提交“压缩”到 master 上的一个合并提交中；也就是说在master分支上，我们看不到test分支的所有变更日志。

So, when we suspect there would some conflicts, we can have following git operations:

因此，当我们怀疑会有一些冲突时，我们可以进行以下 git 操作：

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Test mergebefore commit, avoid a fast-forward commit by --no-ff,

merge之前测试commit，避免快进提交--no-ff，

If conflict is encountered, we can run git statusto check details about the conflicts and try to solve

如果遇到冲突，我们可以运行git status查看冲突的详细信息并尝试解决

git status

Once we solve the conflicts, or if there is no conflict, we commitand pushthem

一旦我们解决了冲突，或者如果没有冲突，我们commit和push他们

git commit -m 'merge test branch'
git push

But this way will lose the changes history logged in test branch, and it would make master branch to be hard for other developers to understand the history of the project.

但是这种方式会丢失 test 分支中记录的变更历史，并且会使 master 分支其他开发人员难以了解项目的历史。

So the best method is we have to use rebaseinstead of merge(suppose, when in this time, we have solved the branch conflicts).

所以最好的方法是我们必须使用rebase而不是merge（假设，在这个时候，我们已经解决了分支冲突）。

Following is one simple sample, for advanced operations, please refer to http://git-scm.com/book/en/v2/Git-Branching-Rebasing

下面是一个简单的示例，高级操作请参考http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Yep, when you have uppers done, all the Test branch's commits will be moved onto the head of Master branch. The major benefit of rebasing is that you get a linear and much cleaner project history.

是的，当您完成上层工作后，所有 Test 分支的提交都将移动到 Master 分支的头部。变基的主要好处是您可以获得线性且更清晰的项目历史记录。

The only thing you need to avoid is: never use rebaseon public branch, like master branch.

您唯一需要避免的是：永远不要rebase在公共分支上使用，例如 master 分支。

Never do operationslike the following:

切勿执行以下操作：

git checkout master
git rebase -i test

Details for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing 的详细信息

appendix:

附录：

• if you are not sure about rebasing operations, please refer to: https://git-scm.com/book/en/v2/Git-Branching-Rebasing

• 如果对rebase操作不清楚，请参考：https: //git-scm.com/book/en/v2/Git-Branching-Rebasing

回答by raylu

Neither a rebase nor a merge should overwrite anyone's changes (unless you choose to do so when resolving a conflict).

变基或合并都不应覆盖任何人的更改（除非您在解决冲突时选择这样做）。

The usual approach while developing is

开发时通常的方法是

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

When you're ready to merge back into master,

当您准备好合并回 master 时，

git checkout master
git log ..test # if you're curious
git merge test
git push

If you're worried about breaking something on the merge, git merge --abortis there for you.

如果您担心在合并时破坏某些内容，git merge --abort那么您可以使用它。

Using push and then pull as a means of merging is silly. I'm also not sure why you're pushing test to origin.

使用推然后拉作为合并的手段是愚蠢的。我也不确定你为什么要将测试推到原点。

回答by Martin Thoma

I would first make the to-be-merged branch as clean as possible. Run your tests, make sure the state is as you want it. Clean up the new commits by git squash.

我会首先使要合并的分支尽可能干净。运行您的测试，确保状态如您所愿。通过git squash清理新提交。

Besides KingCrunches answer, I suggest to use

除了KingCrunches 回答，我建议使用

git checkout master
git pull origin master
git merge --squash test
git commit
git push origin master

You might have made many commits in the other branch, which should only be one commit in the master branch. To keep the commit history as clean as possible, you might want to squash all your commits from the test branch into one commit in the master branch (see also: Git: To squash or not to squash?). Then you can also rewrite the commit message to something very expressive. Something that is easy to read and understand, without digging into the code.

您可能在另一个分支中进行了多次提交，而在 master 分支中应该只有一次提交。为了保持提交历史尽可能干净，您可能希望将来自测试分支的所有提交压缩到主分支中的一个提交中（另请参阅：Git：压缩还是不压缩？）。然后，您还可以将提交消息重写为非常有表现力的内容。易于阅读和理解的东西，无需深入研究代码。

edit: You might be interested in

编辑：你可能感兴趣

• In git, what is the difference between merge --squash and rebase?
• Merging vs. Rebasing
• How to Rebase a Pull Request

• 在 git 中，merge --squash 和 rebase 有什么区别？
• 合并与变基
• 如何重新设置拉取请求

So on GitHub, I end up doing the following for a feature branch mybranch:

所以在 GitHub 上，我最终为一个功能分支做了以下事情mybranch：

Get the latest from origin

从原点获取最新信息

$ git checkout master
$ git pull origin master

Find the merge base hash:

找到合并基哈希：

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

Now make sure only the first is pick, the rest is s:

现在确保只有第一个是pick，其余的是s：

pick 00f1e76 Add first draft of the Pflichtenheft
s d1c84b6 Update to two class problem
s 7486cd8 Explain steps better

Next choose a very good commit message and push to GitHub. Make the pull request then.

接下来选择一个非常好的提交消息并推送到 GitHub。然后发出拉取请求。

After the merge of the pull request, you can delete it locally:

拉取请求合并后，可以在本地删除：

$ git branch -d mybranch

and on GitHub

并在 GitHub 上

$ git push origin :mybranch

回答by Robin Wieruch

Old thread, but I haven't found my wayof doing it. It might be valuable for someone who works with rebase and wants to merge all the commits from a (feature) branch on top of master. If there is a conflict on the way, you can resolve them for every commit. You keep full control during the process and can abort any time.

旧线程，但我还没有找到我的方法。对于使用 rebase 并希望将来自（功能）分支的所有提交合并到 master 之上的人来说，这可能很有价值。如果途中发生冲突，您可以为每次提交解决它们。您在此过程中保持完全控制，并可随时中止。

Get Master and Branch up-to-date:

获取最新的 Master 和 Branch：

git checkout master
git pull --rebase origin master
git checkout <branch_name>
git pull --rebase origin <branch_name>

Merge Branch on top of Master:

在 Master 之上合并分支：

git checkout <branch_name>
git rebase master

Optional: If you run into Conflicts during the Rebase:

可选：如果在 Rebase 期间遇到冲突：

First, resolve conflict in file. Then:

首先，解决文件中的冲突。然后：

git add .
git rebase --continue

Push your rebased Branch:

推送您重新定位的分支：

git push origin <branch_name>

Now you've got two options:

现在你有两个选择：

• A) Create a PR (e.g. on GitHub) and merge it there via the UI
• B) Go back on the command line and merge the branch into master

• A）创建一个 PR（例如在 GitHub 上）并通过 UI 将其合并到那里
• B) 返回命令行，将分支合并到 master

git checkout master
git merge --no-ff <branch_name>
git push origin master

Done.

完毕。

回答by djheru

This is the workflow that I use at my job with the team. The scenario is as you described. First, when I'm done working on testI rebase with master to pull in whatever has been added to master during the time I've been working on the testbranch.

这是我在团队工作中使用的工作流程。场景如你所描述。首先，当我完成工作后，test我与 master 重新建立基准，以提取在我一直在test分支上工作期间添加到 master 的任何内容。

git pull -r upstream master

git pull -r upstream master

This will pull the changes to master since you forked the testbranch and apply them, and then apply the changes you've made to test "on top of" the current state of master. There may be conflicts here, if the other people have made changes to the same files that you've edited in test. If there are, you will have to fix them manually, and commit. Once you've done that, you'll be good to switch to the master branch and merge testin with no problems.

这会将更改拉到 master ，因为您分叉了test分支并应用它们，然后应用您所做的更改以在 master 的当前状态“之上”进行测试。如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。如果有，您必须手动修复它们，然后提交。一旦你这样做了，你就会很好地切换到 master 分支并test没有问题地合并。

回答by user776686

I would use the rebase method. Mostly because it perfectly reflects your case semantically, ie. what you want to do is to refresh the state of your current branch and "pretend" as if it was based on the latest.

我会使用 rebase 方法。主要是因为它在语义上完美地反映了您的情况，即。您想要做的是刷新当前分支的状态并“假装”它是基于最新的。

So, without even checking out master, I would:

所以，master我什至不结账，我会：

git fetch origin
git rebase -i origin/master
# ...solve possible conflicts here

Of course, just fetching from origin does not refresh the local state of your master(as it does not perform a merge), but it is perfectly ok for our purpose - we want to avoid switching around, for the sake of saving time.

当然，仅从原点获取不会刷新您的本地状态master（因为它不执行合并），但对于我们的目的来说完全可以 - 为了节省时间，我们希望避免切换。

回答by Vinay Sikarwar

git checkout master
git pull origin master
# Merge branch test into master
git merge test

After merging, if the file is changed, then when you merge it will through error of "Resolve Conflict"

合并后，如果文件被更改，则合并时会通过“解决冲突”错误

So then you need to first resolve all your conflicts then, you have to again commit all your changes and then push

那么你需要首先解决所有冲突，然后你必须再次提交所有更改，然后推送

git push origin master

This is better do who has done changes in test branch, because he knew what changes he has done.

这更好做谁在测试分支中做过改动，因为他知道自己做了什么改动。

回答by cgnorthcutt

@KingCrunch's answer should work in many cases. One issue that can arise is you may be on a different machine that needs to pull the latest from test. So, I recommend pulling test first. The revision looks like this:

@KingCrunch 的答案应该在许多情况下都有效。可能出现的一个问题是您可能在另一台需要从测试中提取最新版本的机器上。所以，我建议先拉测试。修订版如下所示：

git checkout test
git pull
git checkout master
git pull origin master
git merge test
git push origin master

回答by omkar

I'll answer as per develop and feature branches,

我会根据开发和功能分支回答，

if you're on feature branch and need to update it with develop use below commands: git checkout develop git pull git checkout feature/xyz git merge develop

如果您在功能分支上并且需要使用以下命令进行更新，请使用以下命令： git checkout develop git pull git checkout feature/xyz git merge develop

Now your feature is updated with develop you can push your changes.

现在您的功能已通过开发更新，您可以推送您的更改。