【问题标题】:merging to branches, doesn't matter which one you merge into?合并到分支,不管你合并到哪个分支?
【发布时间】:2023-04-10 18:24:02
【问题描述】:

git 版本 1.7.5.4

我有大约 5 家分店。都来自同一个初始分支。

我想将 2 个分支合并在一起。比如说,branch1 和 branch2。这些分支有很多不同。

我目前正在研究 branch1,并且刚刚意识到我在 branch2 中实现了一些我想要在 branch1 中进行的更改。

什么是最好的合并方式?

checkout branch2 and merge branch1

checkout branch1 and merge branch2

或者你需要结帐哪个分支与另一个分支合并无关紧要?

【问题讨论】:

    标签: git version-control


    【解决方案1】:

    通常两个分支是主题分支还是特性分支都没有关系。

    但是,如果您有一个集成分支或一个标记已发布内容的分支,您肯定希望将长期存在的集成分支用作已签出的分支并将另一个合并到其中。

    这样做的原因是合并提交会将第一个父提交标记为来自主分支的提交。现在,您对该分支历史的树状规范很容易。要找到该分支中倒数第四次的提交,您只需

    git show head~4
    

    如果您从其他分支之间的某个地方合并,则无论以其他方式完成合并,您都必须显式切换到第二次提交:

    git show head^^2^^
    

    这可能由于另一个原因导致主要分支出现问题;将它们合并到主题或功能分支中称为“反向合并”,这不是一个好主意。我记得当贡献者这样做时,Linus Torvalds 大发雷霆。这不允许他清楚地分离他想要合并的主要修订的哪些特性,因为特性分支会带来一个旧的测试合并,其中包括他不再想要的东西。

    所以最后,如果一个分支更重要并且不仅仅是一项功能,请检查它并从那里合并。您将能够轻松查看其历史记录,因为您知道它的第一个父级始终位于该分支之前的位置。如果你不这样做,你将不得不依赖阅读合并提交消息,这并不那么有趣。 :)

    我写了一篇关于 BpF 的文章,其中展示了一种保持分支井井有条的严格方法:http://dymitruk.com/blog/2012/02/05/branch-per-feature/

    【讨论】:

    • 干杯!这些错误使历史导航成为一场噩梦。
    【解决方案2】:

    我假设您确实希望合并整个分支,而不是仅仅挑选奇怪的提交。此外,我在下面所说的内容很大程度上基于此very helpful blog post by Junio C. Hamano,git 维护者,如果您想了解更多关于分支的哲学,我强烈建议您阅读。

    不幸的是,您的问题中没有足够的信息来就此提供合理的建议,因为该问题主要取决于每个分支的目的。例如,在一种常见情况下,可能有一个master 分支,应该始终能够从中生成稳定版本。当有人想向软件添加新功能时,他们可能会从 master 创建一个名为 awesome-feature 的主题分支,他们会在该分支上工作,可能会变基,彻底测试等等。当每个人都对该分支感到满意时,只有将awesome-feature 合并到master 才有意义,反之则不行。 (反过来,大约意味着 master 中的所有内容都有助于实现主题分支所针对的“令人敬畏的功能”。)但是,您只能判断哪种方式是正确的,因为我们知道每个分支的目的.

    在 git 中分支和合并非常简单,它支持许多不同的工作流程,从 highly structuredrather simpler,再到完全非结构化。通过“完全非结构化”,我的意思是有几个不同的开发分支,人们以任何方式在它们之间合并,似乎包括他们在特定分支中想要的特性——如果你处于这种情况,没有明确的为每个分支定义的目的,您是否将branch1 合并到branch2 或相反可能并不重要。但是,我发现为每个分支有一个更清晰的目的会更有帮助,在这种情况下,合并两个分支的方式很重要。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-05-26
      • 2015-10-02
      • 2014-04-30
      • 1970-01-01
      • 2015-11-01
      • 2015-10-30
      • 2015-06-23
      • 1970-01-01
      相关资源
      最近更新 更多