携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第29天，点击查看活动详情 >>
前言
前几天偶然听组里的新人开发在抱怨代码老是被人合丢，rebase merge reset force soft傻傻分不清，所以写一篇文章尝试去讲讲协作开发的代码提交流程和分支管理规范
git分支模型
业界的话，有好几种分支模型，比如master-prerelease-develop模型，master-develop模型，其实就是人为的将开发，预发和生产的分支进行了隔离，
功能分支以feature开头，辅以日期及功能缩写比如feature_20220825_goLang ,漏洞修复分支则是直接hotfix+时间即可，如hotfix_20220825等，功能分支的话，建议功能缩写尽量能表达功能原意，这样在看到分支名的时候就知道可能涉及到了哪部分代码的改动
git提交规范
git 的commit规范也是很有必要的，commit里应当标识是功能修复，还是功能新增，还是代码重构，这样之后需要回滚或者review某个历史提交的时候，会很有帮助，不要总是add,update, 暂存之类的就提交上去了习惯非常的不好
git 提交流程
假如是多人协作的功能分支，提交前你需要先对本地要提交的代码进行暂存
- git add
- git commit -m 'feat：xxxxxxxxxxxxxx' 然后需要对远程分支进行拉取
- git pull 默认是以merge的形式进行合并的 是 git fetch 和git merge的缩写，git pull 之后，不出意外，你需要解决冲突后再进行提交，如果比较顺利，那你也需要commit 拉取下来的新内容，然后进行提交
git fast-forwards
这个是git里合并的一种模式，什么是fast-forwards呢，就是 远程分支a的版本1和你本地分支a的版本2存在共同的祖先a，所以1,2假如没冲突的情况下，是可以进行快进合并的，也就是fast-forwards
git rebase 和 git merge
上图里，可以看出，merge会保留细节，而rebase则是消除了feature分支的commit，并且在主分支形成了新的commit，这俩我们用哪个合适呢？这个也是社区一直在讨论的问题，首先我们需要了解他们各自的原理是什么，先来说merge， 比如 我们 git merge master 这个命令的意思是， 将master分支合并进我们的分支内，这时，你的代码会是你的当前分支代码+master分支代码，当你commit后，是为当前分支又加了一个commit，不会同步主分支的commit，仅仅同步代码， 而如果是 git rebase master， 则是相当于，提取你当前分支和master分支共同的那个代码的commit开始，之后的所有提交，会在当前分支重新复制一遍，然后将head指向你当前分支最新的提交，会丢失之前的合并细节
综上所述： 干净的commit 树是 伪需求， merge 比 rebase 的副作用要小而且对新手友好，所以，我建议使用git merge 而不是 git rebase进行分支合并
