最近我越来越多地使用git和GitHub了，尽管我理解了分支的概念，但是我还不了解人们在实践中实际使用分支的方式吗？
我怎么知道是时候维护不同的分支了，什么时候开始提交除主分支以外的任何东西？
我主要依靠自己和我自己开发，而且我不需要跟上“生产”和“开发”版本，因为我的大多数东西都在开发中。仍然：在这种情况下，我将代码保存在不同的分支中对我有什么好处吗？
答案 0 :(得分：3)
以下是我喜欢使用的名为git-flow的模式：git-flow
答案 1 :(得分：1)
一个常见的范例是尽可能多地提交，以便在开发过程中实现非常小的增量步骤，因为如果事情变得糟糕，这可以很容易地回到历史中。如果您仅在主分支上进行所有开发，则修订历史记录将会很长，因为包含大量注释，因此很难区分添加功能时的情况。
另一种方法是为新功能创建分支，并在那里进行所有增量开发。如果您对设计/代码感到满意，那么您可以压缩修订历史记录并将其合并回master，然后将拥有一个基于特征的非常干净的历史记录，您不需要看到所有的小步骤。< / p>
答案 2 :(得分：0)
我建议将master分支保持在随时可以发布的状态。如果你所有的提交都真的“坚固”，那么就不需要分支了。
我习惯于在每个新功能的专用分支上工作。这样，如果我必须紧急修复一个错误，例如因为我收到Android应用程序的崩溃报告，我可以暂停我当前的工作，修复master中的错误，打包新版本，然后返回我离开的地方。
顺便说一句，我用这个命令将我的功能分支合并为master：
git merge --no-ff --no-commit the_branch
git commit -m 'merged: improved this and that'
这样，当我查看gitk中的历史记录时，我会看到每个功能分支的详细实现步骤。
答案 3 :(得分：0)
正确的分支策略在很大程度上取决于项目，团队成员和外部需求。有一些像git-flow这样的一般模式，但是你应该总是问自己在你的情况下是否有意义。
在您的情况下，您单独使用代码，您不必维护不同版本的代码，也没有外部要求。 - 因此，你可以自由地做什么，所有复杂的模式真的有点过分。
我建议在github上只有一个分支（master）。在您的本地存储库中，您很可能也会使用master。每当你完成一些步骤就会提交，只要你对当前的工作状态感到满意，就会推送到github。
请注意提交和推送之间的区别：只要您没有推送，您就可以随时更改提交，修复错误，重新提交提交等。 - 因此，您很可能不需要任何显式分支。< / p>
如果您愿意，可以使用分支机构获得更清晰的历史记录。如果您正在开发一个接一个的功能并经常提交它可能会导致很长的历史。 在这种情况下，您可以在自己的分支上开发每个功能，并在完成时将其合并（--no-ff）。 - 然后你的主分支应该只包含（ - first-parent）每个功能一个合并。但在你的情况下，这可能已经过度了。
答案 4 :(得分：0)
书中的Branching Workflows一章 - Scott Chacon的Pro Git解释了一些git工作流程。由于git非常灵活，您可以拥有自己的工作流程。例如，
Release -> Production Deployment
Master -> Most Stable tested branch - Deployed on staging
All other branches -> One branch for each feature
答案 5 :(得分：0)
我刚刚意识到我应该更多地搜索stackoverflow，我不需要问这个问题。
这是一个4岁的锁定问题，我认为我需要知道关于Git和GitHub的一切，包括socketwiz提到的git-flow范例。