【Git#6】多人协作企业级开发模型

一、多人协作

1. 同一分支下的协作

目前，我们所完成的工作如下：

基本完成 Git 的所有本地库的相关操作，git基本操作，分支理解，版本回退，冲突解决等等
申请码云账号，将远端信息clone到本地，以及推送和拉取。

是时候干最重要的一件事情了，实现多人协作开发!为了做这件事情，我们需要先做一些准备工作

我们之前已经将项目 clone 到了指定目录，如下：

lighthouse@VM-8-10-ubuntu:git_learning$ pwd
/home/lighthouse/code/gitcode/git_learning

然后我们在 windows 环境下，再 clone 同一个项目仓库，来模拟和你一起协作开发的另一名小伙伴，如下：

注意：上面我们是模拟了两个用户，但是在实际开发中，每个用户都需要有自己的 gitee/github 账号，如果要多人进行协同开发，必须将用户添加进开发者，用户才有权限进行代码提交

然后进行对用户邀请即可

到此，相当于有了两个用户，分别在 linux 和 windows 上针对于同项目进行协作开发，我们的准备工作到此结束

目前，我们的仓库中只有一个 master 主分支，但在实际的项目开发中，在任何情况下其实都是不允许直接在 master 分支上修改代码的，这是为了保证主分支的稳定。所以在开发新功能时，常常会新建其他分支，供开发时进行迭代使用。

那么接下来，就让我们在 gitee 上新建 dev 远程分支供我们使用：

创建成功，结果如下：

🔥 创建成功的远程分支是可以通过 Git 拉取到本地来，以实现完成本地开发工作。

接下来让我们和另一名开发的小伙伴都将远程仓库进行一次拉取操作，并观察结果：

Linux 下进行操作：

lighthouse@VM-8-10-ubuntu:git_learning$ git pull
From gitee.com:island0920/git_learning* [new branch]      dev        -> origin/dev
Already up to date.lighthouse@VM-8-10-ubuntu:git_learning$ git branch -rorigin/HEAD -> origin/masterorigin/devorigin/masterlighthouse@VM-8-10-ubuntu:git_learning$ git checkout -b dev origin/dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.   # 把远程 dev 分支和本地建立联系
Switched to a new branch 'dev'# 查看连接
lighthouse@VM-8-10-ubuntu:git_learning$ git branch -vv 
* dev    61120f2 [origin/dev] first functionmaster d80980f [origin/master] gitignore 配置

注意：之前我们用的 git branch 只能查看本地分支，如果要查看本地分支的话需要加上 -r 选项
但是前提是需要 pull 拉取最新的远端仓库才可以看到最新的内容

拉取后便可以看到远程的 dev 分支，接着切换到 dev 分支供我们进行本地开发

要说明的是，我们切换到的是本地的 dev 分支，根据示例中的操作，会将本地分支和远程分支的进行关系链接。

Windows 下进行操作：

PS D:\笔记\git_learning> git pull
From https://gitee.com/island0920/git_learning* [new branch]      dev        -> origin/dev
Already up to date.PS D:\笔记\git_learning> git branch -a
* masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/master# 或者可以用 git branch --set-upstream-to=origin/dev dev 远程链接
PS D:\笔记\git_learning> git checkout -b dev 
Switched to a new branch 'dev'
branch 'dev' set up to track 'origin/dev'.

欧克，现在让我们来正式在 dev 进入开发中，如下：

lighthouse@VM-8-10-ubuntu:git_learning$ cat file.txt
hello git
complete the first function!lighthouse@VM-8-10-ubuntu:git_learning$ git add file.txt
lighthouse@VM-8-10-ubuntu:git_learning$ git commit -m "first function"
[dev 61120f2] first function1 file changed, 2 insertions(+), 1 deletion(-)
lighthouse@VM-8-10-ubuntu:git_learning$ git push origin dev # 把 dev 分支推送到远端

让我们此时来看看码云的状态，如下：

至此，我们已经将代码成功推送至码云，接下来假如你的小伙伴要和你协同开发，碰巧也要对file.txt文件作修改，并试图推送，例如：

