Git在项目开发管理中常用套路

0x00 前言

初学Git时看过一篇博文, 说如若就职公司不使用Git就坚决离职. 现在想来, 还真不是因为作者性格倔强, 因为作者知道, 这样的公司不是做事的.

此文也是我所在公司所负责项目推行的实践方法, 其实对Git我们也是在不断的摸索和改进, 这里阐述的也是目前我个人认为比较适用了大多数场合的

环境, 无论搭建的是Github, Gitlab, 管理方法都一样, 以下以Gitlab为例

0x01 两种方法

其实作为分布式版本管理, 并且流行度又如此之高的Git来说, 不乏各式各样的工作流程规范. 但其实真正的目的无非就是做事, 而做事无非就是简单, 高效, 所以我总结了两句话来代表两种方法来阐述Git在实际项目中如何用的简单又高效.

origin/feature -> origin/master

该方法其实就是Git最原始的工作流模型, 无论是何种体系最终都要回归这一句.

在该模式下, 所有人员操作的是真正的代码仓库, 人员只有Owner和Developer, master分支被protected, 只能由Owner合并, 对应实际工作就是只有Owner具备审核和合并master的权限

那么实际工作起来流程就类似于:
Developer(包括Owner), 先在本地从最新的master clone出一个分支, 然后完成任务, 完成后push到origin, 发PR由Owner进行审核并决定是否合并, Over.

很简单吧, 保守估计也有超过90%的内部开发团队都是基于此方法的.

someone/master -> origin/master

其实就是fork工作流程.

除了Owner外, 所有人都是Reporter, 每个Reporter从Owner的master clone出自己的master, 然后完成任务, 需要提交的时候也是发PR给owner, 但需要自己来merge Owner的master来保证master是最新的

0x02 总结

两种方法可以混搭. 适用场景比如你的team核心研发人员可以设置为developer, 他们熟悉项目, 熟悉敏捷开发, 不会轻易写出bug一堆的代码, 也不会把commit写的晦涩难懂, 这样, 他们非常适用于第一种方法, 因为他们能很好的维护你真实的版本库, 推进版本迭代; 当你的项目需要开源给其他团队使用或新人, 那就将他们列为reporter, 给他们一个任务, 让他们自己随意的玩自己的master吧, 这样, 即有机会练手, 也不至于把真正的仓库分支和commit搞乱.

Git的使用帮助网上已经是很多了, 但实战方面少的可怜, 无论如何演化, 都逃不过origin/feature -> origin/master这一关. 换言之, 切不可执念于精通Git, 掌握其本质并用好即可, 就算以后遇到git命令难题, google一下便知