git管理复杂项目代码

我初学前端的时候接触git，那时候只要会add/commit什么的就好了，网上的教程大多都停留在从头到尾一个个介绍git的命令，关于各种用法，特别是多个分支来回交叉冲突的实际处理，很少有这方面的介绍，经过很多次的实践（踩雷:ghost:），想分享一点经验，给刚进入前端的同学做过渡用，但毕竟一千个人有一千个使用git的方式，所以不保证对所有人都是有用的:eyes:

现在在公司开发维护一个比较大的项目，有公司自己实现的各种npm包、框架代码、各种业务公共代码和业务实现代码，总行数五六十万行，频繁的git提交经常导致代码翻车，经历过多次车祸现场也算有点心得:joy:。我司前端代码库主要有dev/test/release环境分支（分别对应后端三个环境），几个大的项目/特性分支和小百个业务分支，主要的规则就是自己开发的特性分支合并到dev（和后端联调）=>合并到test（提交测试同学测试，改bug）=>合并release（测试同学模拟线上环境测试，准备发布线上），说出来感觉非常清晰简单，实际操作会有各种问题，有天灾（临时改需求，后台改字段），有人祸（提交代码不规范）。

外部的可视化工具

如果不是特别熟悉git，还是先老实选一款git可视化 工具 吧，推荐SourceTree（安装后需要免费注册，注册要翻墙），之前用过GitHub Desktop，轻量的git工具，不能满足复杂的需求，后来用了SourceTree，随着版本的更新，越来越好用。 有关SourceTree的使用可以写一篇文章，但是如果对git有稍深一点的理解，非常容易上手，节省了记命令的脑容量，节点图也非常直观。刚使用的同学建议多探索一下，很多操作如解决冲突、重置等比命令行要快，绝大部分命令都能用简单的操作代替。如果git仓库分支多而且关系复杂，纯写命令行的git老司机也容易翻车:sweat_smile:

本地和远程origin

提交代码之前请三思，如果是使用SourceTree，请不要在提交上点击同时推送到远端（ 非常重要 ）

，回退的同时把这中间别人提交的代码也干掉了，于是公司就禁止了除管理员以外对远程仓库的修改。理论上说在这三个环境分支release/test/dev上大家不应该直接提交，应该从其他分支改完merge过来，但是毕竟直接提交更方便，有个精度/样式小bug之类的直接改掉，比切到相应业务分支改掉提交，切回环境分支，merge过来更加的快，但是万一提交出错，就比较尴尬，所以还是不能懒。

提取单次提交cherry-pick

cherry-pick这个命令非常强大，也是我习惯SourceTree后唯二在命令行使用的git命令（还有revert merge），它是提取出某个分支的特定的那次提交应用到其他分支上，精准的操作，对其他代码不会造成任何影响。假如有个紧急bug，即将上线，我直接在release上改了，那么事后一定要同步到自己的特性分支和test等其他环境分支，这时候又不想merge过去，就需要用到cherry-pick了，具体使用命令 git cherry-pick xxxxx ，（xxxxx可以取简略的那个commitId）

回退revert及回退某次合并

分支多，合并也多，先说合并merge， merge xxx1 into xxx2 这个命令中，xxx1是传入分支，xxx2是当前分支，把xxx1分支上的代码合并到xxx2这个分支上，xxx1上新的代码就到了xxx2上了。比如我自己新开发的一个业务分支开发测试都搞得差不多，那我就准备合并到release，很好理解，但是合并完过一段时间被告知不对，不应该上去，产品还有别的想法:flushed:，那就revert吧，（由于前面的原因，reset是被禁止的）revert有优点，会只影响那一次提交的的代码，但是缺点是会产生一个新的节点，revert merge又有不同，还拿上面的例子，假如提前合并上了不该上的代码，那只能revert，具体代码 git revert xxxxx -m 1 xxxxx还是commitId，1表示当前分支为准，2表示传入分支为准，一般都是1，然后自己的特性分支又改了很多，等到了要上release的时候是没法在直接merge的，因为revert是一个比较新的节点，这样就要再次revert那个revert提交的commit（和第一次commit不一样，是revert的commit），完了再进行merge自己特性分支最新的代码就可以了（来回merge加revert超乱的，下次谁出问题直接打死他:sunglasses:）

分支污染

分支污染这个问题主要是针对多个开发任务并行的情况，比如这个优惠券功能打算下周上，那个价格比对功能下下周上，那么这两个分支千万不能互相合并，或者间接合并，道理很简单，但是任务一多很容易乱，还有，多个特性任务分支可以随时把release合并进来（最好经常合并以保持同步），因为这是最终版本，但是不能合并除release之外的其他分支，特别是test/dev分支，test/dev分支上存在了许多各种横死的/半死的项目，这些千万不能出到其他分支，要不然其他分支上到release就把这些垃圾内容带过去上线。总之，各公司情况不同，但是大致结构差不多，把握好单向的代码流就好。

复杂场景

实际情况可能很复杂，因为我们公司用json来保存用户级的各种配置，tsx对某些大型组件里面字段类型做校验，这些都是自动生成的，有时候只改了一点配置，就生成了一大堆更改，这样的反复多人在不同分支修改以后，一合并冲突的连它妈都不认识了，这个仍是当前项目的痛点，有可能每次合并就要花去单人半天一天的工作量，这样的只能手动修改合并，借助编辑器内部工具，如果后期有时间可能会把node层json配置改为mongoDB，但是本地json配置还没有好办法，欢迎留言区提出方案。

编辑器内部git工具（vscode的gitlens和webstorm）

vscode里面的必装插件gitlens最近进行了更新，合并等功能已经快赶上webstorm了，合并的三栏式布局适合修改一些复杂冲突，左右是当前以及传入的代码，中间是自己的修改，非常的科学，还有很多功能如查看当前这个文件所有的历史更改，与某个分支的某个文件的快速比对等等功能，解决了复杂项目的很多痛点。

提交钩子及绕过

公司对git有很多规范，禁止了 push -f ，对commit提交的备注信息做了限制，这个是在自己项目的 .git/hooks/ 里面有限制，可以自己修改，我们统一是必须携带JIRA任务号，便于JIRA统计或者提交的是merge信息，但如果想跳过的话（规则就是用来打破的，:sweat:），可以在SourceTree提交里设置绕过钩子提交

tag的问题

实际在多人协作项目里使用git，基本没有打过tag，tag的问题就在于如果和分支名字一样，切换/合并分支容易到tag，而且打了错误的不合适的tag，必须远程和所有本地一起删除tag，要不然只要有一个人本地有tag，一push又到了远程，难以去除，一般都是在运维用jenkins部署时打个上线日期tag，便于回退（但是如果jenkins部署打的tag不规范、重名，也会引发前端代码库提交各类问题）。

总结

git这东西说简单也简单，说难有的问题直挠头皮，但是我觉得，最重要的是要养成一个好的提交习惯，提交本地前先三思，提交到远程前再想一遍，避免翻车，对团队代码造成灾难型的后果，影响他人工作。 纯手敲出这么多字，如果感觉有些帮助，那我就很满足了，如果有问题尽管提，共同进步！