# 打开对应文件, 在记事本下进行修改（Windows 无 vim 指令）
PS D:\笔记\git_learning> cat .\file.txt
hello git
complete the secone function!
PS D:\笔记\git_learning> git add .\file.txt
PS D:\笔记\git_learning> git commit -m "secone function"
[dev 5eac3b0] secone function1 file changed, 1 insertion(+), 2 deletions(-)# 推送失败
PS D:\笔记\git_learning> git push
To https://gitee.com/island0920/git_learning.git! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'https://gitee.com/island0920/git_learning.git'
hint: Updates were rejected because the remote contains work that you do not
hint: have locally. This is usually caused by another repository pushing to
hint: the same ref. If you want to integrate the remote changes, use
hint: 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这时推送失败，因为你的小伙伴的最新提交和你推送的提交有冲突，解决办法也很简单，Git已经提示我们，先用 git pull 把最新的提交从 origin/dev 抓下来，然后，在本地进行合并，并解决冲突，再推送。

操作如下:

# 1. 重新拉取
PS D:\笔记\git_learning> git pull# 2. 修改冲突情况
PS D:\笔记\git_learning> cat .\file.txt
hello git
<<<<<<< HEAD
complete the secone function!
=======
complete the first function!
>>>>>>> 1ebc3e7d698207bf142649e1fd7ec97385316ae4
PS D:\笔记\git_learning> cat .\file.txt
hello git
complete the secone function!
complete the first function!# 3. 再次提交
PS D:\笔记\git_learning> git add .\file.txt
PS D:\笔记\git_learning> git commit -m "merge dev"
[dev 961a8e1] merge dev
PS D:\笔记\git_learning> git push

此时，在码云的 dev 分支下就可以看到当前的新提交了

因此此时我们就可以进行协同开发了，只要不断的进行 git pull/add/commit/push，遇到了冲突，按照之前所学解决即可

对于Linux 端来说，要想看到Windows的代码，只需要 pull一下即可

最后不要忘记，虽然我们是在分支上进行多人协作开发，但最终的目的是要将开发后的代码合并到master上去，让我们的项目运行最新的代码。

接下来我们就需要做这件事情了：

在去 master 分支去合并的时候，我们可以养成一个好习惯：就是先在 dev 分支下合并 master 分支
这么做是因为如果有冲突，可以在 dev 分支上进行处理，而不是在在 master 上解决冲突

lighthouse@VM-8-10-ubuntu:git_learning$ git checkout dev
Already on 'dev'
Your branch is up to date with 'origin/dev'.
lighthouse@VM-8-10-ubuntu:git_learning$ git merge master
Already up to date.

在 dev 分支上合并发现无误之后，再切换到 master 分支进行操作，如下：

lighthouse@VM-8-10-ubuntu:git_learning$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
lighthouse@VM-8-10-ubuntu:git_learning$ git merge dev
Updating d80980f..961a8e1
Fast-forwardfile.txt | 3 ++-1 file changed, 2 insertions(+), 1 deletion(-)lighthouse@VM-8-10-ubuntu:git_learning$ git status
On branch master
Your branch is ahead of 'origin/master' by 4 commits.(use "git push" to publish your local commits)nothing to commit, working tree clean# 推送 master 分支到远端
lighthouse@VM-8-10-ubuntu:git_learning$ git pushlighthouse@VM-8-10-ubuntu:git_learning$ git status
On branch master
Your branch is up to date with 'origin/master'.nothing to commit, working tree clean

此时在远端仓库的 master 分支下，master 已经是最新的了，如下：

此时，dev分支对于我们来说就没用了，那么dev分支就可以被删除掉。我们可以直接在远程仓库中将 dev 分支删除掉，如下：

小结，在同一分支下进行多人协作的工作模式通常是这样：

首先，可以试图用 git push origin branch-name 推送自己的修改;
如果推送失败，则因为远程分支比你的本地更新，需要先用 git pull 试图合并;
如果合并有冲突，则解决冲突，并在本地提交（但是解决冲突比较麻烦，一般都是在不同分支下进行的操作）
没有冲突或者解决掉冲突后，再用 git push origin branch-name 推送就能成功!
功能开发完毕，将分支 merge 进 master，最后删除分支。

2. 不同分支下的协作

