说我并行开发了两个版本的库：
我最终得到3个分支：
我的分支错了吗？我应该在哪里提交1.0和2.0的新功能？现在，我在各自的分支中提交每个功能。 1.0错误修正在1.0分支中提交，然后合并到2.0分支。
什么应该包含master？
答案 0 :(得分：4)
鉴于所有答案都没有引用任何来源，并且都自相矛盾，我决定遵循Doctrine's workflow（鉴于我还在开发一个PHP库，而Doctrine是一个“现代”/最近的项目）。
doctrine存储库包含以下主要分支：
- doctrine / master 向下一个版本开发。
- doctrine / release - * 现有版本的维护分支。这些 分支并行存在，定义如下：
doctrine / master是HEAD源代码所在的分支 反映了最新版本。每个发布的稳定版本都是 在doctrine / release- *分支中标记了提交。每次释放不稳定 version将是doctrine / master分支中的标记提交。
简而言之，它与SVN工作流程非常相似：
如果我在1.0和2.0（未来的实验版本）的并行开发中有 3.0 版本，我就不知道该怎么办。我想我会创建一个3.0分支并在主服务器上留下2.0（给定2.0是“下一个”版本）。
答案 1 :(得分：2)
这里没有正确的方法或错误的方法。对于某些项目，将master视为“不稳定”分支会很有用，因此您的大部分开发工作都集中在那里。 （通常，在自己的分支机构中处理新功能并将这些功能合并到主数据库中会有所回报）。现在，通过您的版本分支，您可以轻松地合并或从主人那里挑选更改。根据项目的工作方式，您可能需要一个策略，指出版本分支应始终处于良好状态，并且任何提交都应增加版本号。
拥有一个不动的主分支是非常方便的，因为你可以设置一次的分支，并期望git pull总是为你提供项目的最新代码。
答案 2 :(得分：1)
master在所有“前沿”代码所属的分支的约定名称中。如果您对代码的特定版本进行分支，则可以 - 对它们进行修复，但是在master中进行代码转换，然后使用您的版本名称从master创建分支。
答案 3 :(得分：-1)
主git分支由git默认创建。它应该包括您的软件产品的最新稳定版本，或者换句话说，您希望用户默认下载的分支。您应该将实验性功能提交给v1和v2分支。