不承诺掌握的原因

Question

在每个关于Git的手册和文档中,您可以看到单个建议 - "不要承诺掌握".因此,如果您需要向master添加一些更改,则需要创建一个新分支并将其合并.因此,我有兴趣知道为什么？这种行为有哪些优点？例如,如果您想要还原更改,则不需要在单独的分支中 - 您可以使用提交哈希来执行此操作.

在这里我找到了一个原因 - 如果你有很多提交,将分支与master合并然后一个接一个地推送提交将更容易 http://waterstreetgm.org/git-why-you-should-never-commit-directly-掌握/

但是,如果您的工作流分为许多小任务,并且每个任务都适合一个提交,那该怎么办呢？因此,每个分支包含一个提交.在这种情况下,不承诺掌握的原因是什么？

Answer 1

那些说永远或永远经常(总是!？!;-))错误的人......

就像你在发现git时会发现的那样,通常有多种方法可以做同样的事情,而你的选择主要是团队选择.

绝对没有规则阻止在master上提交.这两种方式有优点和不便之处.

例如,你链接的帖子更多的是作者没有掌握git而不是其他东西的问题.在不到5分钟的时间内,他就可以创建新的分支并将其本地重置master为远程引用并推送一个提交master.

这是一个并非详尽无遗的列表...使用功能分支(也称为github流):

优点:

• 您可以清楚地看到软件中引入功能的位置(合并分支时)
• 这使代码审查更容易(在合并之前或在所有开发期间,如果您提前提出拉取请求,这是一个很好的做法)
• 如果需要可以轻松恢复(只需恢复合并提交)
• 容易做概念证明(但很难重新引入主人)
• 在进行远程或开源开发时,只需要工作工作流程,这需要在合并提交之前进行代码审查或CI结果(但不一定在公司中使用,因为它在开源世界中是成功的)

缺点:

• git历史可能很难阅读(为此,master就rebase可以使历史更容易阅读)
• 开发人员可以很容易地进入隧道效果而不与主设备同步(最好用rebase而不是同步合并)并最终以合并地狱结束

使用"trunk Base development"(以及'feature toggles'.真正的好开发实践,你应该看看):

优点:

• 真正的持续集成(具有更快发现错误的所有好处)
• 防止合并地狱
• 更简单,更容易掌握git
• 当你是唯一的开发者时完全没问题
• 您希望进行持续部署/交付的先决条件(每次提交都是一个小步骤,可以最大限度地降低引入大错误的风险,很难在大量代码行中找到原因)

缺点:

• 引入功能时不是一个明确的时刻(应该看一下启用的功能切换)
• 需要有良好的开发实践,如编写单元测试(但也可以被视为专业人员)
• 需要(有时)通过抽象掌握分支(Martin Fowler的一个很好的解释:https://martinfowler.com/bliki/BranchByAbstraction.html).这可以降低风险但需要更多时间.

选择适合您团队的一个并坚持使用它并在您认为更有意义并解决您遇到的新问题时应用另一个...

Answer 2

如果您正在与多个人一起工作，则应该始终拥有单独的分支，并且仅在要添加/更改的位完成并经过充分测试后才与母版合并。

如果您在自己的小型项目中，则没有什么区别。如果您添加了功能，那么也可以使用标签来返回给定的提交。

不提交主文件可以防止冲突提交，并且每次2个人更改同一文件时都必须合并。