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

创建了一个来自master的新分支,我们称之为test

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

假设test的工作需要几天时间,并且您希望在master中不断更新test

我会从test开始git pull origin master

问题1:这是正确的方法吗?其他开发人员可以轻松地处理与我处理的相同的文件。


我在test上的工作已经完成,我准备将它合并回master。以下是我能想到的两种方法:

答:

git checkout testgit pull origin mastergit push origin testgit checkout mastergit pull origin test

乙:

git checkout testgit pull origin mastergit checkout mastergit merge test

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

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

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

1983374 次浏览

我该怎么做

git checkout mastergit pull origin mastergit merge testgit push origin master

如果我有一个远程分支的本地分支,我不喜欢将这个分支与远程分支合并。我也不会推送我的更改,直到我对我想要推送的内容感到满意,而且我根本不会推送仅适用于我和我的本地存储库的东西。在你的描述中,test似乎只适合你?所以没有理由发布它。

git总是试图尊重你和他人的更改,--rebase也是如此。我认为我无法恰当地解释它,所以请查看Git书籍-Rebasinggit-就绪:重新建立基础的介绍进行一些描述。这是一个非常酷的功能

重基和合并都不应覆盖任何人的更改(除非您在解决冲突时选择这样做)。

开发时通常的方法是

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

当你准备好合并回Master

git checkout mastergit log ..test # if you're curiousgit merge testgit push

如果你担心在合并中破坏一些东西,git merge --abort就在那里。

使用推和拉作为合并的手段是愚蠢的。我也不知道为什么你要把测试推到原点。

这是一个非常实用的问题,但上面所有的答案都不实用。

喜欢

git checkout mastergit pull origin mastergit merge testgit push origin master

这种方法有两个问题

  1. 这是不安全的,因为我们不知道测试分支和主分支之间是否有任何冲突。

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

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

git checkout testgit pullgit checkout mastergit pullgit merge --no-ff --no-commit test

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

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

git status

一旦我们解决了冲突,或者如果没有冲突,我们commitpush

git commit -m 'merge test branch'git push

但是这种方式会丢失测试分支中记录的更改历史,并且会使主分支难以让其他开发人员了解项目的历史。

所以最好的方法是我们必须使用rebase而不是merge(假设,此时我们已经解决了分支冲突)。

以下是一个简单的示例,有关高级操作,请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout mastergit pullgit checkout testgit pullgit rebase -i mastergit checkout mastergit merge test

是的,当你完成了上面的工作后,所有测试分支的提交都将被移动到主分支的头上。重新建立基础的主要好处是你得到了一个线性的、更干净的项目历史记录。

你唯一需要避免的是:永远不要在公共分支上使用rebase,比如主分支。

永远不要做手术如下所示:

git checkout mastergit rebase -i test

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

附录:

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

合并后,如果文件发生变化,那么合并时会出现“解决冲突”错误

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

git push origin master

这是更好地做测试分支中谁做了更改,因为他知道他做了什么更改。

这是我在团队工作中使用的工作流程。场景如你所描述的。首先,当我完成test的工作时,我用master重新建立基础,以拉入我在test分支工作期间添加到master的任何内容。

git pull -r upstream master

这将拉取自您分叉test分支以来对master的更改并应用它们,然后应用您所做的更改以测试master的当前状态“之上”。如果其他人对您在测试中编辑的相同文件进行了更改,这里可能会有冲突。如果有,您必须手动修复它们并提交。完成后,您可以切换到master分支并将test合并到其中,没有问题。

我将首先使要合并的分支尽可能干净。运行您的测试,确保状态是您想要的。通过gitsquash清理新的提交。

除了KingCrunches的回答,我建议使用

git checkout mastergit pull origin mastergit merge --squash testgit commitgit push origin master

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

编辑:您可能感兴趣的

因此,在GitHub上,我最终为功能分支mybranch执行以下操作:

从原点获取最新信息

$ git checkout master$ git pull origin master

找到合并基础哈希:

$ git merge-base mybranch masterc193ea5e11f5699ae1f58b5b7029d1097395196f
$ git checkout mybranch$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

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

pick 00f1e76 Add first draft of the Pflichtenhefts d1c84b6 Update to two class problems 7486cd8 Explain steps better

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

合并拉取请求后,可以在本地删除:

$ git branch -d mybranch

和github

$ git push origin :mybranch

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

所以,即使没有检查master,我也会:

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

