我是Git的新手，但并不打算发布工程。在Git Flow中，似乎可以省略master分支，并且不会丢失任何信息。如果约定或设计要求使用master，则可以将dev分支的功能用途迁移到master（我假设这样做是抢占诸如“您必须拥有一个名为'master'的分支”之类的答案）。
不过，从清晰度和内务处理的角度来看，我可以看到master分支的用处（在焦虑的时期内，在发行版的源中发现了一个错误，我们需要统计它的状态！），开销基本上是零。我只是指出，它没有提供其他分支中未包含的任何信息以及使用original article的方法中的潜在标记。我错过了什么吗？
答案 0 :(得分：1)
Git Flow分支模型虽然非常流行并且也非常成功，但存在一个缺陷，如果您考虑一下，它会有些不适合Git：Git中的分支不是 lines ，并且会提交不要属于一个分支。相反，分支是指向Git历史图中的单个提交的指针，并且起始提交可到达的所有提交都被视为在分支上 。
因此，假设分支模型中的行严格，并且明确拥有更改的分支所有权（虽然有助于理解该想法），则与Git中的外观完全不符。
因此，从理论上讲，在查看分支模型时，单独的主行很有意义：在主行上，只有那些实际“释放”产品的提交才可见。但是实际上，通过合并，您基本上将所有提交都移到了该分支。
除此之外，Git Flow还采用了明确的发布策略，以及正确的版本和计划的发布。但是很多事情实际上并不是基于发布，而是具有更连续的发布系统（例如，持续交付）。因此，可能会发现严格遵守Git Flow 不适用于特定项目。
最后，这只是一个建议。 Git有许多不同的工作流程，各有各的优点。您和您的团队应该考虑自己的工作方式，然后围绕它设计工作流程。从著名的工作流程（如Git Flow）中汲取一些想法，但不要过于专注于完全遵循它。
答案 1 :(得分：1)
在Git Flow中，似乎可以省略master分支，而不会丢失任何信息。
在大多数城市的街道上，您可以删除除一栋建筑外的所有街道号码，并且不会丢失任何信息[1]。您将失去的是能够轻松地执行常规需要完成的工作的能力-例如无需从某些参考建筑物中找到所需建筑物即可。
master分支存储的是发布（和修补程序）变为“最终”的顺序和时间。假设您标记发行版并遵循某些约定，则无需master分支即可存储所有信息。但是：
1）用户必须定义相关的约定（例如标签名称），而master分支传达的所有信息都可以在git定义的结构中找到
2）您的信息质量取决于人们遵守规则的程度。在仅标签发行分支的方法中，如果有人出于任何原因删除或移动标签，则会丢失信息。丢失master后面的提交历史中编码的信息要更。
3）master分支使信息更易于使用。是否需要在当前版本中添加修补程序？ （或者只需要签出当前版本？）使用master，不用担心您可能会输入错误的标签名称并最终做错事情。
[1]或另一个基于与同事的对话的示例：一个广播电台可以发布他们的歌曲列表，并且您不会因为广播他们的每首歌曲而丢失任何信息。
重点是，您要对结构的有用性发表评论，以反驳“它不会增加信息”的说法。但这不是很有意义。当人们使用系统时，将它们精简到最小程度的信息表示几乎总是会删除有用的功能。
在我的经验中，甚至可以被表示成接近反例的唯一事情是关系数据建模，在此您要剥离多余的表示（规范化）。但是即使这样，您真正仍希望保留冗余结构（如索引），但要确保它们由软件系统地维护，而不是由用户更新-因为没有索引的数据库通常是只是没用。
答案 2 :(得分：1)
即使rebasing某个已发布的分支机构当然也不会被视为最佳实践，但是我们（开发团队的 small 小组）发现自己处于这种情况我们进行了清理，并不时重新排列了develop分支，有时会导致提交的哈希值发生变化。在组织我们的工作时，在master上使用标签标记了 destination 无疑会有所帮助。
您还可以将git-hooks分支机构上的某些事件专门用于master 。
答案 3 :(得分：1)
这是Atlassian的Gitflow Workflow
的一段修补程序分支
维护或“修补程序”分支用于快速修补生产 发布。修补程序分支与发行分支和功能非常相似 分支机构，但它们是基于master而不是development的。这是 唯一应直接从master分支的分支。立刻 修复完成后，应将其合并到母版和开发版中 （或当前的发布分支），并且应使用一个 更新的版本号。
拥有专门的bug修复开发线，可让您的团队 在不中断其余工作流程的情况下解决问题或 等待下一个发布周期。你可以想到维护 分支作为直接与master一起使用的临时发布分支。 （...）
您提到您是git的新手。 Gitflow 不是城里唯一的孩子。您可以签出 Git Feature Branch Workflow 和其他流程...
答案 4 :(得分：0)
master分支确实有一个隐式假设-所有发布均按数字顺序进行-例如，1.1.0将始终在比1.0.1更高的日期出现。如果您有幸可以从事这样的项目，那就太好了。
在更复杂的项目中，您可能需要一次维护多个发行版（例如Linux内核），在制作1.1.0之后，可能需要制作1.0.1。尽管您可以按此顺序将所有这些填充到master分支中，但master分支实际上并不代表任何有用的东西。
这类项目更有可能标记发行分支，而完全忽略master分支。