Git 版本控制（下）

完成 Git 本地仓库、分支、冲突、stash、.gitignore 基础操作后，单人本地开发场景已经可以完全覆盖。但真实企业开发、开源项目协作都会涉及远程云端仓库、多人并行开发、版本上线管理。 本文重点解决四大企业开发痛点：

1. 本地代码如何和 Gitee/GitHub/GitLab 远程仓库互通；
2. merge 合并历史杂乱，rebase 变基实现干净线性提交日志；
3. 大厂通用 GitFlow 分支规范，区分线上 / 测试 / 开发 / 功能分支；
4. 多人协作、开源项目 Fork、PR 代码评审完整流程；
5. 生产环境版本 Tag 打标、版本回滚、版本管理。

一、远程仓库全套命令（clone/remote/pull/push）

1.1 远程仓库核心概念

远程仓库（Remote）即云端仓库，常见平台：GitHub、Gitee、GitLab，用于团队代码共享、代码备份、多设备同步。 本地仓库和远程仓库是双向镜像关系，和文档中分布式架构对应：本地拥有完整仓库快照，远程仅作为同步中转站。
分布式远程仓库架构图

1.2 克隆远程仓库 git clone

从云端完整拉取仓库（包含所有代码 + 全部历史提交记录），自动生成本地同名仓库，默认绑定远程别名origin。

基础命令

# https方式克隆（无需提前配置ssh密钥，输入账号密码即可）
git clone https://gitee.com/xxx/demo-project.git
ssh方式克隆（配置ssh密钥后免密推送拉取，企业开发推荐）
git clone git@gitee.com:xxx/demo-project.git
指定本地仓库文件夹名称
git clone https://gitee.com/xxx/demo-project.git my-test-project

执行后自动完成三件事：

1. 创建本地项目文件夹；
2. 初始化.git 本地版本库；
3. 自动绑定远程仓库，远程默认名称origin。

1.3 远程仓库管理 git remote

git remote用于查看、新增、修改、删除本地绑定的远程仓库地址。

# 查看已绑定的远程仓库别名（默认origin）
git remote
查看远程仓库详细地址（推荐）
git remote -v
手动新增远程仓库（本地已有仓库，未clone场景使用）
git remote add origin https://gitee.com/xxx/demo-project.git
修改已有远程仓库地址（仓库迁移/更换域名）
git remote set-url origin https://gitee.com/new/demo-project.git
删除绑定的远程仓库
git remote remove origin

1.4 拉取远程代码 git pull

多人开发时，远程仓库会有其他同事提交的新代码，git pull = git fetch + git merge：先拉取远程所有更新，自动合并到本地当前分支。

# 拉取origin远程main/master分支最新代码
git pull origin master
简化写法，默认拉取当前分支绑定的远程分支
git pull

踩坑提醒：

1. 本地存在未提交修改时，直接 pull 可能触发合并冲突，建议先git stash暂存代码；
2. 远程分支与本地分支提交历史分叉时，会产生 merge 合并节点，日志变杂乱（下文 rebase 解决）。

1.5 推送本地代码 git push

将本地新提交同步上传至远程仓库，团队其他成员拉取后可见你的修改。

# 首次推送本地分支到远程，建立分支关联（必须加-u参数）
git push -u origin master
已建立关联后，简化推送
git push
强制推送（高危！覆盖远程代码，仅单人私有仓库谨慎使用，团队禁止）
git push -f origin master

禁止场景 ：多人共用分支时使用git push -f，会直接覆盖同事提交的代码，造成代码丢失。

1.6 补充：git fetch（仅拉取不合并）

和 pull 区别：fetch 只下载远程所有更新到本地远程镜像，不会自动合并，适合先查看远程变更再手动处理：

# 拉取远程所有分支更新
git fetch origin
对比本地分支和远程分支差异
git diff origin/master
手动合并远程代码
git merge origin/master

二、高级分支操作：git rebase 变基（线性干净提交日志）

2.1 merge 与 rebase 核心区别

前文基础章节讲解git merge分支合并，Fast-Forward 无冲突时直接移动指针；存在分叉时会新增一条合并提交记录，多次合并后提交日志杂乱、分叉繁多，不利于代码追溯。
标题merge分支分叉示意图标题

rebase变基：将当前分支所有提交，移植到目标分支最新提交节点之后，生成一条无分叉、纯线性的提交历史，企业代码规范优先推荐。

2.2 rebase 标准实操流程

场景：基于 master 创建 feature 功能分支开发，master 分支同时有同事提交更新，使用 rebase 整理日志。

# 1. 切换到功能分支
git checkout feature/user-login
2. 拉取master最新代码
git fetch origin master
3. 变基：将feature分支所有提交移植到master最新节点
git rebase origin/master

rebase 冲突解决

1. 变基过程中若出现文件冲突，不会终止整个操作：

2. 打开冲突文件，删除<<<<<<< HEAD、=======、>>>>>>>标记，保留最终代码；

3. 保存文件，执行git add .暂存冲突修复；

继续执行变基流程：

git rebase --continue

中途想放弃本次变基，回退操作：

git rebase --abort

2.3 rebase 风险红线（必看）

1. 公共共享分支禁止执行 rebase（如 master、dev）；
2. 已经 push 到远程的提交，不要变基，变基后本地提交哈希值改变，再次 push 需要强制推送，会破坏团队代码历史；
3. 仅在本地未推送的私有分支使用 rebase 整理提交日志。

2.4 交互式变基：合并多次提交（git rebase -i）

开发中频繁小提交（修复空格、注释修改），推送到远程前可合并为一条规范提交：

# 合并最近3次提交
git rebase -i HEAD~3