当然,仅仅从原点获取不会刷新master的本地状态(因为它不会执行合并),但它完全符合我们的目的——为了节省时间,我们希望避免切换。

旧线程,但我还没有找到这样做的<强>我的路。对于使用rebase并希望将来自(功能)分支的所有提交合并到master之上的人来说,这可能很有价值。如果路上有冲突,你可以为每次提交解决它们。你在过程中保持完全控制,并且可以随时中止。

获取主分支最新:

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

在Master顶部合并分支:

git checkout <branch_name>git rebase master

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

首先,解决文件中的冲突。然后:

git add .git rebase --continue

您可以随时中止rebase:

git rebase --abort

推动您的重新定位分支:

git push origin <branch_name>

如果你之前有这个分支推送,你需要用强制推送覆盖它:

git push origin -f <branch_name>

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

现在你有两个选择:

  • A)创建一个PR(例如在GitHub上)并通过UI将其合并到那里
  • B)返回命令行并将分支合并到master中
git checkout mastergit merge --no-ff <branch_name>git push origin master

成交

您必须签出分支才能拉取,因为拉取意味着合并到master中,并且您需要一个工作树来合并。

git checkout mastergit pull

不需要先签出;rebase用两个参数做正确的事情

git rebase master test
git checkout mastergit merge test

默认情况下,git ush会推送此处和远程上存在的所有分支

git pushgit checkout test

正如标题所说的“最佳方式”,我认为这是一个好主意耐心合并策略。

来自:https://git-scm.com/docs/merge-strategies

使用此选项,“合并递归”会花费一些额外的时间来避免有时由于不重要的匹配行(例如,不同函数的大括号)而发生的错误合并。当要合并的分支发散很大时使用此选项。另请参阅git-diff[1]--耐心。

用法:

git fetchgit merge -s recursive -X patience origin/master

git别名

我总是使用别名,例如运行一次:

 git config --global alias.pmerge 'merge -s recursive -X patience'

现在你可以做:

git fetchgit pmerge origin/master

来自GitLab:只需按照说明操作:

在此处输入图片描述

@KingCrunch的答案在许多情况下应该有效。可能出现的一个问题是,你可能在不同的机器上,需要从测试中拉取最新的。所以,我建议先拉取测试。修订如下所示:

git checkout testgit pullgit checkout mastergit pull origin mastergit merge testgit push origin master

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

如果您在功能分支上并且需要使用开发更新它,请使用以下命令:

git checkout developgit pullgit checkout feature/xyzgit merge develop

现在您的feature/xyz已更新为develop分支,您可以将更改推送到远程feature/xyz

我总是在做git merge feature-branch时遇到合并冲突。这似乎对我有用:

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

这里已经有很多很好的答案了。我只是添加了我所做的步骤。

git fetch -pgit checkout mastergit rebase origin/mastergit checkout testgit rebase master

补充说明

git fetch -p将检索自上次获取以来所做的任何更改,-p修剪您的分支,删除任何过时的分支。

git checkout master检查主分支

git rebase origin/master更新master分支。在这里做一个拉取会给你相同的结果。

git checkout test签出您所更改的分支

git rebase master使用master上的更改更新test分支。这会合并任何更改的文件,如果您的任何提交存在冲突,您必须解决它们,然后执行git rebase --continuegit rebase --abort

**git分支命令用于列出存储库中所有现有分支。当前活动分支旁边会出现一个星号。

$ git branch
  • 大师要创建一个新分支,我们可以使用git分支新分支命令。这将创建一个新分支,镜像当前活动分支上的提交:

    $git分支新分支$git分支

  • 大师新分支简而言之,请记住,Git在幕后实际上并不会创建一组新的提交来表示新分支。在Git中,分支实际上只是一个标签。它是一个我们可以用来引用特定提交字符串的标签。在幕后复制一组提交会效率低下,因此Git允许我们从一个基础创建多个不同的提交集。

至此,我们已经创建了一个新分支,但仍然位于源分支上。要开始处理新分支,我们首先需要运行命令git check out new-分支。这将把活动分支更改为新分支:

$ git checkout new-branch

切换到新分支$git分支master

  • 新分支此时,可以在新分支上提交以实现新功能。功能完成后,可以将分支合并回主代码分支。

首先我们运行git check out master将活动分支更改回master分支。然后我们运行命令git合并new-分支将新功能合并到master分支中。**