将 Git 分支合并到 master 中的最佳(最安全)方法是什么?

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

有几个开发人员要么致力于master要么创建其他分支,然后合并成master

假设test工作需要花费几天的时间,并且您希望通过master内的提交来不断更新test

我会做git pull origin mastertest

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


我的test工作已经完成,我准备将其合并回master 。这是我可以想到的两种方法:

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

我不使用--rebase因为据我所知,rebase 将获得master的更改并在此基础上堆叠我的更改,因此它可能会覆盖其他人所做的更改。

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

所有这一切的目的是使我的test分支随时master发生的事情,然后我可以将它们合并回master以期使时间轴尽可能保持线性。

答案

我将如何做

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

如果我有一个来自远程分支机构的本地分支机构,那么除了将这个分支机构与远程分支机构合并之外,我不满意。同样,我不会推送更改,直到对要推送的内容感到满意并且也不会推送所有仅适用于我和我的本地存储库的东西。在您的描述中,似乎该test仅适合您?因此,没有理由发布它。

git 总是尝试尊重您和他人的更改,-- --rebase也是如此。我认为我无法适当地解释它,因此请看一下Git 书 - Rebasinggit-ready:介绍 rebasing 作一些说明。这是一个很酷的功能

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

喜欢

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

这种方法有两个问题

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

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

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

git checkout test
git pull 
git checkout master
git pull
git 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 master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

是的,完成鞋面后,所有 Test 分支的提交都将移至 Master 分支的头部。变基的主要好处是,您可以获得线性且清晰得多的项目历史记录。

您唯一需要避免的是:永远不要在公共分支(如 master 分支)上使用rebase

切勿执行以下操作

git checkout master
git rebase -i test

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

附录:

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

开发时通常的方法是

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

当您准备好合并回母版时,

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

如果您担心在合并中破坏某些内容,可以使用git merge --abort

使用推后拉作为合并的方法很愚蠢。我也不确定您为什么要把测试推向原点。

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

除了KingCrunches 答案 ,我建议使用

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

您可能在另一个分支中进行了多次提交,而这些提交仅应在 master 分支中进行了一次提交。为了使提交历史记录尽可能整洁,您可能希望将所有来自 test 分支的提交压缩为 master 分支中的一个提交(另请参见: Git:压扁还是不压扁? )。然后,您也可以将提交消息重写为非常具有表现力的内容。无需深入了解代码即可轻松阅读和理解的内容。

编辑:您可能对

因此,在 GitHub 上,我最终对功能分支mybranch执行了以下mybranch

从起源获取最新

$ git checkout master
$ git pull origin master

查找合并基础哈希:

$ git merge-base mybranch master
c193ea5e11f5699ae1f58b5b7029d1097395196f

$ git checkout mybranch
$ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

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

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

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

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

$ git branch -d mybranch

并在 GitHub 上

$ git push origin :mybranch

这是我在团队工作中使用的工作流程。该场景如您所描述。首先,当我完成test工作时,我以 master 为基础进行基础工作,以提取我在test分支工作期间添加到 master 中的所有内容。

git pull -r upstream master

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

旧线程,但是我还没有找到解决方法 。这对于使用 rebase 并希望将 master 分支(功能)中的所有提交合并的某人来说可能是有价值的。如果途中有冲突,则可以为每次提交解决它们。在此过程中,您可以完全控制,并且可以随时中止。

获得最新的 Master 和 Branch:

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

合并分支到 Master 之上:

git checkout <branch_name>
git rebase master

可选:如果在重新设置基准期间遇到冲突:

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

git add .
git rebase --continue

推送您的基础分支:

git push origin <branch_name>

现在,您有两个选择:

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

做完了

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

合并后,如果文件已更改,则合并时将出现 “解决冲突” 错误

因此,您首先需要解决所有冲突,然后再次提交所有更改,然后再按

git push origin master

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

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

因此,即使不签出master ,我也会:

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

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

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

git checkout master
git pull

无需先结帐; rebase 用两个参数做正确的事

git rebase master test  

git checkout master
git merge test

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

git push
git checkout test

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

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

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

用法:

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

Git Alias

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

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

现在您可以执行以下操作:

git fetch
git pmerge origin/master