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