首页 文章

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

提问于
浏览 次
1629

创建了一个来自 master 的新分支，我们将其称为 test .

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

假设 test 上的工作需要几天时间，并且您希望通过 master 内的提交继续保持 test 更新 .

我会从 test 做 git pull origin master .

Question 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 获得更改并将我的堆叠放在其上，因此它可以覆盖其他人所做的更改 .

Question 2: 这两种方法中哪一项是对的？那有什么区别？

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

git git-merge

8 回答

  • 3

    我该怎么做

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

    如果我有一个来自远程的本地分支机构，我对我想要推送的内容感到满意，而且我根本不会推送那些只针对我和我的本地存储库的东西 . 在您的描述中，似乎 test 仅适合您？所以没有理由发表它 .

    git总是试图尊重你和其他人的变化，所以 --rebase . 我不认为我可以适当地解释它，所以看一下the Git book - Rebasing或git-ready: Intro into rebasing进行一些描述 . 这是一个非常酷的功能

    回复于
  • 0

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

    喜欢

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

    这种方法有 two issues ：

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

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

    所以，当我们怀疑会有一些冲突时，我们可以进行以下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

    一旦我们解决了冲突，或者没有冲突，我们就会 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一样 .

    Never do operations 如下：

    git checkout master
git rebase -i test

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

    附录：

    回复于
  • 2407

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

    所以，即使没有查看 master ，我也会：

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

    当然，只是从原点获取不会刷新 master 的本地状态（因为它不执行合并），但它完全可以达到我们的目的 - 我们希望避免切换，以节省时间 .

    回复于
  • 79
    git checkout master
git pull origin master
# Merge branch test into master
git merge test

    合并后，如果文件被更改，那么当你合并它将通过“Resolve Conflict”错误

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

    git push origin master

    在测试分支中做了更改的人更好，因为他知道他做了什么改变 .

    回复于
  • 1

    无论是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作为合并的手段是愚蠢的 . 我也不确定你为什么要把测试推向原点 .

    回复于
  • 26

    旧线程，但我还没有找到自己的方式 . 对于使用rebase工作并想要从master上的分支合并所有提交的人来说，它可能很有 Value . 如果存在冲突，则可以针对每次提交解决冲突 .

    Get Master and Branch up-to-date:

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

    Merge Branch on top of Master:

    git checkout <branch_name>
git rebase master
git add .
git rebase continue

    If you run into Conflicts during the Rebase:

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

    git add .
git rebase --continue

    Once rebase finished, rebase branch on top of master:

    git checkout master
git rebase <branch_name>
    回复于
  • 296

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

    除了KingCrunches answer，我建议使用

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

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

    编辑：你可能会感兴趣

    所以在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
    回复于
  • 1

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

    git pull -r upstream master

    这将把更改提取到master，因为您分叉了 test 分支并应用它们，然后应用您在测试中编辑的更改 . 如果有，您将必须手动修复它们并提交 . 一旦你很好地切换到主分支并合并 test in没有问题 .

    回复于

相关问题