前言
最近都比较少发博客了，最大的原因是，现在很多问题都能在ai工具上解答， 而且正确率非常的高，大家还没用上ai工具的赶紧用起来，对自己写代码还是挺有帮助的。往后我会更新一些ai工具的使用，让大家更好的了解ai的现况。 但是git这一块，需要有自己的思想，得知道整体的一个逻辑，才能更好的使用git,而且git在工作中真的很重要，大家都不想浪费时间处理git的问题。今天主要是写在公司用git最标准的一套流程，包括了保持git分支的线性历史，让git分支更加的干净，更好的追溯问题。
公司环境:
一般稍微大一点公司都会把项目分为这几个环境：sit，uat，prod环境。分别对应了测试环境，uat环境和生产环境，sit环境没这么正式，主要用于功能，即功能完成了，就放到sit测试；uat环境更正式一点，用于回归测试，需要功能在sit测试完成再合并到uat；prod环境最正式，需要经过双重测试验证的代码才会合并到这里。 不同的环境对应了不同的分支。 以下一般为相对应的分支（当然，分支名可能不一样）：
sit环境------>sit分支
uat环境------>uat分支
prod环境------>master分支
标准流程
以下为git开发的标准流程：
1.从master分支切出feature分支（一般是一个功能一个feature分支）
2.feature分支开发完成合并到sit分支
3.sit测试完成之后，将feature分支的代码合并到uat分支
4.测试回归测试完成之后，等待发版日， 发版日到来时，从master切出一个release1.x.x分支，将需要发版的功能分支合并到该release1.x.x进行发版。。 待生产验证稳定之后，可以将release1.x.x分支合并到master分支上去
如何正确的使用命令
以上为大部分公司git管理的一个流程。但是今天想要说的，不仅仅只是这些，因为上面是基本，下面要讲的主要是如何去保持分支的线性历史。
以下的命令对应标准流程的每一步
1.从master分支切出feature分支（这里使用 git checkout -b 没什么好说的）
2.feature分支开发完成合并到sit分支（这里就有说法了，大家都知道使用git merge去合并）
但是我们会碰到这种情况，就是你切到了sit分支，你没有先pull，而是先合并了自己的featureA分支，然后你想推代码到远程会报错，需要让你git pull，原因是同事在sit分支上合并了featureB分支并且推送到了远程。这里使用git pull可以，但是会让历史变乱。这里建议使用git pull --rebase 来同步分支，让自己的提交在同事的功能之后。原因可查看：juejin.cn/post/738965...
另外就是在合并的时候，建议大家都使用 git merge --no-ff 来合并分支，具体原因可看：
a.www.cnblogs.com/guanghui-hu...
b.廖雪峰的分支管理策略 liaoxuefeng.com/books/git/b...
关键点：
javascript
git pull --rebase
javascript
sit git merge --no-ff feature3:遵循第二点：使用git pull --rebase和git merge --no-ff
4:遵循第二点：使用git pull --rebase和git merge --no-ff
意外情况
还有一些意外情况：
如：
a.你从master切出的feature分支，但是你当时切出来的时候master分支不是最新的，但是你要更新到master最新的代码。一般人都会使用git merge来更新，但是这样子的话，到时候合并回master分支之后，master分支的历史看起来就会挺乱的，这一块建议大家使用git rebase来更新分支的代码。 git rebase这个命令最好就是用在自己的分支，不要在公共的分支乱用
具体原因如下：
juejin.cn/post/749899...
关键点：
javascript
git rebase masterb.处理git rebase时发生的冲突：打开编辑器，然后解决冲突，解决完冲突之后， 运行：git add . ，然后再运行git rebase --continue来继续进行变基操作。
总结
保持分支线性历史的关键点如下：
1.远程有同事的提交时，少用git pull ，多用 git pull --rebase
2.合并分支少用git merge ，多用git merge --no-ff
3.同步分支少用git merge，多用git rebase 来更新分支代码