使用Git作为项目的版本控制工具时的策略
我使用Git跟踪我的所有开发，并且我始终遵循这一策略。
该策略的灵感来自成功的Git分支模型。
我有2个常驻分支机构：掌握和发展。
这些是我日常工作中要遵循的规则：
当我提出一个新问题或决定合并一项功能时，有两条主要道路：
该功能是一种快速的功能，否则我将进行的后续提交不会破坏代码（或者至少希望如此）：我可以进行开发，也可以进行快速功能分支，然后将其合并以进行开发。
该功能将需要完成多个提交，而完成该功能并再次变得稳定之前，可能需要几天的提交时间：我做一个功能分支，然后合并发展。
如果我们的东西生产服务器需要立即采取行动，就像错误修正一样，我需要尽快解决，我做了一个简短的修补程序分支，修复问题，在本地和测试机上测试分支，然后将其合并以掌握和开发。
如果我需要一个快速功能/编辑要推送到生产服务器上，develop分支中包含一些不稳定的代码，我希望尽快进行功能/编辑，我可以跳过develop分支，执行快速功能分支并将其合并到master和develop中，只要功能/编辑快速且微不足道即可。如果事实证明这会变得更复杂，那么最好等待并稳定开发分支上的代码。
这开发分支将始终处于不断变化的状态，这就是为什么应将其放在“冻结'在准备发行时。对代码进行了测试，并检查了每个工作流程以验证代码质量，并为合并到母版做好了准备。
每次开发或另一个修补程序分支合并到master中时，我标记带有版本号，因此如果出现问题，很容易返回到先前的状态。
更多git教程：
- 一个Git作弊表
- Git工作流程来管理多个分支机构的工作
- 处理Git子存储库的简单方法
- 出色的Git教程的不完整列表
- GitHub开发人员简介
- 完整的Git指南
- 如何使用git bisect发现错误
- 如何在GitHub上发出第一个拉取请求
- 如何从另一个分支更新Git分支
- 我在GitHub上发布了密码/ API密钥
- 压扁Git提交
- 如何删除Git遥控器