干货：基于 Git Flow 的 Git 最佳实践（附加解决大家经常碰到的问题）

Posted 2020-09-29

突然想写这一篇Git的使用心得，主要有几个原因，其一是自己使用Git也有快3年时间了，其间自己经历过一些坑，也有迷茫的时候，在呆过的大大小小的团队中，其实每个人也都并不是Git专家，很多对于流程以及Git本身的理解，还处于一个比较混乱的地带。自己写这篇文章希望能抛砖引玉，在总结自己得失的同时，能给大家带来更深层次的思考。

直接进入主题，经过这么多年的实践，多次想避开Git flow寻找更简单的流程，每次自认为找到了捷径，但事实上都发现有这样或者那样更多的问题，所以，我认为最佳的Git实践，仍然得基于标准的Git Flow，来看看Git Flow的标准模型，下面是大家非常熟悉的图：

 

 

来自非常经典的Git flow奠基论文：http://nvie.com/posts/a-successful-git-branching-model/

基于这个Git Flow，我所认为的Git 最佳实践，补充和修复了这么几点：

1.分支一共有5类，名称用 / 来区分是因为Sourcetree里面 / 可以作为一个文件夹使用，命名标准为下面这样：

master

develop

feature/***

release/v13.5

hotfix/v13.2

本地的分支可以有一些其他的命名规则，没关系，但是推到远程的必须是这几种命名规范，最好一字不差，比如不要把release写成Release

2.此Git Flow唯一可以变通的地方为开发的时候非必须一定要用feature分支，比如说一个项目刚开始开发的时候，或者突然发现一个不是特别严重的bug，我现在先修改下，想在下一个版本发的时候一起带出去，这种情况就在develop上面改就行了。

3.与Git Flow的论文略微不同，我倡导的是：一个版本开发完成，需要提测的时候，由各个feature合并到develop，然后在develop上开发自测，修复bug，正式提测的时候，由develop迁出release分支，提测

 

我个人认为这是一个非常良好的开发模型，伸缩性强，适用于各个规模的开发团队，一个人开发，我也会这么干，20个人的团队，也是没有任何问题的。关于这个模型，如果有任何疑问，都可以关注我的公众号（文章底部），然后给我发消息，我会一一解答。

 

还有关于之前收集网友的很多问题和疑问，我在这里一一回答下：

1，最经常问的，为什么忽略文件无效

因为Git的忽略文件没有办法对已经纳入版本库的文件生效，解决办法：gitignore里面添加完之后，把本地文件删了，然后commit，push上去，别人再更新，就OK了，下次还有这种类型的文件，就直接忽略了

2，Git可以添加项目中的文件夹权限控制吗

不行，问这个问题的原因是因为很多人把svn的思维搬到Git上来，Git并不是以文件夹为单位来组织的，所以现在大多数公司中UI的图片等资源，像png，psd等文件都是用的svn管理，代码用Git管理。想要用这种权限控制的话，很多人另辟捷径选择用Git的子模块和子数来处理，我感觉也是不太好

3，关于Git客户端

我认为就两种选择，命令行和Sourcetree等全局的客户端软件，TortoiseGit根本不适用，原因就是Git不是以文件夹为组织单位的，Tortoise是依托于文件管理器的操作，所以不对付。然后就是各种IDE的插件，很多人用，我个人也是不喜欢，原因很简单，Git是一种生活方式，并不只是在项目中用用而已

4，关于Git代码回滚

暴力派reset：

本地的分支先（reset）重置到一个commit，然后：git push -f，强推，这种是属于删除commit历史的行为，而且强推需要权限，一般来说master分支默认都不让强推

优点：彻底清除版本库上无用的代码，干净，但是做这种操作的同时，最好本地新建一个分支备份下代码

缺点：误操作的代价比较大

婉约派revert：

git revert HEAD~1（1代表从0到1，回退包含当前commit的两个commit，然后会创建新的commit）

优点：所有历史都在，回退的做法为新建一个commit来回滚之前几个commit的代码

缺点：回退几个commit这个需要手动计算，比较烦

 

5，cherry pick合并单个提交

cherry pick不能完全合并单个commit，因为每个commit都是建立在前一个commit之上

 

关于我：android和JavaEE开发工程师，运营有微信公众号"大土豆爱开发"，原则“简单，分享”，涉及的内容包括但不限于JavaEE,Android,Git等，欢迎大家关注，共同学习。

二维码: