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

Question

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

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

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

我会做git pull origin master的test.

问题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希望保持时间线尽可能线性.

Answer 1

我该怎么做

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

如果我有一个远程本地分支,我觉得将其他分支与远程分支合并后感觉不舒服.此外,我不会推动我的更改,直到我对我想要推送的内容感到满意,而且我根本不会推送任何内容,这些内容仅适用于我和我的本地存储库.在您的描述中,似乎test只适合您？所以没有理由发表它.

git总是试图尊重你和他人的变化,所以也会如此--rebase.我不认为我能够恰当地解释它,所以看看Git书 - 重新定位或git-ready:介绍变基础以获得一些描述.这是一个非常酷的功能

Answer 2

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

喜欢

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

这种方法有两个问题:

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

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

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

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

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

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

git status

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

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分支的头部.变基的主要好处是,您可以获得线性且更清晰的项目历史记录.

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

切勿执行以下操作:

git checkout master
git rebase -i test

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

附录:

• 如果您不确定变基操作,请参阅:https://git-scm.com/book/en/v2/Git-Branching-Rebasing

Answer 3

无论是rebase还是合并都不应该覆盖任何人的更改(除非您在解决冲突时选择这样做).

开发过程中的常用方法是

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上有什么破坏,那就适合你.

使用push然后pull作为合并的手段是愚蠢的.我也不确定你为什么要把测试推向原点.

Answer 4

我会首先使待合并的分支尽可能干净.运行测试,确保状态符合您的要求.通过git squash清理新的提交.

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

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

您可能在另一个分支中进行了许多提交,这应该只是主分支中的一个提交.为了使提交历史尽可能干净,您可能希望将所有提交从测试分支压缩到主分支中的一个提交中(另请参阅:Git:压缩或不压缩？).然后,您还可以将提交消息重写为非常富有表现力的内容.一些易于阅读和理解的东西,无需深入研究代码.

编辑:你可能会感兴趣

• 在git中,merge --squash和rebase之间有什么区别？
• 合并与重新定位
• 如何重新启动拉取请求

所以在GitHub上,我最终为功能分支做了以下事情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

Answer 5

这是我在团队工作中使用的工作流程.场景如您所述.首先,当我完成工作时,test我会与主人一起工作,以便在我在test分支机构工作期间拉入已添加到主人的任何内容.

git pull -r upstream master

这将把更改拉到master,因为你分叉test并应用它们,然后应用你所做的更改来"测试"当前master的状态.如果其他人对您在测试中编辑的相同文件进行了更改,则此处可能存在冲突.如果有,您将必须手动修复它们并提交.完成后,您可以切换到主分支并合并test而不会出现任何问题.

Answer 6

旧线程，但是我还没有找到解决方法。这对于使用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

做完了

Answer 7

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

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

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

git push origin master

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

Answer 8

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

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

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

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

Answer 9

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

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

Answer 10

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

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

git checkout develop
git pull
git checkout feature/xyz
git merge develop

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