🔥 一般情况下，如果有多需求需要多人同时进行开发，是不会在一个分支上进行多人开发，而是一个需求或一个功能点就要创建一个 feature 分支。

现在同时有两个需求需要你和你的小伙伴进行开发，那么你们俩便可以各自创建一个分支来完成自己的工作。在上个部分我们已经了解了可以从码云上直接创建远程分支，其实在本地创建的分支也可以通过推送的方式发送到远端。在这个部分我们就来用一下这种方式。

对于你来说，可以进行以下操作:

lighthouse@VM-8-10-ubuntu:git_learning$ git branchdev
* master
lighthouse@VM-8-10-ubuntu:git_learning$ git checkout -b feature-1
Switched to a new branch 'feature-1'
lighthouse@VM-8-10-ubuntu:git_learning$ cat function1
Done!# 提交
lighthouse@VM-8-10-ubuntu:git_learning$ git add function1
lighthouse@VM-8-10-ubuntu:git_learning$ git commit -m "add function1"# 直接推送 -- 失败
lighthouse@VM-8-10-ubuntu:git_learning$ git push
fatal: The current branch feature-1 has no upstream branch.
To push the current branch and set the remote as upstream, usegit push --set-upstream origin feature-1# 本地创建分支推送到远端 
lighthouse@VM-8-10-ubuntu:git_learning$ git push origin feature-1
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 2 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 268 bytes | 268.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [1.1.5]
remote: Set trace flag fe457285
remote: Create a pull request for 'feature-1' on Gitee by visiting:
remote: https://gitee.com/island0920/git_learning/pull/new/island0920:feature-1...island0920:master
To gitee.com:island0920/git_learning.git* [new branch]      feature-1 -> feature-1# 分支推送成功
lighthouse@VM-8-10-ubuntu:git_learning$ git branchdev
* feature-1master

然后再切换到 Windows 上，相当于另一个人可以进行如下操作：

# 操作之前, 需要保证最新的 git pull
PS D:\笔记\git_learning> git checkout -b feature-2
Switched to a new branch 'feature-2'# 去对应目录创建并编写文件
PS D:\笔记\git_learning> cat .\function2.txt
I am coding...PS D:\笔记\git_learning> git add .
PS D:\笔记\git_learning> git commit -m "add function2"
[feature-2 d25c5b3] add function21 file changed, 1 insertion(+)create mode 100644 function2.txt# 直接推送失败
PS D:\笔记\git_learning> git push
fatal: The current branch feature-2 has no upstream branch.
To push the current branch and set the remote as upstream, usegit push --set-upstream origin feature-2To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.# 推送成功
PS D:\笔记\git_learning> git push origin feature-2
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 20 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 279 bytes | 279.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [1.1.5]
remote: Set trace flag 4d424297
remote: Create a pull request for 'feature-2' on Gitee by visiting:
remote: https://gitee.com/island0920/git_learning/pull/new/island0920:feature-2...island0920:master
To https://gitee.com/island0920/git_learning.git* [new branch]      feature-2 -> feature-2

此时，在本地，你看不见他新建的文档，他看不见你新建的文档。并且推送各自的分支时，并没有任何冲突，你俩互不影响，用起来很舒服!!

此时远端码云的状态如下：

两个人协作开发的状态图也如下：

正常情况下，你俩就可以在自己的分支上进行专业的开发了!

但天有不测风云，另一个人突然生病了，但需求还没开发完，需要你帮他继续开发，于是他便把 feature-2分支名告诉你了。这时你就需要在自己的机器上切换到 feature-2 分支帮忙继续开发

其实现在的操作就和之前在同一分支类似了，要做的操作如下：

# 操作之前, 必须先拉取远端仓库
lighthouse@VM-8-10-ubuntu:git_learning$ git pull# 可以看到远程已经有了 feature-2
lighthouse@VM-8-10-ubuntu:git_learning$ git branch -adev
* feature-1masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master# 切换到feature-2分⽀上，可以和远程的feature-2分⽀关联起来，
# 否则将来只使⽤ git push 推送内容会失败
lighthouse@VM-8-10-ubuntu:git_learning$ git checkout -b feature-2 origin/feature-2
Branch 'feature-2' set up to track remote branch 'feature-2' from 'origin'.
Switched to a new branch 'feature-2'
lighthouse@VM-8-10-ubuntu:git_learning$ ls
a.so  b.ini  file.txt  function2.txt  README.en.md  README.md

