【问题标题】:Git bad merges: understanding themGit 错误合并:理解它们
【发布时间】:2014-02-12 21:58:08
【问题描述】:

我有一个简短的问题,希望有人可以解释或至少指出一些文档。我已经阅读了 git-merge 手册页,但我仍然不明白是什么原因造成的。

我们的主分支是版本 1。

我们的几个开发人员和一个图形设计师已经在他们自己的 master 分支上工作了大约三周。开发人员一直在制作补丁和更新。图形设计师一直在研究第 2 版 - 完全重新设计。

我一直害怕合并它,因为我以前见过 git 进行错误的合并,本质上是覆盖代码和破坏东西。

无论如何,我们有很多合并冲突,果然在第二个文件进行到一半时,我发现了一些看起来不正确的东西。我将设计师和开发人员召集在一起,果然,设计师的更改被覆盖了。

现在,开发人员从未检查过设计师作品的副本,也从未将其合并到他们的分支中。然而,设计师可能在某个时候检查了主分支并自行解决了一些冲突以获得一些最新的更改(我不知道这是否重要,但我希望在这种情况下设计者提交会覆盖开发者)。

如前所述,这不是第一次发生这样的事情,因为这是一个相当大的合并,我想了解正在发生的事情。

【问题讨论】:

    标签: git merge conflict git-merge merge-conflict-resolution


    【解决方案1】:

    您可能希望为您的团队研究更复杂的工作流程。对我来说,目标是将 master 作为纯粹工作提交的日志,并使用功能/修补程序分支来处理。这是基于git-flow 模型。

    例如,假设您是从事用户身份验证的开发人员。你会:

    • 从开发中签出一个新分支:git checkout -b feature/auth develop
    • 进行一些更改
    • 提交您的代码:git commit -m 'commit message'

    现在您想推动您的更改发展。不幸的是,设计师已经推送了一些更改,其中一个会影响您提交中的文件。这意味着您的分支已从开发中“分道扬镳”。

    • 运行 git rebase develop 将要开发的更改覆盖到您的功能提交中
    • 如果存在冲突,您需要修复它们
    • 冲突解决后,继续 rebase。

    准备好后,您可以将develop 的提示推到master。查看我在上面发布的链接,了解有关发布分支、修补程序等的更多信息。

    【讨论】:

      猜你喜欢
      • 2017-12-04
      • 2011-08-25
      • 2013-05-27
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-08-03
      • 2011-03-07
      • 1970-01-01
      相关资源
      最近更新 更多