最近我越来越多地使用git和GitHub了，虽然我在一般和理论上理解了分支的概念，但我还没有理解人们在实践中实际使用分支的方式？
我怎么知道是时候维护不同的分支以及何时开始提交除 master 分支以外的任何东西？
我主要是自己开发和为自己开发，我不必完全跟上“生产”和“开发”版本，因为我的大部分东西都在大量开发中。仍然：在这种情况下，将我的代码保存在不同的分支中对我有什么好处吗？
问问题
738 次
6 回答
3
这是我喜欢使用的一种称为 git-flow 的模式：git-flow
于 2013-04-13T12:02:40.953 回答
1
一个常见的范式是尽可能频繁地提交，以便在开发中实现非常小的增量步骤，因为如果出现问题，这可以很容易地回到历史中。如果您仅在 master 分支上进行所有开发，则修订历史记录将非常长，因为其中包含大量注释，因此难以区分何时添加了特色。
另一种方法是为新功能创建一个分支并在那里进行所有增量开发。当您对设计/代码感到满意时，您可以压缩修订历史并将其合并回主控，然后将拥有一个非常干净的基于功能的历史记录，您无需查看让您到达那里的所有小步骤。
于 2013-04-13T12:10:18.653 回答
0
我刚刚意识到我应该更多地搜索stackoverflow，我不需要问这个问题。
这是一个 4 年前的锁定问题，其中包含我认为我需要了解的关于 Git 和 GitHub 的所有内容，包括 socketwiz 提到的 git-flow 范例。
于 2013-04-13T16:26:56.960 回答
0
书中的分支工作流一章- 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
于 2013-04-13T14:30:24.583 回答
0
我建议将master分支保持在随时可以发布的状态。如果你所有的提交都是“可靠的”，那么就不需要分支。
我养成了为每个新功能在专用分支上工作的习惯。这样，如果我必须紧急修复错误，例如因为我收到来自 Android 应用程序的崩溃报告，我可以暂停我当前的工作，修复错误master，打包新版本，然后回到我离开的地方。
顺便说一句，我使用以下命令将我的功能分支合并到 master 中：
git merge --no-ff --no-commit the_branch
git commit -m 'merged: improved this and that'
这样，当我查看 中的历史记录时gitk，我会看到每个功能分支很好地分组的详细实现步骤。
于 2013-04-13T12:17:54.780 回答
0
正确的分支策略很大程度上取决于项目、团队中的工作人员和外部需求。有一些通用模式，例如 git-flow，但您应该始终问自己，它们在您的情况下是否有意义。
在您的情况下，您独自处理代码，您不必维护不同版本的代码，也没有外部要求。- 因此你可以很自由地做什么，所有复杂的模式真的是矫枉过正。
我建议在 github 上只有一个分支（主）。在您的本地存储库中，您很可能也会在 master 上工作。每当您完成某个步骤时，您就提交，并且只要您对当前工作状态感到满意，您就会推送到 github。
请注意提交和推送之间的区别：只要您不推送，您就可以随时更改提交、修复错误、重新排序提交等 - 因此您很可能不需要任何显式分支。
如果您愿意，可以使用分支来获得更清晰的历史记录。如果你一个接一个地开发一个特性并且经常提交它可能会导致很长的历史。在这种情况下，您可以在自己的分支上开发每个功能，并在完成后将其合并（--no-ff）以掌握。- 那么你的主分支应该只包含（--first-parent）每个功能一个合并。但这在您的情况下可能已经过大了。
于 2013-04-13T13:08:08.133 回答