如何安全地将Git分支合并到master？

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

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

假设测试工作需要几天的时间，您希望通过master内部的提交不断更新测试。

我会从测试中提取原始主机。

问题1：这是正确的方法吗？其他开发人员可以像我一样轻松地处理相同的文件。

我的测试工作已经完成，我已经准备好将其合并回master。以下是我可以想到的两种方法：

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

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

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

问题2：这两种方法中哪一种是正确的？有什么不同？

所有这一切的目标是让我的测试分支随着master中发生的事情而更新，然后我可以将它们合并到master中，希望尽可能保持时间线的线性。

当前回答

本文来自GitLab：只需遵循说明：

其他回答

我总是在执行git合并功能分支时遇到合并冲突。这似乎对我有用：

git checkout -b feature-branch

进行一系列代码更改。。。

git merge -s ours master 

git checkout master

git merge feature-branch

git checkout -b feature-branch

进行一系列代码更改。。。

git checkout master

git merge -X theirs feature-branch

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

获取Master和Branch的最新信息：

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

合并主节点顶部的分支：

git checkout <branch_name>
git rebase master

可选：如果您在回扣期间遇到冲突：

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

git add .
git rebase --continue

您可以随时使用以下方法中止重新基准：

git rebase --abort

推送您的重新基础分支：

git push origin <branch_name>

如果之前已推送此分支，则需要使用强制推送来覆盖它：

git push origin -f <branch_name>

在执行此操作之前，请始终检查当前本地分支是否符合您的期望，因为强制推送会覆盖远程存储库中的旧分支。

现在您有两个选项：

A）创建PR（例如在GitHub上）并通过UI将其合并B）返回命令行并将分支合并到主节点

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

完成。

我该怎么做

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

如果我有一个来自远程分支的本地分支，那么我不愿意将除此分支之外的其他分支与远程分支合并。此外，我不会推送我的更改，除非我对我想要推送的内容感到满意，而且我也不会推送任何内容，这些内容只针对我和我的本地存储库。在你的描述中，这个测试似乎只针对你？所以没有理由发表它。

git总是努力尊重你和其他人的改变，所以会——重新基准。我觉得我不能恰当地解释它，所以看看Git的书《Rebasing or Git ready》：介绍一下Rebasing。这是一个很酷的功能

这是我在团队工作中使用的工作流。场景如您所述。首先，当我完成测试工作时，我与master重新建立了基础，以便在我进行测试分支的过程中提取添加到master的任何内容。

git pull-r上游主机

这将从您分叉测试分支开始将更改拉到master并应用它们，然后将您所做的更改应用到“在”当前master状态的顶部进行测试。如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。如果存在，则必须手动修复并提交。完成后，切换到主分支并合并测试将很好，不会出现任何问题。

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

所以，我甚至不需要检查master，我会：

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

当然，仅从原点获取不会刷新主机的本地状态（因为它不会执行合并），但这完全符合我们的目的-为了节省时间，我们希望避免切换。

推荐文章