切换成功后，便可以看见 feature-2 分支中的 function2 文件了，接着就可以帮小伙伴进行开发：

lighthouse@VM-8-10-ubuntu:git_learning$ cat function2.txt
I am coding...
I am coding...# 推送内容
lighthouse@VM-8-10-ubuntu:git_learning$ git add .
lighthouse@VM-8-10-ubuntu:git_learning$ git commit -m "md function2"
[feature-2 d026c28] md function21 file changed, 2 insertions(+), 1 deletion(-)
lighthouse@VM-8-10-ubuntu:git_learning$ git push origin feature-2

这时，另一个人已经修养的差不多，可以继续进行自己的开发工作，那么他首先要获取到你帮他开发的内容，然后接着你的代码继续开发。或者你已经帮他开发完了，那他也需要在自己的电脑上看看你帮他写的代码：

PS D:\笔记\git_learning> git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 (from 0)
Unpacking objects: 100% (3/3), 244 bytes | 8.00 KiB/s, done.
From https://gitee.com/island0920/git_learningd25c5b3..d026c28  feature-2  -> origin/feature-2
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.git pull <remote> <branch>If you wish to set tracking information for this branch you can do so with:git branch --set-upstream-to=origin/<branch> feature-2 # 需要远端再次链接# 发现之前 push 失败, 内容不变
PS D:\笔记\git_learning> cat .\function2.txt
I am coding...

Pull 无效的原因是小伙伴没有指定本地 feature-2 分支与远程 origin/feature-2 分支的链接
根据提示，设置 feature-2和origin/feature-2 的链接即可

PS D:\笔记\git_learning> git branch --set-upstream-to=origin/feature-2 feature-2
branch 'feature-2' set up to track 'origin/feature-2'.
PS D:\笔记\git_learning> git pull
Updating d25c5b3..d026c28
Fast-forwardfunction2.txt | 3 ++-1 file changed, 2 insertions(+), 1 deletion(-)# 拉取成功
PS D:\笔记\git_learning> cat .\function2.txt
I am coding...
I am coding...

目前，小伙伴的本地代码和远端保持严格一致。你和你的小伙伴可以继续在不同的分支下进行协同开发了。

注意：各自功能开发完毕后，不要忘记我们需要将代码合并到 master 中才算真正意义上的开发完毕。

由于你的小伙伴率先开发完毕，于是开始 merge：

# 1. 切换至 master. pull 保证本地是最新内容
PS D:\笔记\git_learning> git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
PS D:\笔记\git_learning> git pull
Already up to date.# 2. 切换分支, 合并 master 分支
PS D:\笔记\git_learning> git checkout feature-2
Switched to branch 'feature-2'
Your branch is up to date with 'origin/feature-2'.
PS D:\笔记\git_learning> git merge master
Already up to date.# 3. 切换至 master 分支, 合并分支
PS D:\笔记\git_learning> git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
PS D:\笔记\git_learning> git merge feature-2
Updating 961a8e1..d026c28
Fast-forwardfunction2.txt | 2 ++1 file changed, 2 insertions(+)create mode 100644 function2.txt# 4. 推送 master 分支
PS D:\笔记\git_learning> git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.(use "git push" to publish your local commits)nothing to commit, working tree cleanPS D:\笔记\git_learning> git push origin master

同样地，我们开发完之后，也要进行如上操作，如下：

