代码之家 › 专栏 › 技术社区 › Jon

Git pull与Git pull——回扣

branch git

Jon · 技术社区 · 6 年前

关于这个写得很好的答案: https://stackoverflow.com/a/4675513/1139436

如果你真的觉得不管什么原因需要某个分支。。。

这里的“分支”指的是什么?在我们的工作流程中,我们将master分支为进行错误修复、新特性等,然后将这些更改推送到gerrit进行审查,gerrit一旦批准(我想,我没有设置它)就会将它们合并到master中。这些是被提到的分支,还是评论提到了更大的东西(项目分歧等)?

回到我们的工作流程。。。一旦提交更改,我们 git checkout master , git pull *以及 git branch -D bugfix_branch . 我用*标记了pull,因为这经常导致在本地主控中合并提交。我开始用 git pull --rebase 不再看到合并的承诺,但我承认,我一点也不明白幕后发生了什么。

为什么我看到合并提交,我想要它们吗?我最好还是 --rebase 避开他们?不管怎样,似乎都没有答案,只要它“管用”。

1 回复 | 直到 6 年前

torek 6 年前

最终,决定是否使用面向合并的工作流程、面向调整基的工作流程或一些混合的工作流程,也就是说,两者都使用,基于判断选择哪一个是意见问题,好吧,是判断问题。 ^一双方都有很好的论据。这里有两个外部意见页, one by Ken Sheedlo in favor of rebase 和 one that lists arguments on both sides ,加上 Atlassian tutorial page 关于合并和重新调整。

关于rebase要认识到的是副本 (一些)犯罪。如果您理解将提交表示为图表 , ^二 Ken Sheedlo的pro rebase参数中的示例向您展示了这一点的确切含义:原始提交 B 和 C 进入

  B--C   <-- feat
 /
A--D--E   <-- master

象征性地被狼群抛弃,取而代之的是闪亮的新替代品 B' 和 C' :

  B--C   [abandoned]
 /
A--D--E   <-- master
       \
        B'-C'  <-- feat

已经取代了沉闷又恶心的老家伙 B-C 闪亮的新链子 B'-C' 提交链,新的特性分支现在可以无缝地集成到 master ,有或没有合并提交。使用合并共轴 git merge --no-ff feat 打开时 主人 给你这个图表:

A--D--E------F   <-- master
       \    /
        B'-C'  <-- feat

有助于历史学家将来的发展 feat 被删除,这是安全的,因为 F 记住 C' 以及 E )并确保一对 , B'-C' ,是实现该功能的。这是否有价值,与更简单的外观相比:

A--D--E--B'-C'  <-- master

是一个单独的问题。但事实上真最初的承诺是 B--C 无论哪种方式都会迷失,因为有了回扣。如果那个事实是很重要的,因为某些原因,然后你确实失去了一些东西。

简言之,这就是反回扣的论点: 你可能会失去一些重要的历史。 支持回扣的论点是,这些历史片段不仅仅是 不重要的 ,他们 积极干涉理解 . 计算机程序设计的大部分是抽象的,抽象是 去除不必要的细节 . ^三这给了你一个很好的“大局观”。一旦你明白你现在的处境和你想去的地方, 然后你可以描绘出你是如何到达这里和如何到达那里的具体细节。如果你迷失在细节的杂草中,不知道你在哪里,你要去哪里,你最多会得到某种布朗运动的幸运。

^一对于是否用额外的“e”拼写判断也是如此: http://grammarist.com/spelling/judgment-judgement/ , https://www.dictionary.com/e/judgement-vs-judgment/

^二如果你不要 ,浏览以下页面 Think Like (a) Git .

^三数学也是如此。图论本身起源于 删除不必要的细节: 欧拉意识到最重要的是桥梁和陆地。(见脚注2中的链接。)