Git：管理我的应用程序的每个版本？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/5400460/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Git: Manage each version of my app?
提问by Nic Hubbard
I am using git and github, and I just finished the 1.0 version of my iOS app. From here, I am wondering how git can best serve me.
我正在使用 git 和 github，我刚刚完成了我的 iOS 应用程序的 1.0 版本。从这里开始，我想知道 git 如何才能最好地为我服务。
I really am just looking for a best practice here, and what others recommend for managing major versions.
我真的只是在这里寻找最佳实践，以及其他人推荐的管理主要版本的方法。
Should I create a new branch for each new version, such as for 1.1, 1.5, 2.0, etc? Or should I just keep pushing to the master branch? If so, how do I do this?
我是否应该为每个新版本创建一个新分支，例如 1.1、1.5、2.0 等？还是我应该继续推送到主分支？如果是这样，我该怎么做？
回答by RDL
I would recommend using tags(tag tutorial)
From your master branch since you are done v1.0 add a tag called v1.0.
自从你完成 v1.0 以来，从你的主分支添加一个名为v1.0.
git tag -a v1.0 -m "Tagging release 1.0"
This way you can always come back to a specific version at any time by calling git checkout [tag_name]
这样您就可以随时通过调用返回到特定版本 git checkout [tag_name]
Another common practice is to use branches to work on features until they are stable.
另一种常见的做法是使用分支来处理功能，直到它们稳定为止。
git checkout -b [feature-branch]
That creates a new branch named whatever is in [feature-branch]and checks it out. Be sure to do this from where you want to start working on the feature (typically from master).
这将创建一个名为 what is in 的新分支并将[feature-branch]其检出。请务必从您想要开始处理该功能的位置（通常从master）执行此操作。
Once stable they can then be safely merged into master. From masterrun:
一旦稳定，它们就可以安全地合并到master. 从master运行：
git merge [feature-branch]
This way your masterbranch always stays in a working state and only completed items get added once ready. This will allow you to keep a working copy of the app at all times (ideally anyways) for testing, etc.
这样，您的master分支始终处于工作状态，并且只有在准备就绪后才会添加已完成的项目。这将允许您始终（理想情况下）保留应用程序的工作副本以进行测试等。
You could use branches for each version of the application however using tags makes it so you can't merge into another branch version by accident.
您可以为应用程序的每个版本使用分支，但是使用标签可以使您不会意外合并到另一个分支版本。
回答by ctcherry
Personally, for large projects I've adopted most of the methods shown in this article:
就我个人而言，对于大型项目，我采用了本文中展示的大部分方法：
http://nvie.com/posts/a-successful-git-branching-model/
http://nvie.com/posts/a-successful-git-branching-model/
It has worked out really well for me, and now there are even libraries and tools to help you follow along with the methodology: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
它对我来说效果很好，现在甚至还有一些库和工具可以帮助您遵循该方法：http: //jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
回答by Kyle Falconer
You can also use the new GitHub releasesmechanism. It is a way of managing software versions with GitHub.
您还可以使用新的GitHub 发布机制。这是一种使用 GitHub 管理软件版本的方式。
回答by Karl Bielefeldt
It depends on if you want to maintain older versions with bug fixes only. If you want to add bug fixes to 1.0 while adding new features to 2.0, you create a 2.0 branch, merge all bug fixes into both branches, and features into 2.0. But for each release within each branch all you need is a tag. Just remember to branch fromthe oldest branch you intend to merge back into.
这取决于您是否只想通过错误修复来维护旧版本。如果您想在向 2.0 添加新功能的同时向 1.0 添加错误修复，您可以创建一个 2.0 分支，将所有错误修复合并到两个分支中，并将功能合并到 2.0。但是对于每个分支中的每个版本，您只需要一个标签。请记住从您打算合并回的最旧分支进行分支。