# 切换⾄ master分⽀, pull ⼀下，保证本地的master是最新内容。
# 合并前这么做是⼀个好习惯
lighthouse@VM-8-10-ubuntu:git_learning$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
lighthouse@VM-8-10-ubuntu:git_learning$ git pull
From gitee.com:island0920/git_learning961a8e1..d026c28  master     -> origin/master
Updating 961a8e1..d026c28
Fast-forwardfunction2.txt | 2 ++1 file changed, 2 insertions(+)create mode 100644 function2.txt# 切换⾄ feature-1 分⽀, 合并 master 分⽀
# 这么做是因为如果有冲突，可以在feature-1分⽀上进⾏处理，⽽不是在在master上解决冲突。
# 这么做是⼀个好习惯
lighthouse@VM-8-10-ubuntu:git_learning$ git checkout feature-1
Switched to branch 'feature-1'
lighthouse@VM-8-10-ubuntu:git_learning$ git merge master
Merge made by the 'ort' strategy.function2.txt | 2 ++1 file changed, 2 insertions(+)create mode 100644 function2.txt
lighthouse@VM-8-10-ubuntu:git_learning$ ls
a.so  b.ini  file.txt  function1  function2.txt  README.en.md  README.md# 1、由于feature-1分⽀已经merge进来了新内容，为了保证远程分⽀最新，所以最好push⼀下。
# 2、要 push 的另⼀个原因是因为在实际的开发中，master的merge操作⼀般不是由我们⾃⼰在本地
# 进⾏操作，其他⼈员或某些平台merge时，操作的肯定是远程分⽀，所以就要保证远程分⽀的最新。
# 3、如果 merge 出现冲突，不要忘记需要commit才可以push!!
lighthouse@VM-8-10-ubuntu:git_learning$ git push origin feature-1
Enumerating objects: 4, done.
...# 切换至 master 分支, 合并 feature-1 分支
lighthouse@VM-8-10-ubuntu:git_learning$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.
lighthouse@VM-8-10-ubuntu:git_learning$ git merge feature-1
Updating d026c28..cff72ed
Fast-forwardfunction1 | 1 +1 file changed, 1 insertion(+)create mode 100644 function1# 推送 Master 到远端
lighthouse@VM-8-10-ubuntu:git_learning$ git status
On branch master
Your branch is ahead of 'origin/master' by 2 commits.(use "git push" to publish your local commits)nothing to commit, working tree clean
lighthouse@VM-8-10-ubuntu:git_learning$ git push origin master

此时远程仓库状态如下：

此时， feature-1 和 feature-2 分支对于我们来说就没用了，那么我们可以直接在远程仓库中将dev分支删除掉:

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

3. 思考

为啥远程分支删除后，本地 git branch-a 依然能看到，该怎么解决？

当前我们已经删除了远程的几个分支，使用 git branch-a 命令可以查看所有本地分支和远程分支，但发现很多在远程仓库已经删除的分支在本地依然可以看到。

例如：

lighthouse@VM-8-10-ubuntu:git_learning$ git pull
Already up to date.
lighthouse@VM-8-10-ubuntu:git_learning$ git branch -adevfeature-1feature-2
* masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master

使用命令 git remote show origin，可以査看remote地址，远程分支，还有本地分支与之相对应关系等信息。

lighthouse@VM-8-10-ubuntu:git_learning$ git remote show origin
* remote originFetch URL: git@gitee.com:island0920/git_learning.gitPush  URL: git@gitee.com:island0920/git_learning.gitHEAD branch: masterRemote branches:master                        trackedrefs/remotes/origin/dev       stale (use 'git remote prune' to remove)refs/remotes/origin/feature-1 stale (use 'git remote prune' to remove)refs/remotes/origin/feature-2 stale (use 'git remote prune' to remove)Local branches configured for 'git pull':dev       merges with remote devfeature-2 merges with remote feature-2master    merges with remote masterLocal ref configured for 'git push':master pushes to master (up to date)

此时我们可以看到那些远程仓库已经不存在的分支，根据提示，使用 git remote prune origin 命令：

lighthouse@VM-8-10-ubuntu:git_learning$ git branch -adevfeature-1feature-2
* masterremotes/origin/HEAD -> origin/masterremotes/origin/master

这样就删除了那些远程仓库不存在的分支，而对于本地仓库的分支删除之前已经说过了，就不提了（git branch -d 分支）

二、企业级开发模型

1. 背景

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段:规划、编码、构建、测试、发布、部署和维护。

最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。但随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升，一个人已经hold不住了，就开始出现了精细化分工

如下图所示：

但在传统的 IT组织下，开发团队(Dev)和运维团队(0ps)之间诉求不同：

开发团队(尤其是敏捷团队)追求变化。
运维团队追求稳定

