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

Git : 多人协作和企业级开发模型

news 2025/9/18 8:19:11

Git : 多人协作和企业级开发模型

一、多人协作
- 多人协作一：不同开发者在dev分支开发
- - 1. 前期准备
  - 2. 分支管理
  - 3. 在 dev 分支上开发
  - 4. 协作模式总结
  - 5. 功能开发完成后合并
  - 6. 总结
- 多人协作二：不同开发者在不同分支开发
- - 1. 多人协作的基本方式
  - 2. 你创建并推送分支
  - 3. 小伙伴创建自己的分支
  - 4. 帮小伙伴继续开发
  - 5. 小伙伴继续开发
  - 6. 合并到 `master`
  - 7. 删除无用分支
  - 远程分支删除后本地依然能看到的解决办法
  - - 1. 问题场景
    - 2. 查看远程状态
    - 3. 清理本地无效的远程分支
  - 🎯 总结
二、企业级开发模型
- 1. 从“一人包揽”到“精细分工”
- 2. DevOps 的登场
- 3. 系统开发常见环境
- 4. Git 分支与环境的对应

一、多人协作

多人协作一：不同开发者在dev分支开发

条件：在同一分支下协作完成

1. 前期准备

目前我们已完成以下工作：

掌握 Git 本地库的操作（分支、版本回退、冲突解决等）。
申请了 Gitee 账号，可以完成 clone、push、pull 操作。

接下来要进行多人协作开发。

模拟多人环境

在 Linux 下 clone 项目：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git_practice]$ pwd
/home/xrw/git_practice

在 Windows 下再次 clone 同一个项目，模拟另一位协作者。

⚠️ 注意：
实际开发中，每个开发者都有自己的 Gitee/GitHub 账号。若要协作开发，必须由仓库管理员邀请用户加入项目，才有权限提交代码。

2. 分支管理

仓库初始只有 master 主分支。
不能直接在 master 上开发，避免破坏主分支稳定性。
在远端创建一个 dev 分支，供开发使用。

拉取远程分支

# 拉取远程仓库信息
git pull# 查看远程分支
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch -rorigin/HEAD -> origin/masterorigin/devorigin/master# 本地创建 dev 分支并追踪远程 dev
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout -b dev origin/dev
Branch dev set up to track remote branch dev from origin.
Switched to a new branch 'dev'[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch -vv
* dev    c8d2e57 [origin/dev] update file.txt.master c8d2e57 [origin/master] update file.txt.

这样就能在本地 dev 分支上进行开发

3. 在 dev 分支上开发

开发者 A 的操作

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ cat file.txt
xxxxxxx
bbbbbbbbb
hello by linux
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git add .
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git commit -m "add by linux"
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$git push origin dev

推送成功后，远端仓库 dev 分支更新。

开发者 B 的操作

PS D:\git\git-practice> cat .\file.txt
xxxxxxx
bbbbbbbbb
world by windowsPS D:\git\git-practice> git add .
PS D:\git\git-practice> git commit -m "add by windows"
[dev 1055ffb] add by windows1 file changed, 1 insertion(+)
PS D:\git\git-practice> git push
info: detecting host provider for 'https://gitee.com/'...
info: detecting host provider for 'https://gitee.com/'...
info: detecting host provider for 'https://gitee.com/'...
To https://gitee.com/rxrw/git-practice.git! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'https://gitee.com/rxrw/git-practice.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

如果也在 dev 开发，推送时可能失败（因为有新提交）。
Git 提示先 pull → 合并 → 解决冲突 → 再 push。

示例：

PS D:\git\git-practice> git pull origin dev
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), 251 bytes | 14.00 KiB/s, done.
From https://gitee.com/rxrw/git-practice* branch            dev        -> FETCH_HEAD80c02b4..85f1d9c  dev        -> origin/dev
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.# 冲突
PS D:\git\git-practice> cat .\file.txt
xxxxxxx
bbbbbbbbb
<<<<<<< HEAD
world by windows
=======
hello by linux
>>>>>>> 85f1d9cef63f372b95de386dd6879292ce5ef0fd# 解决冲突
PS D:\git\git-practice> git add .
PS D:\git\git-practice> git commit -m "fix conflict"
[dev 45d814f] fix conflict
PS D:\git\git-practice> git push
info: detecting host provider for 'https://gitee.com/'...
info: detecting host provider for 'https://gitee.com/'...
info: detecting host provider for 'https://gitee.com/'...
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 16 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 548 bytes | 548.00 KiB/s, done.
Total 6 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [1.1.5]
remote: Set trace flag 1f45faaa
To https://gitee.com/rxrw/git-practice.git85f1d9c..45d814f  dev -> dev

4. 协作模式总结

多人协作时，一般遵循以下流程：

本地开发后，尝试推送：

git push origin branch-name

如果失败（远端有新提交）：

先执行：

git pull

