真实企业(公司)Git分支开发协作流程

前言

大家好，当你看见这篇文章，我相信你才刚入职，才刚拉项目，才刚写点代码。
接着你突然意识到这些问题：

1. 我要提交到哪个分支
2. 有哪些分支
3. 各分支是干啥用的
4. 平时开发的同事们是如何分支协作的

如果你有上面疑问，恭喜你。这篇文章应该能帮到你，因为本人也是涉世未深的码农小白，很多规范本就不知，加上公司给的Git协作流程图也不算具体，前期还是厚着脸皮问，今天是2023年3月4号周六，本应该放假在家躺尸的我，决定来公司写下这篇帮助各位小白，因为有些同事很SB嫌你烦嫌你这些都不知道而洋洋自得，这种滋味真的不好受

那下面我们开始吧。

分支介绍

1. featrue分支：功能分支。每个开发人员分配完任务后，需要根据另一个分支创建一个featrue分支开发自己的任务代码

2. develop分支：开发分支。全部开发人员的featrue分支开发完的代码要合并这上面

3. release分支：预发布分支（测试分支）。用于develop分支合并到release，然后发布到测试环境用于测试。

4. master分支：生产分支（主分支）。这个分支是用于发布到生产环境的分支，代码稳定性要求是最强的，当release分支发完没问题，就可以合并到master了

5. hotfix分支：热修复分支。如果线上master出现bug了，就会根据master创建hotfix分支，在此分支上进行bug修复，然后再合并回master

看到这里，知道大家还是很蒙，很正常。现在举例我呆过团队的git分支协作流程，结合上面分支概念你可能清楚不少。

Git分支协作流程：团队1

我给大家举了5个分支是很全的了，但实际上不同公司不同团队开发一个项目不会搞这么多分支。比如我的团队1：

团队1就只有两个分支：master和hotfix分支。

平时开发都在master分支上开发，开发完提交代码就完事了。测试环境也是master分支，生产也一样。每次发完master后，开发经理会先创建一个hotfix分支，用于出现bugA了，开发就在这个分支上修复bugA，修复完发布的是hotfix分支。然后开发也要记得在master分支去修复这个bugA，保证下次master迭代时不出现

这种分支开发模式算是最简单的，通常项目也不大。从开发角度，是比较利于Git新手的

Git分支协作流程：团队2

团队2就很规范了，包含了上面所提及的所有分支。刚开始时头疼的很，不知道咋回事只能自己摸索emmmmm

首先，开发经理会先创建3个分支：master,release,develop分支。

以我为例，比如说开发经理分配了任务A，我就根据develop分支创建属于我的featrue分支，一般命名为：featrue-姓名首字母，如张三的话就：featrue-zs作为自己的分支名

接着在featrue-zs开发A任务，开发完呢。这时你要做5步：

1. 提交featrue-zs分支到远程分支。

2. 切换到develop分支更新最新的代码。

3. 当前分支是develop分支，然后把远程featrue-zs分支合并到当前分支

4. 提交本地develop分支到远程分支

5. 再次切换到featrue-zs，合并远程的develop分支进来当前分支，然后再提交代码

合并的过程中可能会出现冲突，这个自行解决哦。一般做完这5步，能保证两个事情：

1. 自己featrue分支代码是最新的，因为其他同事也会合并到develop上

2. 自己featrue分支合并到远程develop，保证其他同事能合并你的代码

其实到这里，我们的任务就完成了。下次再分配任务B，继续在featrue-zs上开发就行，不用删掉。后面develop合并到release,release合并到master都不用你操心，这些都有人做。

你要做的是守护我自己的featrue-zs

最后

大家到不同公司，一定得灵活点。可能有的公司分支没那么多，或者命名不是这样的，比如release分支人家偏叫test，或者develop叫测试分支。我见过有的featrue不叫功能分支，叫开发分支.....

所以具体流程，请大家到公司后可以了解下，最后如果此篇文章有帮到你的话，点个赞呗！