双方往往存在利益的冲突。比如，精益和敏捷的团队把持续交付作为目标，而运维团队则为了线上的稳定而强调变更控制。部门墙由此建立起来,这当然不利于IT 价值的最大化。

为了弥合开发和运维之间的鸿沟，需要在文化、工具和实践方面的系列变革 – DevOps 正式登上舞台。

DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。
透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。在DevOps的软件开发过程包含计划、编码、构建、测试、预发布、发布、运维、监控，由此可见DevOps的强大。

讲了这么多，这个故事到底和我们课程的主题 Git 有什么关系呢?举一个很简单的例子就能说明这个问题。一个软件的迭代，在我们开发人员看来，说白了就是对代码进行迭代，那么就需要对代码进行管理。如何管理我们的代码呢，那不就是 Git(分布式版本控制系统)!所以 Git 对于我们开发人员来说其重要性就不言而喻了。

2. 系统开发环境

言归正传，对于开发人员来说，在系统开发过程中最常用的几个环境必须要了解一下：

开发环境：开发环境是程序猿们专门用于日常开发的服务器。为了开发调试方便，一般打开全部错误报告和测试工具，是最基础的环境。
测试环境：一个程序在测试环境工作不正常，那么肯定不能把它发布到生产机上。该环境是开发环境到生产环境的过渡环境。
预发布环境：该环境是为避免因测试环境和线上环境的差异等带来的缺陷漏测而设立的一套环境。吃其配置等基本和生产环境一致，目的是能让我们发正式环境时更有把握！所以预发布环境是你的产品质量最后一道防线，因为下一步你的项目就要上线了。要注意预发布环境服务器不在线上集成服务器范围之内，为单独的一些机器。
生产环境：是指正式提供对外服务的线上环境，例如我们目前在移动端或PC端能访问到的APP都是
生产环境。

这几个环境也可以说是系统开发的三个重要阶段:开发->测试->上线。一张图总结：

对于规模稍微大点的公司来说，可不止这么几个环境，比如项目正式上线前还存在仿真/灰度环境，再比如还存在多套测试环境，以满足不同版本上线前测试的需要。

一个项目的开始从设计开始，而一个项目的成功则从测试开始。一套良好的测试体系可以将系统中绝大部分的致命Bug解决在系统上线之前。测试系统的完善和成熟也是衡量一个软件企业整体水平的重要指标之一，测试往往被忽视，因为它对可以的隐性、对软件开发企业不产生直接的效益，但是它却是软件质量的最终保障，乃至项目能否成功的重要因素!

3. Git 分支设计规范

环境有了概念后，那么对于开发人员来说，一般会针对不同的环境来设计分支，例如:

分支	名称	适用环境
master	主分支	生产环境
release	预发布分支	预发布/测试环境
develop	开发分支	开发环境
feature	需求开发分支	本地
hotfix	紧急修复分支	本地

① master分支

master 为主分支，该分支为只读且唯一分支。用于部署到正式发布环境，一般由合并 release 分支得到。
主分支作为稳定的唯一代码库,任何情况下不允许直接在 master 分支上修改代码。
产品的功能全部实现后，最终在master分支对外发布，另外所有在master分支的推送应该打标签(tag)做记录，方便追溯。
master 分支不可删除。

② release 分支

release 为预发布分支，基于本次上线所有的 feature 分支合并到 develop 分支之后，基于 develop 分支创建。可以部署到测试或预发布集群。
命名以 release/开头，建议的命名规则：release/version_publishtime
release 分支主要用于提交给测试人员进行功能测试。发布提测阶段，会以 release 分支代码为基准进行提测。
如果在 release 分支测试出问题，需要回归验证 develop 分支看否存在此问题。
release 分支属于临时分支，产品上线后可选删除。

③ develop 分支

develop 为开发分支，基于 master 分支创建的只读且唯一分支，始终保持最新完成以及bug修复后的代码。可部署到开发环境对应集群。
可根据需求大小程度确定是由 feature 分支合并，还是直接在上面开发(非常不建议)

⑤ feature 分支

feature 分支通常为新功能或新特性开发分支，以 develop 分支为基础创建 feature 分支
命名以 feature/ 开头，建议的命名规则：feature/user_createtime_feature
新特性或新功能开发完成后，开发人员需合到 develop 分支。
一旦该需求发布上线，便将其删除。

