我正在使用 git 和 github，我刚刚完成了我的 iOS 应用程序的 1.0 版本。从这里开始，我想知道 git 如何才能最好地为我服务。
我真的只是在这里寻找最佳实践，以及其他人对管理主要版本的建议。
是否应该为每个新版本（例如 1.1、1.5、2.0 等）创建一个新分支？还是我应该继续推送到主分支？如果是这样，我该怎么做？
【问题讨论】：
标签： git version-control github versioning
我建议使用tags (tag tutorial)
在您完成 v1.0 后，从您的 master 分支添加一个名为 v1.0 的标签。
git tag -a v1.0 -m "Tagging release 1.0"
这样您就可以随时致电git checkout [tag_name]回到特定版本
另一种常见的做法是使用分支来处理功能，直到它们稳定为止。
git checkout -b [feature-branch]
这将创建一个名为 [feature-branch] 中的任何内容的新分支并检查它。请务必从您想要开始使用该功能的位置开始执行此操作（通常从master）。
一旦稳定，它们就可以安全地合并到master。来自master 运行：
git merge [feature-branch]
这样，您的master 分支始终处于工作状态，并且只有完成的项目在准备好后才会被添加。这将允许您始终（最好无论如何）保留应用程序的工作副本以进行测试等。
您可以为应用程序的每个版本使用分支，但是使用标签可以避免意外合并到另一个分支版本。
【讨论】：
master 是你今天发布的，如果你必须的话。一旦你标记并发布了 1.0（当时的 master），master 就会成为你下一个版本的分支。版本 1.0 标记位于您的历史记录中，以提醒您发布的内容，并且可能是我一分钟前描述的错误修复的分支点。如果你幸运的话，它只是一个参考。
您还可以使用新的GitHub releases 机制。这是一种使用 GitHub 管理软件版本的方法。
【讨论】：
就个人而言，对于大型项目，我采用了本文中显示的大部分方法：
http://nvie.com/posts/a-successful-git-branching-model/
它对我来说效果很好，现在甚至还有一些库和工具可以帮助您遵循该方法：http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
【讨论】：
这取决于您是否只想通过错误修复来维护旧版本。如果您想在 1.0 中添加错误修复同时向 2.0 添加新功能，您可以创建一个 2.0 分支，将所有错误修复合并到两个分支中，并将功能合并到 2.0 中。但是对于每个分支中的每个版本，您所需要的只是一个标签。请记住从您打算合并回的最旧的分支从分支。
【讨论】：