打开编辑面板，将需要合并的提交前缀pick改为squash，保存后合并多条提交，统一填写提交注释。

三、企业标准化分支：GitFlow 完整开发流程

3.1 GitFlow 五大核心分支定义

解决多人并行开发、线上版本、bug 修复、新功能并行开发混乱问题，大厂通用规范：

分支名称	作用	生命周期
main/master	生产线上稳定代码，随时可部署上线	永久存在
develop	开发主分支，整合所有新功能，测试通过后合并至 main	永久存在
feature/*	新需求 / 新功能开发分支，从 develop 拉出	短期，功能完成即删除
release/*	版本预发布分支，测试、修复小 bug，不新增功能	短期，上线后删除
hotfix/*	线上紧急 bug 修复分支，从 main 拉出，修复后同步合并 main+develop	短期，修复上线即删除

3.2 GitFlow 完整开发流程

1. 新功能开发

# 1. 切换到开发分支，拉取最新代码
git checkout develop
git pull origin develop
# 2. 创建功能分支
git checkout -b feature/order-pay
# 3. 开发完成，提交代码、rebase整理日志
git add .
git commit -m "完成订单支付功能"
git rebase develop
# 4. 合并至develop分支，删除功能分支
git checkout develop
git merge feature/order-pay
git push origin develop
git branch -D feature/order-pay

版本发布流程

从 develop 拉出 release 分支，测试人员在 release 分支修改 bug，测试通过后合并 main 与 develop，打版本 tag。

线上紧急 bug 修复 hotfix

# 从线上main分支拉出修复分支
git checkout main
git pull origin main
git checkout -b hotfix/login-error
# 修复bug并提交
git commit -m "修复登录验证码失效线上bug"
# 分别合并到main和develop
git checkout main
git merge hotfix/login-error
git push origin main
# 同步合并开发分支，避免开发环境复现bug
git checkout develop
git merge hotfix/login-error
git push origin develop
# 打线上版本标签，删除hotfix分支
git tag -a v1.0.1 -m "线上修复版本v1.0.1"
git push origin v1.0.1
git branch -D hotfix/login-error

四、多人开源 / 团队协作：Fork 仓库 + Pull Request 代码评审

4.1 Fork 适用场景

1. 开源项目：无仓库直接推送权限，通过 Fork 复制仓库到个人账号，开发后提交 PR 合并至原仓库；
2. 大型团队：代码统一评审，禁止直接 push 主分支，所有修改走 PR 流程，leader 审核通过后合并。

4.2 完整 Fork+PR 实操步骤

打开开源项目远程仓库页面，点击Fork，将仓库复制到个人账号；

克隆个人 Fork 后的仓库到本地：

git clone https://gitee.com/你的账号/demo-project.git

绑定原上游仓库（同步原仓库最新代码）：

git remote add upstream https://gitee.com/原作者/demo-project.git
# 拉取原仓库更新
git fetch upstream

1. 创建功能分支开发、提交代码、推送到个人远程仓库；
2. 个人仓库页面点击Pull Request，选择目标合并分支（develop/main）；
3. 填写 PR 说明：修改内容、测试步骤、关联需求 / 缺陷编号；
4. 项目维护者代码评审：提出修改意见，开发者本地修改后推送更新至 PR；
5. 评审通过，维护者点击合并，PR 流程完成。

4.3 PR 常见问题处理

1. PR 存在冲突：本地拉取上游代码 rebase 解决冲突，重新推送；
2. 评审需要修改代码：本地在原分支追加提交，自动同步到 PR；
3. 废弃 PR：关闭 PR，删除本地临时分支。

五、版本标签 Tag 管理（线上正式版本标记）

Tag 用于标记稳定上线版本，不可修改，永久记录每一次生产发布快照，区分 v1.0.0、v1.0.1 迭代版本。

5.1 创建轻量标签 / 附注标签

# 1. 附注标签（推荐，携带版本说明，线上版本统一使用）
git tag -a v1.0.0 -m "正式上线版本v1.0.0，包含用户、订单基础功能"
2. 轻量标签（仅标记提交节点，无备注，测试临时使用）
git tag v1.0.0
给历史提交打标签（回退后补打版本）
git tag -a v0.9.0 提交哈希值

5.2 标签查看、推送、删除

# 查看本地所有版本标签
git tag
推送单个标签到远程
git push origin v1.0.0
一次性推送所有本地标签
git push origin --tags
删除本地标签
git tag -d v1.0.0
删除远程仓库标签
git push origin --delete v1.0.0

5.3 根据 Tag 版本回滚线上代码

线上新版本存在重大问题，快速回退至历史稳定 Tag 版本：

# 切换到指定tag快照
git checkout v1.0.0
# 基于tag创建修复分支重新发布
git checkout -b rollback-v1.0.0

六、进阶知识点总结速记

1. 远程仓库核心命令 clone 克隆、remote 管理远程地址、fetch 仅拉取、pull 拉取合并、push 推送，首次推送加-u绑定分支；禁止多人分支强推-f。
2. rebase 变基 生成线性干净提交日志，仅本地未推送分支使用；公共分支、已推送提交严禁 rebase；冲突使用--continue继续、--abort放弃。
3. GitFlow 分支规范 main 线上稳定、develop 开发主分支；feature 做功能、release 预发布、hotfix 线上紧急修复，各分支生命周期明确，解决团队并行开发混乱。
4. Fork+PR 协作 无仓库推送权限时使用，上游仓库同步更新，代码强制评审，企业 / 开源项目标准协作流程。
5. Tag 版本标签 标记线上发布版本，附注标签带说明，支持推送远程、历史提交打标，用于版本回滚、迭代追溯。