Answers:
立即。
关键是主人的政策是什么。通常，使用git时，Master上的分支策略是可构建的稳定版本。有时，Master是“主线”，在合并到Release分支之前，分支是从分支中合并而成的。这是两种不同的角色/策略方法。
人们在项目过程中更改分支机构的角色或策略通常是错误的来源。单独的开发人员更容易将这些更改传达给贡献者，但是试图让十几位程序员都认识到“ Master现在是1.0，请分支功能，而不是所有人都推动它”
我谈到了上面的政策方法。Master的政策是它是可构建的稳定版本。检入微小的增量更改意味着您始终没有可构建的稳定文件。不检查较小的更改会违背“大量的较小（但完整）的检入”，这通常是最好的策略（并且易于分支，鼓励这样做）。
从基于角色的角度来看，您首先是作为主线，发布，维护和开发角色的主角色，然后在开发和维护角色转移到分支机构的道路上走了下来。这再次意味着对主服务器允许的内容进行更改，并且可能会使贡献者混淆事物的归属。它也可以（稍微）混淆分支历史，鼓励进行大的提交，这意味着更大和更难理解的合并。
从一开始就简单，一致地确定分支机构的角色和策略。
在分支模式中可以看到这种“政策变化分支”。每个分支都有其作用的想法可以在Advanced SCM Branching Strategies中阅读。这两个都是很好的读物。
通常在两种情况下，您通常要开始使用分支：
当您或您的团队必须启动一个新功能，而该功能极有可能不被添加到下一个版本（可能是有史以来的第一个版本）时，然后在单独的功能分支中开始开发
当您必须提供针对最新版本的严重错误的修复程序，并且您想要创建一个仅包含这些修复程序但不包含新开发（可能不稳定）功能的新错误修复程序版本时
对于此类决策，从您拥有程序的第一个可编译/可运行版本的角度出发，始终以“新功能”或“错误修正”的方式进行思考是有帮助的。
迈克尔·费瑟斯（Michael Feathers）在他的着名书中列出了进行更改的四个原因，但我通常会在“新功能分支”（针对非功能性功能）下放置“优化资源”，而在“新功能分支”下也多数时候将“改进设计”放在“新功能分支”下，因为IMHO绝不应该在不旨在简化特定功能实现的情况下改进设计。
如果你遵循混帐流 -和，坦率地说，我觉得你疯了，如果你使用Git和不使用分支模型-那么你应该永远不会承诺master，直到你真正准备好公开发布。
您的第一次提交master应该是一个空的存储库。您的下一个提交master应该是develop分支或临时发布分支的合并提交，并且应该是稳定的，经过测试的，并且可以进行部署（如果是应用程序）或公共分发（如果是库）。
还有是其他分支模型的Git，但其中大部分都被从旧的集中式SCM模型得出的，并可能导致在DVCS环境的严重问题。您不必实际使用git-flow扩展，也不必全部使用那些release / hotfix / feature分支，但是裸露的骨骼是developand master，并且不稳定的代码进入了develop。
master。请记住，mastergit没什么特别的，它不需要在那里。您可以只拥有一个开发分支，直到要发布为止。
自从这个问题的最后答案已经过去了两年，我认为现在的故事发生了变化。对我来说，答案是“只要您使用源代码控制来跟踪版本”。
详细说来，如今使用源代码控制跟踪项目版本并不总是有效。（例如，使用npm管理依赖关系并使用'^'指定语义版本）在这种情况下，每次构建时项目工件都会更改，而不必每次都对应于源代码更改。为了应对此类新挑战，一些团队选择已经构建了保存在工件控制系统（例如，JFrog Artifactory）中的“工件”以用于跟踪项目版本。
显然，当您已经有工件版本控制时，您不会从GIT分支中提取“生产代码”并将其构建/部署到生产中，而是向工件控制系统咨询以直接运行的版本进行部署。在这种情况下，“释放分支”的概念突然失去了其含义。每当您的团队决定不将git分支与发行版本相关联时，直接提交/推送到master再次成为明智的选择：每当克隆回购协议时，它就会作为默认分支出现，因此自动给出了广为接受且易于传达的语义变化。但是，正如已接受的答案所建议的那样，您可能应该为包括master在内的分支分配角色，并将这些分支仅用于那些特定角色。
最后，我要进一步走一步，建议在只有少数核心提交者的项目中使用master作为开发分支。我的团队就是这种情况，大多数微服务商店也可能如此。提交母版可消除更改流程的沟通，并在处理多个sprint的功能时可能避免“合并”。此外，master分支中的代码甚至不必“工作”，自动化的构建/测试过程将告诉您出了什么问题，并且无论如何，很容易检查git历史记录并联系破坏了构建/测试的作者:-)