当前位置：首页 > news >正文

gitflow在公司的全流程

news 2025/9/21 18:36:57

前言

最近都比较少发博客了，最大的原因是，现在很多问题都能在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 来同步分支，让自己的提交在同事的功能之后。原因可查看：https://juejin.cn/post/7389650358539255845?searchId=20250911222915615E8C6E876B0B660723
另外就是在合并的时候，建议大家都使用 git merge --no-ff 来合并分支，具体原因可看：
a.https://www.cnblogs.com/guanghui-hua/p/18059148
b.廖雪峰的分支管理策略 https://liaoxuefeng.com/books/git/branch/policy/index.html

关键点：

git pull --rebase

sit git merge --no-ff feature

3:遵循第二点：使用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这个命令最好就是用在自己的分支，不要在公共的分支乱用
具体原因如下：
https://juejin.cn/post/7498997224400355347?searchId=20250920192156C4E3E823358EF4E16582
关键点：