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

Git 多人协作实战：从基础操作到分支管理全流程记录

news 2025/7/18 5:25:59

在团队开发中，Git 作为分布式版本控制系统，其核心价值在于高效支持多人协作与分支管理。本文将通过两个本地仓库（模拟两个开发者）与远程仓库（Gitee）的交互案例，详细记录从初始化仓库、文件提交、冲突处理到分支管理的完整流程，并结合 Git 分支管理策略，解析实战中的关键操作与问题解决方法。

一、环境与场景说明

本次实战模拟两个开发者（yby和鲁智深）协作开发，共享远程仓库https://gitee.com/yby6666/ittest717.git：

本地仓库 1（gitTest01）：开发者yby操作，主要进行文件创建、更新及分支管理。
本地仓库 2（gitTest02）：开发者鲁智深操作，模拟并行开发与冲突场景。
远程仓库：Gitee 上的ittest717.git，作为代码共享中心。

二、基础操作：从初始化到首次推送

2.1 初始化仓库与首次提交

开发者yby的操作：
首先在本地创建仓库并初始化，完成第一个文件的提交：

# 初始化本地仓库
git init# 创建并编辑文件a.txt
vi a.txt# 将文件加入暂存区
git add .
# 提交到本地仓库（提示LF将被替换为CRLF，Windows系统换行符适配）
git commit -m "a.txt commit"

此时通过git status可查看工作区状态为 “clean”，表示提交成功。

2.2 关联远程仓库

本地仓库需与远程仓库关联才能实现代码同步，通过git remote add命令绑定远程仓库地址：

# 关联远程仓库，命名为origin（Git默认远程仓库名）
git remote add origin https://gitee.com/yby6666/ittest717.git# 查看配置确认关联成功
cat .git/config

配置文件中会显示远程仓库的 URL 及拉取规则，确认[remote "origin"]配置正确。

2.3 首次推送冲突：远程与本地历史不一致

首次推送本地master分支到远程时，遇到报错：

git push -u origin master
# 报错：! [rejected] master -> master (fetch first)
# 提示远程有本地未包含的提交

进一步拉取远程更新时，出现 “不相关历史” 错误：

git pull origin master
# 报错：fatal: refusing to merge unrelated histories

原因：本地仓库与远程仓库无共同提交历史（远程可能已存在初始化文件，如README.md），Git 默认拒绝合并 “不相关” 历史。

解决方法：使用git pull --rebase强制将本地提交基于远程历史重放，合并历史：

git pull --rebase origin master
# 输出：Successfully rebased and updated refs/heads/master.

重新推送即可成功：

git push -u origin master
# 提示：branch 'master' set up to track 'origin/master'

三、多人协作核心场景：冲突与同步

3.1 远程更新拉取：保持本地与远程同步

当远程仓库有新提交（如其他开发者推送了更新），本地需先拉取再推送，避免冲突。

开发者yby拉取远程更新：

git pull
# 拉取到远程新增的c.txt文件，提示Fast-forward（快速合并，无冲突）

git pull本质是git fetch + git merge，若希望保持提交历史线性，可使用git pull --rebase，将本地提交 “嫁接” 到远程最新提交之后。

3.2 文件冲突处理：多人修改同一文件

当两个开发者同时修改同一文件的同一部分时，会产生冲突。以c.txt为例：

开发者鲁智深的操作：
创建并推送c.txt：

# 配置用户信息（区分开发者）
git config --local user.name '鲁智深'
git config --local user.mail 'luzhishen@126.com'# 创建c.txt并提交
vi c.txt
git add .
git commit -m "c.txt commit"
git push  # 推送成功，远程新增c.txt

开发者yby的操作：
本地修改c.txt后推送，发现冲突：

vi c.txt  # 修改内容与鲁智深的修改冲突
git add .
git commit -m "yby c.txt commit"
git push  # 报错：rejected，需先拉取远程更新

解决冲突步骤：

拉取远程更新，触发冲突提示：

git pull origin master
# 提示：CONFLICT (content): Merge conflict in c.txt

编辑冲突文件c.txt，手动保留需要的内容（冲突标记为<<<<<<< HEAD、=======、>>>>>>> [commit-hash]）：
```
vi c.txt  # 保留"ybyupdate"和"luzheshen"的有效内容
```

标记冲突已解决并提交：

git add .  # 标记文件为已解决
git commit -m "yby 2 c.txt commit"  # 提交合并结果
git push  # 推送成功，冲突解决

四、分支管理：并行开发与协作

分支是 Git 协作的核心，通过分支可实现功能隔离、并行开发。以下结合实战案例讲解分支操作。

4.1 创建与推送分支

开发者yby创建dev分支并推送至远程：

# 创建dev分支（基于当前master）
git branch dev# 切换到dev分支
git checkout dev# 推送dev分支到远程（首次推送需关联）
git push --set-upstream origin dev
# 等价于：git push -u origin dev

推送后，远程仓库会新增dev分支，本地dev分支与远程dev分支关联，后续可直接用git push推送。

4.2 拉取远程分支到本地

开发者鲁智深拉取dev分支：
当远程已有dev分支，另一开发者需创建本地对应分支并关联：

# 拉取远程分支信息
git pull# 基于远程dev分支创建本地dev分支并切换
git checkout -b dev origin/dev
# 提示：branch 'dev' set up to track 'origin/dev'

此时本地dev分支与远程同步，可在该分支进行开发。

4.3 分支的删除与清理

