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


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

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

有几个开发人员要么承诺使用master，要么创建其他分支，然后合并到master。

比如说，在test上的工作需要几天时间，而您需要不断地将test更新为master内的提交。

我会从test开始做git pull origin master。

问题1：这是正确的方法吗？其他开发人员可以很容易地处理和我处理过的btw相同的文件。

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

答：

1
2
3
4
5
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test

B：

1
2
3
4
git checkout test
git pull origin master
git checkout master
git merge test

号

我不使用--rebase，因为据我所知，rebase将从master获得更改，并将我的更改叠加在上面，因此它可以覆盖其他人所做的更改。

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

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

相关讨论

我该怎么做

1
2
3
4
git checkout master
git pull origin master
git merge test
git push origin master

如果我有一个远程分支的本地分支，我不愿意将其他分支与远程分支合并。另外，我不会推动我的更改，除非我对我想要推动的内容感到满意，而且我也不会推动任何东西，这只适用于我和我的本地存储库。在你的描述中，似乎test只适合你？所以没有理由发表它。

Git总是试图尊重你和其他人的变化，--rebase也会如此。我觉得我无法恰当地解释它，所以请看一下Git图书-Rebasing或Git Ready：介绍一下Rebasing以获得一些描述。这是一个很酷的特色

相关讨论

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

喜欢

1
2
3
4
git checkout master
git pull origin master
git merge test
git push origin master

这种方法有两个问题：

  • 这是不安全的，因为我们不知道测试分支和主分支之间是否有冲突。

  • 它将把所有测试提交"挤压"到master上的一个合并提交中；也就是说，在master分支上，我们看不到测试分支的所有更改日志。

    • 因此，当我们怀疑会发生冲突时，我们可以进行以下Git操作：

    1
    2
    3
    4
    5
    git checkout test
    git pull
    git checkout master
    git pull
    git merge --no-ff --no-commit test

    在commit之前测试merge，避免--no-ff的快进承诺，

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

    1
    git status

    。

    一旦我们解决了冲突，或者如果没有冲突，我们就去解决它们。

    1
    2
    git commit -m 'merge test branch'
    git push

    。

    但是这样会丢失登录到测试分支中的更改历史，并且会使主分支对于其他开发人员来说很难理解项目的历史。

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

    下面是一个简单的示例，有关高级操作，请参阅http://git-scm.com/book/en/v2/git-branching-rebasing

    1
    2
    3
    4
    5
    6
    7
    git checkout master
    git pull
    git checkout test
    git pull
    git rebase -i master
    git checkout master
    git merge test

    是的，当您完成了upper之后，所有测试分支的提交都将移动到主分支的头上。重新平衡的主要好处是您可以得到一个线性的和更干净的项目历史。

    唯一需要避免的是：不要在公共分支上使用rebase，就像主分支一样。

    切勿执行以下操作：

    1
    2
    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
    相关讨论

    无论是REBASE还是MERGE都不应覆盖任何人的更改(除非您在解决冲突时选择这样做)。

    通常的开发方法是

    1
    2
    3
    4
    5
    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

    号

    当您准备好合并回主控形状时，

    1
    2
    3
    4
    git checkout master
    git log ..test # if you're curious
    git merge test
    git push

    如果你担心在合并中会有什么问题，那么git merge --abort就是为你准备的。

    把推然后拉作为合并的一种方式是愚蠢的。我也不知道你为什么要把测试推到原点。

    相关讨论

    我会先把要合并的分支尽可能地清理干净。运行测试，确保状态符合您的需要。通过git squash清除新提交。

    除了Kingcrunches的答案，我建议使用

    1
    2
    3
    4
    5
    git checkout master
    git pull origin master
    git merge --squash test
    git commit
    git push origin master

    您可能在另一个分支中进行了许多提交，这应该只是主分支中的一个提交。为了尽可能保持提交历史记录的整洁，您可能希望将测试分支中的所有提交压缩到主分支中的一个提交中(另请参见：git:是否压缩？)然后您还可以将提交消息重写为非常有表现力的内容。易于阅读和理解的东西，而不必深入代码。

    编辑：你可能对

    • 在Git中，merge——squash和rebase有什么区别？
    • 合并与再平衡
    • 如何重新设置拉请求的基

    在Github上，我最后为一个特性分支mybranch做了以下工作：

    从来源获取最新信息

    1
    2
    $ git checkout master
    $ git pull origin master

    号

    查找合并基哈希：

    1
    2
    3
    4
    5
    $ git merge-base mybranch master
    c193ea5e11f5699ae1f58b5b7029d1097395196f

    $ git checkout mybranch
    $ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f

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

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

    。

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

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

    1
    $ git branch -d mybranch

    在Github上

    1
    $ git push origin :mybranch

    。

    相关讨论

    这是我在团队工作中使用的工作流。场景如您所描述的。首先，当我完成了对test的操作后，我重新与master连接，以便在我处理test分支时，将添加到master的内容拉入。

    埃多克斯1〔2〕

    这将把更改拉到master，因为您分叉了test分支并应用了它们，然后将您所做的更改应用到master当前状态的"顶层"测试。如果其他人对您在测试中编辑的相同文件进行了更改，则此处可能存在冲突。如果有，您必须手动修复它们，然后提交。一旦完成了这项工作，您就可以切换到主分支，并在没有问题的情况下合并test。

    旧线，但我还没找到我的方法。对于与Rebase合作并希望合并master上分支的所有提交的人来说，这可能是很有价值的。如果其中一种方式存在冲突，您可以为每次提交解决它们。

    获取最新的主和分支：

    1
    2
    3
    4
    git checkout master
    git pull --rebase origin master
    git checkout <branch_name>
    git pull --rebase origin <branch_name>

    在主服务器上合并分支：

    1
    2
    git checkout <branch_name>
    git rebase master

    。

    如果在重新设置过程中遇到冲突：

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

    1
    2
    git add .
    git rebase --continue

    一旦完成重新平衡，在主服务器上重新平衡分支：

    1
    2
    git checkout master
    git rebase <branch_name>

    。

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

    因此，即使不签出master，我也会：

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

    。

    当然，仅仅从源站获取不会刷新您的master的本地状态(因为它不执行合并)，但对于我们的目的来说，这是完全正常的——为了节省时间，我们希望避免切换。

    1
    2
    3
    4
    git checkout master
    git pull origin master
    # Merge branch test into master
    git merge test

    合并后，如果文件发生更改，则合并时会出现"解决冲突"错误。

    因此，您需要首先解决所有冲突，然后，您必须再次提交所有更改，然后推送

    1
    git push origin master

    。

    在测试分支中做了更改的人做得更好，因为他知道自己做了什么更改。