【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 分支。