当分支完成使命（如功能合并到主分支），需删除本地和远程分支：

删除本地分支：

git branch -d dev2  # 删除已合并的dev2分支

删除远程分支：

git push origin --delete dev2  # 远程dev2分支被删除

清理无效远程分支引用：
远程分支删除后，本地可能仍保留引用，需修剪：
```
git remote prune origin  # 移除本地对已删除远程分支的引用
```

五、分支管理策略实践

结合理论中的分支策略，本次实战中的分支对应关系如下：

master分支：主分支，对应 “stable 分支”，用于版本发布，保持稳定。
dev分支：开发分支，对应 “develop 分支”，用于日常开发，开发者在该分支协作。
临时分支（如dev2）：可对应 “feature 分支”，用于单独功能开发，完成后合并到dev。

通过这种策略，可实现：

功能开发在feature分支，不影响dev和master；
版本发布前，将dev合并到release分支测试，再合并到master；
线上 bug 通过 “bugfix 分支” 修复，基于master创建，修复后合并到master和dev。

六、关键命令与协作要点总结

6.1 核心命令速查表

操作场景	命令示例
初始化仓库	`git init`
提交文件	`git add .` + `git commit -m "msg"`
关联远程仓库	`git remote add origin <url>`
拉取远程更新（合并）	`git pull origin <branch>`
拉取远程更新（变基）	`git pull --rebase origin <branch>`
推送分支	`git push -u origin <branch>`
创建并切换分支	`git checkout -b <branch>`
关联远程分支	`git checkout -b <branch> origin/<branch>`
删除远程分支	`git push origin --delete <branch>`

6.2 协作要点

推送前先拉取：每次推送前用git pull同步远程更新，避免冲突。
合理使用分支：功能开发用 feature 分支，修复 bug 用 bugfix 分支，保持主分支干净。
冲突理性解决：冲突是协作常态，需沟通后保留有效代码，避免盲目覆盖。
历史清晰为主：优先使用git pull --rebase保持提交历史线性，便于追溯。

通过本文案例，可直观理解 Git 多人协作的核心流程与问题解决方法。熟练掌握分支管理与冲突处理，能显著提升团队开发效率。

七、分支管理策略

git 的分支整体预览图如下：

从上图可以看到主要包含下面几个分支：

master：git默认主分支（这里不作操作）。

stable：稳定分支，替代master，主要用来版本发布。

develop：日常开发分支，该分支正常保存了开发的最新代码。

feature：具体的功能开发分支，只与 develop 分支交互。

release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。

bugfix：线上 bug 修复分支。

主分支

因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。

stable分支：用来发布，管理着多个稳定的版本。

develop分支：就是我们日常开发的分支。

使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。

辅助分支

通过这些分支，我们可以做到：团队成员之间并行开发，增加新功能更加容易，可以同时进行开发和版本发布、线上bug修复等。

Feature分支

feature 分支用来开发具体的功能，一般基于develop分支，最后完成功能后再合并到develop分支。

比如，目前我们针对develop分支来做功能开发，在开发的过程中会有紧急需求需要开发，且在本次版本发布时间之前要能测试完成。我们可以基于之前稳定版本另开一个feature分支来做紧急需求的开发，发布并进行测试，完成之后再合并到develop分支上。

release分支

release分支作为预发布分支，release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 stable 分支，合并到 stable分支上就是可以发布的代码了。

为什么我从develop分支fork出来，还要合并到develop分支中呢？因为我们在release分支上难免会有bug产生，修复bug也是在release分支上，所以必须要合并到develop分支。

bugfix分支

bugfix 分支用来修复线上bug。当线上代码出现 bug 时，我们基于 stable 分支开一个bugfix分支，修复 bug之后再将 bugfix分支合并到stable分支并进行发布，同时develop 分支作为最新最全的代码分支，bugfix分支也需要合并到 develop 分支上去。

八、Gitee注册创建仓库

Gitee 作为国内主流的代码托管平台，其注册与仓库创建流程简洁高效。以下是基于最新界面的详细操作指南，结合实战案例解析关键步骤：

一、账号注册与初始化

1. 访问官网并注册

打开浏览器访问 Gitee 官网，点击右上角「注册」按钮1。
选择注册方式：
- 邮箱注册：填写邮箱、密码、验证码，勾选用户协议后提交。
- 第三方登录：支持微信、QQ、GitHub 等账号快速登录。
完成注册后，系统会发送验证邮件至注册邮箱，点击链接激活账号。

2. 完善账号信息（可选）

点击右上角头像，进入「设置」→「个人信息」，补充真实姓名、手机号等信息（部分功能需实名认证）。
建议绑定 SSH 公钥（在「安全设置」中操作），后续推送代码时可免输密码2。

二、创建远程仓库

1. 进入仓库创建页面

登录后点击右上角「+」按钮，选择「新建仓库」2。

2. 配置仓库基础信息

仓库名称：必填项，建议使用英文或数字（如 my-project）。
仓库描述：可选，简要说明项目用途（如「前端项目演示」）。
仓库可见性：
- 公开：所有人可查看，适合开源项目。
- 私有：需授权才能访问，适合企业项目（免费账户限 3 个私有仓库）。
- 内部：仅企业成员可见（需开通企业版）。
初始化仓库（可选）：
- 勾选「使用 README 文件初始化这个仓库」，系统会自动生成项目说明文档。
- 可额外选择开源协议（如 MIT、GPL），明确代码使用权限1。