总结git各大命令详细 且 谈谈git flow流程

入职后，公司使用的是gitlab去做协同开发，相比以前只会在一条master主分支上玩耍，要复杂一些，我觉得吧，git本身的命令不难，难的是要理解协同开发的流程，不能再像以前那像随性的提交，提交也可能变得没那么容易了，毕竟协同开发会涉及到冲突的问题，使用gitlab或者协同开发一般都遵循git flow 流程
git使用规范可参考：Git 使用规范流程

git flow流程，我的理解 ：

一般只有一个master主分支和一个dev分支，每个组员基于dev分支checkout出很多特性分支，各自开发自己的功能，开发结束后 ，向dev分支提出MR（merge request），老大（组长）收到MR请求后，会review（检查）下你的代码，没有问题后同意合并，dev分支上的功能基本合并完后，就会向master主分支发起MR合并请求，master一般是一个稳定的版本，而dev一般是开发版本，基于dev分支克隆出release分支，其中测试工程师会克隆你的release分支，测试功能，测出bug，会在gitlab中提issue，开发看到了就要根据issue去查bug且修复它，测试完成后，合并到dev分支，且删除该release分支，大致流程就是这样

这里重点说下issue吧！因为我司就是采用以issue为中心的git workflow流程推进项目的，基于issue提需求，提bug，做测试，做讨论，做反馈等等。。， issue即是一个任务，也可以表示一个新功能，也可以是一个bug的反馈，提了一个issue，老大一般会指派人去解决这个issue，指派人把dev分支更新到最后后，会checkout一个分支去解决这个issue，分支名也一般以这个issue名字和编号命名，比如：git checkout -b issue#121_xxx问题，最重要的是，当你解决了这个issue，你commit的信息要关联到这个issue上，所有commit的信息一般是以编号开头，描述置后，比如，git commit -m “#121_修复了xxx问题”，这样你push到远程仓库的时候就自动关联到对应的issue页面去了，刚开始接触的小伙伴，肯定也像我一样踩了不少坑吧，哈哈

一个master主分支和一个dev分支，不是硬性规定，git也没有这样规定过，但一般来说开发项目都是基于这样的流程，git flow流程，这大概是前人总结出来的经验吧，这样做，多人开发的时候会好管理，总比打家都往master上push要强得多