⑥ hotfix 分支

hotfix 分支为线上 bug 修复分支或叫补丁分支，主要用于对线上的版本进行 bug修复。当线上
出现紧急问题需要马上修复时，需要基于 master 分支创建 hotfix 分支。
命名以 hotfix/ 开头，建议的命名规则：hotfix/user_createtime_hotfix
当问题修复完成后，需要合并到 master 分支和 develop 分支并推送远程。一旦修复上线，便

其实，以上跟大家讲解的是企业级常用的一种 Git 分支设计规范：Git Flow 模型。

但要说的是，该模型并不是适用于所有的团队、所有的环境和所有的文化。如果你采用了持续交付，你会想要一些能够尽可能简化交付过程的东西。有些人喜欢基于主干的开发模式，喜欢使用特性标志。然而，从测试的角度来看，这些反而会把他吓一跳。

关键在于站在你的团队或项目的角度思考：这种分支模型可以帮助你们解决哪些问题？它会带来哪些问题？这种模式为哪种开发提供更好的支持？你们想要鼓励这种行为吗？你选择的分支模型最终都是

为了让人们更容易地进行软件协作开发。因此，分支模型需要考虑到使用者的需求，而不是盲目听信某些所谓的“成功的分支模型”

所以对于不同公司，规范是会有些许差异，但万变不离其宗，是为了效率与稳定。

三、企业级管理实战

1. 具体流程

1.1 DevOps 研发平台

Gitee 企业版免费版

这里企业名称可随意填写一个测试名称，只要能通过即可
注意：多人协作开发，需要将多人账号拉入一个企业下才行

1.2 创建项目

1.3 创建仓库

注意：创建的仓库可以关联到某个项目中被管理起来

1.4 添加成员

① 添加企业成员

注意：申请后需要负责人进行审批才可以通过

② 添加项目成员

③ 添加仓库开发人员

1.5 添加仓库开发人员

2. 开发场景 – 基于 git flow 模型的实践

现有⼀个订单管理的新需求需要开发，首先可以基于 develop分支创建⼀个 feature/hyb_order_20250412 分支

① 需求在 feature/hyb_order_20250412 分支开发完毕，这时研发人员可以将代码合并到 develop 分支，将其部署在开发环境的服务器中，方便开发人员进行测试和调试。

a. 开发者在 feature 分支下发起a请求评审

b. 审查员审查代码

c. 审查通过，合并分支

d. 合并成功，查看结果

② 在 develop 下开发人员自测通过后，先确定下 develop 不存在未测试完毕的需求，然后研发人员可基于 develop 分支创建一个 release/xxx 分支出来，可交由测试人员进行测试。

③ 测试人员测试 release 通过后(包含测试环境和预发布环境的测试)，就可将代码合并入 master

④ 测试人员在 master(正式环境) 测试通过后，便可删除 feature/xxx 分支

3. bug 修复

修复测试环境 Bug
- 在 develop 测试出现了Bug，建议大家直接在 feature 分支上进行修复。
  修复后的提测上线流程与新需求加入的流程一致。
修改预发布环境 Bug
- 在 release 测试出现了 Bug，首先要回归下 develop 分支是否同样存在这个问题。
- 如果存在，修复流程与修复测试环境 Bug流程一致。
- 如果不存在，这种可能性比较少，大部分是数据兼容问题，环境配置问题等。
修改正式环境 Bug
1. 在 master 测试出现了Bug，首先要回归下 release 和 develop 分支是否同样存在这个问题
2. 如果存在，修复流程与修复测试环境 Bug流程一致
3. 如果不存在，这种可能性也比较少，大部分是数据兼容问题，环境配置问题等
紧急修复正式环境 Bug
- 需求在测试环节未测试出 Bug，上线运行一段时候后出现了 Bug，需要紧急修复的
- 有的企业面对紧急修复时，支持不进行测试环境的验证，但还是建议验证下预发布环境
- 可基于 master 创建 hotfix/xxx 分支，修复完毕后发布到 master验证，验证完毕后，master 代码合并到 develop 分支，同时删掉 hotfix/xxx 分支。