本地合并并解决冲突。

再次推送：

git push origin branch-name

这样即可多人在同一分支下协作。

5. 功能开发完成后合并

合并流程

切换到 master，更新本地：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout master
Switched to branch 'master'
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git pull

切回 dev，合并 master（避免在 master 上解决冲突）：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout dev
Switched to branch 'dev'
Your branch is behind 'origin/dev' by 2 commits, and can be fast-forwarded.(use "git pull" to update your local branch)[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git pull
Updating 85f1d9c..45d814f
Fast-forwardfile.txt | 2 +-1 file changed, 1 insertion(+), 1 deletion(-)[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git merge master
Already up-to-date.

再切回 master，合并 dev：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout master
Switched to branch 'master'
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git merge dev
Updating c8d2e57..85f1d9c
Fast-forwardfile.txt | 4 +++-1 file changed, 3 insertions(+), 1 deletion(-)

推送最新的 master：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git push

在这里插入图片描述

删除开发分支

当 dev 完成任务后，可以在远程仓库删除 dev 分支。

6. 总结

多人协作的核心流程：

开发阶段：在 dev 分支上 pull → 开发 → commit → push。
冲突解决：如果 push 失败 → pull → 合并 → 解决冲突 → 再 push。
上线阶段：将 dev 合并到 master，再删除 dev 分支。

多人协作二：不同开发者在不同分支开发

1. 多人协作的基本方式

在多人协作中，不会在同一个分支上多人同时开发。
一般规则：

一个需求 / 一个功能点 = 一个 feature 分支
多人可以在不同分支上开发，互不影响

2. 你创建并推送分支

创建本地分支并切换

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch
# dev
# * master
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout -b feature-1
Switched to a new branch 'feature-1'

新增功能文件

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ vim function1
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ cat feature-1.txt 
abcdefd
Done!!

提交并推送远端

git add function1
git commit -m "add function1"
git push origin feature-1

推送成功后，远端会提示可以创建 PR。

3. 小伙伴创建自己的分支

你看不见小伙伴的文件，他也看不见你的文件。

PS D:\git\git-practice> git branch
* devmaster
PS D:\git\git-practice> git checkout -b feature-2
Switched to a new branch 'feature-2'
PS D:\git\git-practice> cat feature-2.txt
codeing by windows
PS D:\git\git-practice> git add .
PS D:\git\git-practice> git commit -m "add function2"
[feature-2 c04d41f] add function21 file changed, 1 insertion(+)create mode 100644 feature-2.txt
PS D:\git\git-practice> git push origin feature-2

推送各自的分支时没有冲突，互不影响。

4. 帮小伙伴继续开发

由于某种原因，function2的开发需要你接手

拉取远端仓库内容

git pull

查看远端分支

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch -adevfeature-1
* masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master

切换并关联远端分支

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ 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'

查看并继续开发

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ ls
feature-2.txt  file.txt  README.en.md  README.md[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ vim function2
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ cat feature-2.txt 
codeing by windows
codeing by linux
Done!

提交并推送

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git add function2
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git commit -m "modify function2"
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git push origin feature-2

5. 小伙伴继续开发

小伙伴需要先设置 feature-2 与远程分支的关联，然后才能 pull 到你帮忙开发的内容。

PS D:\git\git-practice> git pull
Updating c04d41f..ed562f5
Fast-forwardfeature-2.txt | 2 ++1 file changed, 2 insertions(+)
PS D:\git\git-practice> cat .\feature-2.txt
codeing by windows
codeing by linux
Done!

本地与远程保持一致后，就可以继续协作开发。

6. 合并到 `master`

小伙伴率先完成，合并到 master

#1.将切换回master,pull一下，保证本地master时最新更新
PS D:\git\git-practice>  git checkout master
PS D:\git\git-practice> git pull#2.切换回feature-2分支，合并master分支,检查是否存在冲突  
PS D:\git\git-practice> git checkout feature-2
PS D:\git\git-practice> git merge master
PS D:\git\git-practice> git push# 3. 切换回master分支, 合并feature-2分支
PS D:\git\git-practice> git checkout master
PS D:\git\git-practice> git merge feature-2#4. 将master分支推送至远端
PS D:\git\git-practice> git push

你完成开发后，先合并 master 到自己分支

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout master
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git pull[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout feature-1
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git merge master
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git push origin feature-1

最后合并回 master

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git checkout master
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git merge feature-1
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git push

这里我们是将更新完后的功能从本地master推送到远程仓库master分支中,其实我们可以将更新完的功能推送到 feature-1和feature-2分支（此时两个分支都合并了master确保没有冲突）后，在git中向远程仓库管理者发起合并请求，这样会更加安全稳妥！！

7. 删除无用分支

当 feature-1 和 feature-2 的任务完成后，可以在git中删除远程分支，保持仓库整洁。

在这里插入图片描述

远程分支删除后本地依然能看到的解决办法

1. 问题场景

在远程仓库中删除了某些分支。
本地执行 git branch -a 仍然能看到这些已删除的远程分支。

示例：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch -adevfeature-1feature-2
* masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/feature-1remotes/origin/feature-2remotes/origin/master

其中 remotes/origin/dev、remotes/origin/feature-1、remotes/origin/feature-2 已经在远程删除，但本地仍显示。

2. 查看远程状态

使用以下命令可以看到远程分支的实际情况：

git remote show origin

输出（部分）：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git remote show origin
* remote originFetch URL: https://gitee.com/rxrw/git-practice.gitPush  URL: https://gitee.com/rxrw/git-practice.gitHEAD branch: masterRemote branches:dev                           trackedmaster                        trackedrefs/remotes/origin/feature-1 stale (use 'git remote prune' to remove)refs/remotes/origin/feature-2 stale (use 'git remote prune' to remove)

stale 表示本地缓存的远程分支已经在远程仓库中不存在。

3. 清理本地无效的远程分支

执行：

git remote prune origin

示例输出：

[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git remote prune origin
Pruning origin
URL: https://gitee.com/rxrw/git-practice.git* [pruned] origin/feature-1* [pruned] origin/feature-2# 再次查看分支可以看到已经清除干净
[xrw@iZ7xv0vjzfc2mzsasssfooZ git-practice]$ git branch -adevfeature-1feature-2
* masterremotes/origin/HEAD -> origin/masterremotes/origin/devremotes/origin/master

远程已删除的分支被清理干净 ✅
本地的普通分支（dev、feature-1、feature-2）如果不需要，可以用 git branch -d 分支名自行删除。

🎯 总结

多人协作的模式：

每个需求单独建 feature 分支开发。
各自开发、互不干扰。
必要时切换到别人的分支协助开发。
开发完成后合并回 master。
清理无用分支。

二、企业级开发模型

1. 从“一人包揽”到“精细分工”

早期的软件很简单：一个程序员就能完成规划 → 编码 → 构建 → 测试 → 发布 → 部署 → 维护。
随着软件规模增大、复杂度提高，一个人 Hold 不住，于是出现了专业分工。

但问题来了：

开发团队（Dev）：追求快速变化（尤其是敏捷开发）。
运维团队（Ops）：追求系统稳定。
结果：一堵“部门墙” 出现 → 开发想上线快，运维怕出事。

2. DevOps 的登场

为了解决这个矛盾，DevOps 出现了：

DevOps = Development + Operations
强调 开发与运维的协作。
借助 自动化的工具链 实现：构建 → 测试 → 发布 → 部署 → 监控全流程快速、频繁、可靠。

DevOps 流程：
计划 → 编码 → 构建 → 测试 → 预发布 → 发布 → 运维 → 监控

3. 系统开发常见环境

一个软件上线前会经过多个环境，每个环境作用不同：

开发环境（Dev）
- 开发人员日常写代码的地方。
- 打开全部错误报告，便于调试。
测试环境（Test）
- 代码写完先放到测试环境验证。
- 如果测试不通过，绝不能发布到线上。
预发布环境（Pre-release/Staging）
- 配置与生产环境几乎一致。
- 是上线前的“最后一道防线”。
生产环境（Prod）
- 正式对外服务的环境。
- 稳定性要求最高。

有些大公司还会额外引入：

仿真/灰度环境（部分用户先用新版本）。
多套测试环境（满足不同版本的测试需要）。

在这里插入图片描述

4. Git 分支与环境的对应

为了配合不同环境，Git 分支通常这样设计：

分支名	适用环境	说明
master	生产环境	主分支，唯一且稳定，只能从 release 合并而来。
release	预发布/测试环境	预发布分支，测试人员提测用。上线后可删除。
develop	开发环境	开发主干，所有新功能合并到这里。
feature	本地/需求开发	新功能分支，完成后合并到 develop，上线后删除。
hotfix	本地/紧急修复	基于 master 创建，用于线上 Bug 修复，修复后合并回 master 和 develop。

master分支
- 生产唯一分支，不能直接改代码。
- 版本发布时必须打 tag（方便回溯）。
- 不可删除。
release 分支
- 从 develop创建 ，用于测试和预发布。
- 命名规则：release/version_publishtime。
- 上线后可删除。
develop 分支
- 基于 master 创建，是开发主干。
- 保持最新、可用的代码。
- 新功能通过 feature 分支合并，不建议直接开发。
feature 分支
- 用于开发新功能。
- 从 develop 创建，完成后合并回 develop。
- 命名规则：feature/user_createtime_feature。
- 上线后删除。
hotfix 分支
用于紧急修复线上 Bug。
从 master 创建，修复完成后需合并到 master 和 develop。
命名规则：hotfix/user_createtime_hotfix。
修复上线后删除。