不承诺掌握

Question

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

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

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

Answer 1

那些说永远或永远经常（总是！？！;-)）错误的人......

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

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

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

这是一份并非详尽无遗的清单...... 使用特征分支（也称为github流）：

优点：

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

缺点：

• git历史记录可能难以阅读（为此，rebase之前的merge可以使历史记录更容易阅读）
• 开发人员可以轻松地进入隧道效果而不与主人同步（最好使用rebase而不是同步合并）并最终以合并地狱结束

使用“trunk Base development”（以及'feature toggles'。真正的好开发实践，你应该看看）：

优点：

• 真正的持续集成（尽快发现错误等所有好处）
• 阻止合并地狱
• 不太麻烦，更容易掌握git
• 当你是唯一的开发者时完全没问题
• 您希望进行持续部署/交付的先决条件（每次提交都是一个小步骤，可以最大程度地降低引入大错误的风险，很难找到更改代码行的原因）

缺点：

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

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

Answer 2

如果您正在与多个人合作，您应该始终拥有单独的分支，并且只有在您添加/更改的位完成并经过全面测试后才会与主人合并。

如果你自己的小项目没有那么多的区别。如果你的添加功能，标签也可以用来回到给定的提交。

不提交master会阻止冲突提交，每次2人更改同一文件时必须合并。

Answer 3

我一直都在推动修补程序以掌握。如果我想快速将某些内容推送到生产环境，则只需对其进行编辑，添加，提交并推送。老实说，我认为采取额外的步骤来创建分支并将其合并到master中没有任何价值。但是，我说的是真正的细微更改，我肯定不会破坏任何内容，例如EG将硬编码链接更新为新的url。

但是，如果您要做的不仅仅是修补程序，那么创建分支将更加轻松，更有条理。这样，您可以在不同的项目之间切换，并将所有内容保存在自己的盒子中。它使您可以切换设备并部署到暂存环境以更轻松地进行测试。