不在 Git 中的 master 分支上工作的原因答案

【问题标题】：Reasons for not working on the master branch in Git不在 Git 中的 master 分支上工作的原因
【发布时间】：2011-08-08 11:39:39
【问题描述】：

所以，我对 git 还很陌生，在过去的几周里，我读了一些书，我读到一些人说不应该更改 master 分支，而是从和分支然后合并到。

我很高兴与分支合作，但想知道为什么不使用 master 分支？

【问题讨论】：

标签： git version-control branch dvcs

【解决方案1】：

不确定我的理解是否正确，我是 git 新手。

我认为，当您拥有多个功能时，生活会更轻松。假设您有一个项目，并致力于功能 A，然后您实现功能 B。

现在可能会发生，您认为整个功能 A 是错误的，并且您希望拥有一个只有功能 B 但没有功能 A 的项目版本。如果一切都在 master 上，这个任务很棘手。

如果每个功能都在自己的分支上，那么这个任务很简单：您采用旧的主版本（没有 A 和没有 B）。您合并分支 B。完成。

【讨论】：

虽然这个工作流程也可以使用feature flags 来完成（假设每个功能都用于生产），但如果分支 A 上的功能非常不稳定以至于将被搁置。

【解决方案2】：

其他人在master 中不直接进行更改提出了很好的案例，我同意他们的观点。然而，总是提倡这样的工作流程有时会让刚接触 git 的人认为它是不必要的复杂，所以我想提供一个对位。

如果您有一个单人或非常小的团队，并且您的开发是高度线性的，即您很少一次处理超过一件事，并且每个功能通常在开始下一个功能之前完成，那么真的很少甚至没有受益于不直接从master 工作。如果需要，可以随时返回并添加分支非常容易。我强烈建议您了解功能分支的工作流程，但如果您觉得在您的情况下它只是添加了额外的步骤而没有为您购买任何东西，我保证我不会告诉 git 警察。

【讨论】：

在这里我看到两个非常不同但同样有价值的问题的答案并不常见。这是这样一种情况。太糟糕了，不允许接受多个答案。

【解决方案3】：

使用 Git 或 Mercurial 等 DVCS（分布式版本控制系统）需要考虑的一件事是“发布”工作流程 (orthogonal to the branching workflow)。

当您只有分支时，您会问自己它们代表了哪些开发工作。
如果master 是为了表示稳定的代码，比如his answer 中的knittl 详细信息，那么是的，您需要从/合并到master。

但是当你可以克隆/推送/拉取（即发布到不同的仓库，它们本身可以有不同的目的）时，'master'可以在不同的仓库中扮演不同的角色。

一个开发仓库可以有很多分支，master 通常代表最稳定的代码。
部署存储库只能有master，以及一些用于紧急修复的修补程序维护分支。
本地测试存储库只能有一个 master 分支，从推送到推送重写只是为了通过仅监视该测试存储库的 master 分支的挂钩运行一些静态分析代码。
...

【讨论】：

这是使用 git 的一个被低估/记录不足的方面，我很想看到更多细节。在我的工作场所，我们仍然使用 git 作为所有角色的单一存储库，使用分支来区分角色。

【解决方案4】：

我猜通常的推理是，主分支应该代表代码的“稳定”历史。使用分支来试验新功能，实现它们，当它们足够成熟时，您可以将它们合并回 master。

这样，master 中的代码几乎总是可以毫无问题地构建，并且大部分可以直接用于发布。

我们以 git.git（官方 git 仓库）为例。有几个分支，最引人注目的是：

所以，master 包含的代码很可能会出现在 git 的下一个版本中。 next 包含经过测试的代码，可能会合并到 master 分支中。 pu（提议的更新，iirc）包含相当新的（并且可能）未经测试的代码。

pu 被认为是不稳定的，将根据 junio 的喜好进行重置和重新定位。 next 可能会在发布后或发布周期内重置，但这种情况不太常见。 master 是一成不变的，在被推送并公开后从未改变。

你看，如果这些更改被认为是有价值的并且不会破坏内容，那么这些更改将从 pu 合并到 next 和从 next 合并到 master。

maint 分支用于修复错误，也适用于旧版本的 git。 maint 通常合并到 next 和/或 master。

你可以检查http://git.kernel.org/?p=git/git.git;a=summary上的分支

【讨论】：

谢谢。我看到了这样做的好处，因为可以在不同的分支中同时处理多个功能或错误修复，并在它们成熟时将它们合并回主分支（主干？）。
@willburt：是的，如果你来自svn，你习惯于调用master分支trunk。它们非常相似，但是对于 git（和任何其他分布式 vcs），有许多 master 分支（每个克隆的存储库都有一个），所以树的隐喻不再有意义
优秀。感谢您的帮助。

【解决方案5】：

在双方都进行提交时——这意味着在您的本地存储库和上游，例如来自其他团队成员 - 可能会发生冲突。这意味着文件，特别是行都由两者编辑。在这种情况下，一些手动合并处理是必要的。

master 分支用于在您无法访问上游（移动使用或网络故障）时拥有一个代表上游的本地分支。当有一个本地分支代表上游更改时，进行合并解析和其他事情要容易得多。

【讨论】：

问题不是关于上游/下游，而是我们为什么使用功能和维护分支等。
有趣的答案。我从未听说过有人使用 master 分支作为上游的缓存以进行断开连接的合并。
我不能排除拥有master 和其他原因的其他原因。但是 Wilburt 明确询问为什么有一个 master 根本没有改变，只是用于合并。当我学习 Git 时，有人告诉我不要动master，它工作得很好。有更多的经验，例如在合并中可以节省那部分。