【学Git看这篇文章就够了】远程仓库 AND 企业协作进阶

作者：逆境不可逃

技术永无止境

希望我的内容可以帮助到你！！！！

大家吼 ! 我是 逆境不可逃 今天给大家带来文章

《【学Git看这篇文章就够了】远程仓库 AND 企业协作进阶 》

可以回顾上一篇文章让大家有个初步认识

【学Git看这篇文章就够了】基础入门之本地单机 Git-CSDN博客

第一部分：远程仓库基础（Gitee 版）

这节课是 Git 从单机工具变成团队协作工具的转折点。我会把每个命令的作用、原理、新手必踩坑都讲透，你跟着一步步做就行。

一、我们要知道：什么是远程仓库？？？

你之前操作的都是本地仓库（存在你自己电脑上）。远程仓库就是存在互联网上的 Git 仓库，作用是：

国内推荐用 Gitee（码云），访问速度比 GitHub 快很多，注册简单。

二、第一步：注册 Gitee 账号 + 新建空远程仓库

创建成功后，你会进入仓库主页，地址大概是：https://gitee.com/你的用户名/git-demo

 新手必看：为什么不能勾选初始化？ 因为你本地已经有一个完整的仓库了，如果远程也初始化了，两个仓库历史不兼容，第一次 push 会报错。等你熟练了再用初始化的方式。

三、第二步：本地仓库关联远程仓库

回到你的终端，确保当前目录是本地的git-demo仓库。

1. 查看当前有没有关联远程仓库

git remote -v

• 如果什么都没输出，说明还没关联任何远程
• 如果有输出，说明之前关联过，先执行 git remote remove origin 删除旧的

2. 关联远程仓库

复制 Gitee 仓库主页上的 HTTPS 地址（就是那个https://gitee.com/xxx/git-demo.git），执行：

git remote add origin https://gitee.com/你的用户名/git-demo.git

• origin：远程仓库的别名（行业默认叫法，不用改）
• add：添加一个远程仓库

3. 验证关联是否成功

再次执行：

git remote -v

会输出两行内容，分别是 fetch（拉取）和 push（推送）的地址，说明关联成功。

四、第三步：第一次推送本地代码到远程

这是最关键的一步，把你本地所有提交记录推送到云端。

git push -u origin master

逐字解释这个命令（新手一定要懂）

• git push：推送命令
• -u：全称–set-upstream，建立本地分支和远程分支的追踪关系
  • 作用：这次执行完后，以后再推送这个分支，只需要写git push，不用再加origin master
• origin：推送到哪个远程仓库（就是刚才关联的那个）
• master：推送本地的 master 分支到远程

第一次推送会要求登录

Windows 会弹出 Gitee 的登录窗口，输入你的 Gitee 账号密码登录即可。 Mac/Linux 会在终端提示输入用户名和密码，输入的时候密码是看不见的，正常输入回车就行。

推送成功后，刷新 Gitee 仓库主页，你会看到本地的所有文件都出现在云端了！

五、反向操作：拉取远程更新到本地

如果远程仓库有了新的改动（比如你在网页上改了文件，或者别人推了代码），需要拉取到本地：

git pull origin master

• 作用：把远程 master 分支的最新代码拉取下来，自动合并到本地 master 分支

实操验证（必做）

git pull origin master

六、另一种常用场景：克隆别人的远程仓库

如果你想把别人的开源项目完整下载到本地，用git clone命令：

git clone 远程仓库地址

• 作用：自动在本地创建一个和远程一模一样的仓库，包括所有提交历史和分支
• 不需要git init，克隆下来直接就是 Git 仓库

七、进阶：SSH 免密登录（强烈建议配置）

每次用 HTTPS 推送都要输账号密码，很麻烦。配置 SSH 密钥后，以后 push/pull 都不用输密码了。

一步一步配置

ssh-keygen -t ed25519 -C "你的Gitee注册邮箱"

• 执行后一路按回车（不要输入任何密码），直到出现密钥指纹
• 密钥会默认生成在用户目录下的.ssh文件夹里

ssh -T git@gitee.com

第一次连接会提示Are you sure you want to continue connecting?，输入yes回车。

如果输出：Hi 你的用户名! You've successfully authenticated, but GITEE.COM does not provide shell access. 说明 SSH 配置成功！

切换远程地址为 SSH（可选但推荐）

之前用的是 HTTPS 地址，现在改成 SSH 地址，以后就不用输密码了：

git remote set-url origin git@gitee.com:你的用户名/git-demo.git

八、常见错误及解决方法

第二部分：远程分支协作（GitHub 版，团队开发核心流程）

核心说明：Git 命令本身100% 跨平台通用，GitHub 和 Gitee 只是代码托管平台不同，界面操作有差异，所有 Git 命令完全一致。本节课我会全程用 GitHub 界面演示，所有操作逻辑可直接迁移到 Gitee。

一、前置准备（先搞定这一步）

1. GitHub 账号注册

打开 https://github.com/ 注册账号（免费版完全够用）。

2. 配置 GitHub SSH 免密登录（和 Gitee 几乎一样）

• 生成本地 SSH 密钥（如果没有）：

  ssh-keygen -t ed25519 -C "你的GitHub邮箱"

  一路回车即可，生成后公钥在 ~/.ssh/id_ed25519.pub

• 把公钥内容添加到 GitHub： GitHub → Settings → SSH and GPG keys → New SSH key，粘贴公钥内容保存。

重要：你之前生成的 SSH 密钥对可以重复使用，不用重新生成！

ssh -T git@github.com

第一次连接输入yes回车，看到输出： Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access. 代表配置成功！

3. 新建 GitHub 测试仓库

如果进行了SSH就不用把git remote set-url origin git@github.com:你的用户名/github-git-demo.git替换第二步

之后直接 git push 就不会再要密码了。

git remote remove origin

git remote add origin https://github.com/你的用户名/git-demo

git push -u origin master

二、核心概念：本地分支 vs 远程分支

• 本地分支：存在你电脑上的分支（git branch看到的）
• 远程分支：存在 GitHub 服务器上的分支（git branch -r看到的）
• 追踪关系：本地分支和远程分支一一对应，这样git push/git pull才知道推给谁、拉谁

举个例子：本地的dev分支对应远程的origin/dev分支，它们是绑定在一起的。

三、远程分支常用操作（逐行讲解）

1. 查看所有分支（本地 + 远程）

# 只看本地分支
git branch

# 只看远程分支
git branch -r

# 看所有分支（本地+远程）
git branch -a

远程分支会显示为红色，格式是origin/分支名。

2. 推送本地分支到远程（最常用）

需求：把本地的dev分支推送到 GitHub，让团队其他人能看到

# 先确保你在本地dev分支
git checkout dev

# 推送到远程并建立追踪关系
git push -u origin dev

• -u：建立本地dev和远程origin/dev的追踪关系
• 执行完后，刷新 GitHub 仓库页面，就能看到dev分支了
• 以后再推这个分支，只需要写git push，不用再加参数

3. 拉取别人的远程分支到本地

需求：同事推了一个feature/login分支到远程，你需要拉下来一起开发

# 先拉取远程所有最新分支信息
git fetch origin

# 创建本地分支并追踪远程分支（两种写法等价）
git checkout -b feature/login origin/feature/login
# 或者新版Git推荐写法
git switch -c feature/login origin/feature/login

✅ 新手必懂：git fetch vs git pull

• git fetch：只拉取远程最新信息到本地，不自动合并，安全
• git pull：拉取 + 自动合并，等于git fetch + git merge，可能产生冲突 建议新手先养成git fetch看一下的习惯，再决定要不要合并。

4. 删除远程分支

需求：feature/login分支已经合并完成，不需要了

# 删除本地分支
git branch -d feature/login

# 删除远程分支
git push origin –delete feature/login

刷新 GitHub 页面，这个分支就消失了。

四、企业级团队协作标准流程（每天都这么做）

这是全世界所有互联网公司通用的 Git 工作流，一定要背下来：

标准开发流程（单人开发一个功能）

• 每天上班第一件事：切回主分支，拉取最新代码

git checkout master
git pull

• 基于最新主分支，创建自己的功能分支

git checkout -b feature/user-registration

• 在功能分支上开发，频繁提交（每完成一个小功能就 commit）

git add .
git commit -m "feat: 实现用户注册表单"

• 开发完成，推送到远程

git push -u origin feature/user-registration

• 在 GitHub 上创建 Pull Request(PR)（核心！）
  • 打开 GitHub 仓库页面 → 点击 Pull requests → 点击 New pull request
  • base 分支选master（要合并到的分支），compare 分支选你的功能分支
  • 填写 PR 标题和描述（说明你做了什么功能）
  • 点击 Create pull request
• 等待同事代码审核，审核通过后，点击 Merge pull request 合并到主分支
• 删除远程和本地的功能分支（可选）

多人协作冲突处理

如果你的 PR 提示 "有冲突无法合并"，按以下步骤处理：

git checkout master
git pull

git checkout feature/user-registration
git merge master

git add .
git commit -m "fix: 解决合并冲突"
git push

五、GitHub PR 完整实操演示

# 关联远程仓库（复制你GitHub仓库的SSH地址）
git remote add origin git@github.com:你的用户名/github-git-demo.git

# 推送master分支
git push -u origin master

git checkout -b feature/add-readme

# 新建README.md文件，写点内容
echo "# GitHub Git Demo" > README.md

# 提交
git add README.md
git commit -m "feat: 添加README文件"

# 推送到远程
git push -u origin feature/add-readme

git checkout master
git pull

现在本地 master 分支就有了 README 文件，本地功能分支可以删除了：

git branch -d feature/add-readme

六、常见错误及解决

第三部分：git stash 临时代码暂存 + tag 版本标签（开发必备工具）

这两个命令是 Git 里最实用的 "小工具"，几乎每天都会用到。

git stash解决 "开发一半被迫切分支" 的痛点，

tag解决 "线上版本回溯" 的问题。

一、git stash：临时代码暂存

1. 什么时候用 stash？

你一定遇到过这种场景：

• 正在dev分支开发一个新功能，写了一半代码还没提交
• 突然线上出了 bug，需要立刻切回master分支修复
• 这时候直接切分支会报错：error: Your local changes would be overwritten by checkout
• 你又不想提交一堆不完整的垃圾代码

这时候就用git stash！它会把你当前未提交的所有改动临时储藏起来，让工作区变干净，等你处理完紧急事情再恢复回来。

2. 核心常用命令

3. 完整实操流程（跟着敲）

• 确保当前在dev分支，随便修改一个文件，不要提交

# 修改test.txt，加一行内容
echo "临时开发的代码" >> test.txt

# 查看状态，有未提交的改动
git status

• 临时储藏代码

git stash

输出：Saved working directory and index state WIP on dev: xxxxxx

• 现在工作区变干净了，可以安全切分支

git status
# 输出：nothing to commit, working tree clean

git checkout master
# 完美切换，没有报错

• 处理完紧急 bug，切回 dev 分支，恢复代码

git checkout dev

# 恢复暂存的代码
git stash pop

现在你之前写的临时代码就完整回来了，暂存记录也自动删除了。

4. 高级用法（必学）

4.1 暂存时加描述（推荐）

默认的暂存记录都是WIP on 分支名，时间长了分不清哪个是哪个。暂存时加描述：

git stash save "开发用户注册表单，完成了一半"

然后git stash list就能看到清晰的描述：

stash@{0}: On dev: 开发用户注册表单，完成了一半

4.2 恢复指定的暂存记录

如果你有多个暂存记录，可以指定恢复某一个：

# 查看所有暂存
git stash list
# 输出：
# stash@{0}: On dev: 第一个暂存
# stash@{1}: On dev: 第二个暂存

# 恢复第二个暂存（索引从0开始）
git stash apply stash@{1}

# 删除第二个暂存
git stash drop stash@{1}

4.3 暂存未跟踪的文件（新手必踩坑）

⚠️ 重点：默认的git stash只会暂存已经被 Git 跟踪过的文件（也就是之前 commit 过的文件）。新建的文件不会被暂存！

如果要暂存包括新建文件在内的所有改动，加-u参数：

git stash -u

• -u：全称–include-untracked，包含未跟踪文件

5. 新手最常见坑

• ❌ 新建的文件没被暂存：忘记加-u参数
• ❌ 恢复后代码不见了：不要在不同分支恢复同一个 stash，会产生冲突
• ❌ 暂存太多分不清：一定要加save "描述"

二、tag：版本标签（上线发布必备）

1. 什么是 tag？

tag 就是给某个提交打一个永久的、不可变的标记，通常用于标记线上发布版本。

比如：

• 你开发完 v1.0 版本上线，就给当时的提交打一个v1.0的 tag
• 以后线上出了 bug，直接切换到v1.0标签就能回溯到当时的代码
• tag 和分支的区别：分支会移动，tag 永远指向同一个提交

2. 两种标签类型

3. 常用命令

3.1 创建标签

# 创建附注标签（推荐）
git tag -a v1.0.0 -m "第一个正式上线版本"

# 给历史提交打标签
git tag -a v0.9.0 提交号 -m "测试版本"

3.2 查看标签

# 查看所有标签
git tag

# 查看标签详细信息
git show v1.0.0

3.3 推送标签到远程（GitHub）

⚠️ 重点：默认的git push不会推送标签到远程，必须手动推送！

# 推送单个标签
git push origin v1.0.0

# 推送所有本地标签
git push origin –tags

推送成功后，刷新 GitHub 仓库页面，点击Tags就能看到所有标签。

3.4 切换到标签版本

git checkout v1.0.0

这时候你会进入 "分离头指针" 状态（detached HEAD），意思是你现在不在任何分支上，只是在查看某个历史版本。

⚠️ 注意：不要在分离头指针状态下提交代码！如果需要修改，应该基于这个标签新建一个分支：

git checkout -b hotfix-v1.0.0 v1.0.0

3.5 删除标签

# 删除本地标签
git tag -d v1.0.0

# 删除远程标签
git push origin –delete tag v1.0.0

4. 完整实操流程（结合 GitHub）

• 确保当前在master分支，代码是最新的

git checkout master
git pull

• 打一个 v1.0.0 的正式版本标签

git tag -a v1.0.0 -m "第一个正式上线版本，包含用户注册登录功能"

• 推送标签到 GitHub

git push origin v1.0.0

• 去 GitHub 查看标签

  • 打开 GitHub 仓库页面 → 点击Releases → 点击Tags
  • 就能看到你刚才推送的v1.0.0标签
  • 点击标签名可以下载该版本的代码压缩包

• 切换到标签版本测试

git checkout v1.0.0

• 切回 master 分支

git checkout master

第三部分：Git Rebase 变基（企业级提交历史整理）

这是 Git 进阶中最容易混淆但也最实用的知识点。我会用最直白的对比讲清楚 Rebase 和 Merge 的区别、各自的使用场景，以及绝对不能踩的致命坑。

一、先搞懂：我们为什么需要 Rebase？

你之前用的是git merge合并分支，它会产生一个额外的合并提交，导致提交历史变成 "网状"，非常混乱。

比如你在dev分支开发，同时master分支也有新提交，用merge合并后历史会变成这样：

* 合并提交 (merge dev into master)
|\\
| * dev分支提交3
| * dev分支提交2
| * dev分支提交1
* | master分支提交2
* | master分支提交1
|/
* 初始提交

而git rebase（变基）能把提交历史整理成一条干净的直线，看起来非常清晰，这也是绝大多数互联网公司要求的提交规范。

二、核心原理：Rebase vs Merge 本质区别

一句话总结

• Merge：保留所有提交历史，产生新的合并提交，历史是网状的
• Rebase：重写提交历史，不产生额外提交，历史是线性的

通俗类比

• Merge 就像两条路汇合成一条十字路口，会留下交汇的痕迹
• Rebase 就像把 dev 分支的所有提交 "剪下来"，重新 "贴" 到 master 分支的最新提交后面

直观对比图

注意：Rebase 后的 D' 和 E' 和原来的 D、E内容完全一样，只是提交 ID 变了，因为它们的 "基础"（父提交）变了。

三、最常用场景 1：用 Rebase 合并分支

完整实操流程

• 先回到 master 分支，拉取最新代码

git checkout master
git pull

• 创建并切换到 dev 分支，做几次提交

git checkout -b dev
echo "第一次修改" >> test.txt
git add .
git commit -m "feat: 第一次修改"

echo "第二次修改" >> test.txt
git add .
git commit -m "feat: 第二次修改"

• 切回 master，模拟别人提交了新代码

git checkout master
echo "master分支的新提交" >> test.txt
git add .
git commit -m "feat: master新增功能"

• 现在用 Rebase 合并 dev 分支到 master（关键步骤）

# 先切回dev分支
git checkout dev

# 执行变基：把dev分支的提交"搬"到master最新提交后面
git rebase master

• 如果有冲突，解决冲突后继续变基

# 解决冲突后，把修复后的文件加入暂存
git add .

# 继续变基（不要commit！）
git rebase –continue

• 变基完成后，切回 master，执行快进合并

git checkout master
git merge dev

现在执行git log –oneline，你会看到提交历史是一条完美的直线，没有任何多余的合并提交！

四、最常用场景 2：整理本地零散提交（git rebase -i）

这是 Rebase 最实用的功能！开发中我们经常会提交很多零散的 "垃圾提交"：

git commit -m "写了一半"
git commit -m "修复bug"
git commit -m "又修复bug"
git commit -m "终于写完了"

用git rebase -i可以把这些零散的提交合并成一个干净的提交，再推送到远程。

完整实操

• 查看最近 n 次提交

# 整理最近4次提交
git rebase -i HEAD~4

• 会进入一个交互式编辑界面，看起来像这样：

pick 7a2f91c 写了一半
pick 3b4d7e8 修复bug
pick 9c1a2b3 又修复bug
pick 5d6e7f8 终于写完了

# 命令:
# p, pick = 保留这个提交
# s, squash = 合并到上一个提交
# f, fixup = 合并到上一个提交，丢弃提交信息
# r, reword = 修改提交信息
# d, drop = 删除这个提交

• 修改命令，把后面 3 个提交合并到第一个

pick 7a2f91c 写了一半
squash 3b4d7e8 修复bug
squash 9c1a2b3 又修复bug
squash 5d6e7f8 终于写完了

• 保存退出（vim 按Esc，输入:wq回车），会进入第二个编辑界面，让你写新的提交信息

# 把原来的提交信息删掉，写一个清晰的
feat: 完成用户登录功能，包含表单验证和接口调用

• 保存退出，完成！执行git log –oneline，你会看到 4 个提交变成了 1 个干净的提交。

五、Rebase 黄金法则

 致命警告：永远不要对已经推送到远程的公共分支执行 Rebase！

为什么？

Rebase 会重写提交历史，改变提交 ID。如果别人已经基于旧的提交 ID 做了开发，你重写历史后推送到远程，别人拉取代码时会产生灾难性的冲突，整个团队的提交历史都会乱掉。

正确的使用范围

✅ 只能对只有你自己在使用的本地分支执行 Rebase

✅ 只能对还没有推送到远程的提交执行 Rebase

❌ 绝对不能对 master、dev 等公共分支执行 Rebase

❌ 绝对不能对已经推送到远程的提交执行 Rebase

六、进阶：git pull –rebase（推荐日常使用）

多人协作时，每次git pull拉取代码，默认会用merge合并，产生一个多余的 "Merge branch 'master' of github.com:xxx/xxx" 提交，非常难看。

推荐永远用git pull –rebase代替默认的git pull：

git pull –rebase origin master

它会先拉取远程最新代码，然后把你本地未推送的提交 "搬" 到远程最新提交后面，不会产生多余的合并提交，历史保持干净。

全局配置（一劳永逸）

设置 Git 默认 pull 时使用 rebase：

git config –global pull.rebase true

以后直接执行git pull就等价于git pull –rebase了。

七、常见问题及解决方法

# 放弃本次变基，恢复到变基前的状态
git rebase –abort

八、核心总结

最终建议

• 个人开发：大胆用 Rebase，保持提交历史干净
• 团队协作：拉取代码用git pull –rebase，合并 PR 用 Merge（GitHub 默认）
• 永远记住：公共分支不能 Rebase！

第四部分：企业级 Git 工作流（Git Flow）｜面试必问 + 工作直接用

前面我们学完了所有 Git 核心命令，但真正在团队工作中，没有规范的分支管理比不会用 Git 更可怕。本节课讲的Git Flow是全世界互联网公司最通用的分支管理规范，也是面试 100% 会问到的知识点。

一、为什么需要 Git 工作流？

想象一下 10 个人同时开发一个项目：

• 有人直接在 master 分支写代码
• 有人分支名乱起，分不清是开发什么功能
• 上线前发现代码混进了未完成的功能
• 线上出了 bug，不知道该回滚到哪个版本

Git Flow 就是一套标准化的分支命名、创建、合并、删除规则，让所有团队成员的操作保持一致，从根本上避免这些混乱。

二、Git Flow 核心分支模型（5 种分支）

Git Flow 把分支分为长期分支和临时分支两大类：

1. 长期分支（永远存在，不能删除）

✅ 铁律：永远不要直接在 master 和 develop 分支提交代码！所有代码都必须通过临时分支合并进来。

2. 临时分支（用完就删，生命周期短）

三、完整的 Git Flow 工作流程（跟着走一遍就懂）

我们用一个实际的项目周期来演示：当前线上版本是v1.0.0，现在要开发v1.1.0版本，包含用户注册和登录两个功能。

阶段 1：开发新功能（feature 分支）

每个功能单独开一个 feature 分支，互不干扰。

# 1. 先切回develop分支，拉取最新代码
git checkout develop
git pull

# 2. 基于develop创建feature分支
git checkout -b feature/user-registration

# 3. 开发功能，频繁提交
git add .
git commit -m "feat: 实现用户注册表单"
git commit -m "feat: 实现注册接口调用"

# 4. 开发完成，推送到远程
git push -u origin feature/user-registration

git checkout develop
git pull
git branch -d feature/user-registration

阶段 2：发布版本（release 分支）

当所有计划的功能都开发完成并合并到 develop 后，就可以准备发布新版本了。

git checkout develop
git pull
git checkout -b release/v1.1.0
git push -u origin release/v1.1.0

# 修复bug
git add .
git commit -m "fix: 修复注册时密码长度验证错误"
git push

# 1. 合并到master
git checkout master
git pull
git merge –no-ff release/v1.1.0

# 2. 打版本标签
git tag -a v1.1.0 -m "发布v1.1.0版本，新增用户注册登录功能"
git push origin v1.1.0

# 3. 合并回develop
git checkout develop
git pull
git merge –no-ff release/v1.1.0
git push

# 4. 删除release分支
git branch -d release/v1.1.0
git push origin –delete release/v1.1.0

阶段 3：修复线上紧急 bug（hotfix 分支）

线上版本突然出现严重 bug，需要立刻修复，这时候用 hotfix 分支。

git checkout master
git pull
git checkout -b hotfix/v1.1.1

git add .
git commit -m "fix: 修复用户登录时验证码错误的bug"
git push -u origin hotfix/v1.1.1

# 1. 合并到master
git checkout master
git pull
git merge –no-ff hotfix/v1.1.1

# 2. 打补丁版本标签
git tag -a v1.1.1 -m "修复v1.1.0登录验证码bug"
git push origin v1.1.1

# 3. 合并回develop
git checkout develop
git pull
git merge –no-ff hotfix/v1.1.1
git push

# 4. 删除hotfix分支
git branch -d hotfix/v1.1.1
git push origin –delete hotfix/v1.1.1

四、核心知识点补充

1. 语义化版本号规范（必须遵守）

所有版本号都遵循主版本号.次版本号.补丁版本号的格式：

• 补丁版本号（v1.1.1）：修复 bug，不改变功能
• 次版本号（v1.2.0）：新增功能，向下兼容
• 主版本号（v2.0.0）：不兼容的重大改动

2. 提交信息规范（Angular 规范）

所有 commit 信息都遵循以下格式，方便自动生成更新日志：

<type>(<scope>): <subject>

常用 type：

• feat：新功能
• fix：修复 bug
• docs：文档修改
• style：代码格式修改
• refactor：代码重构
• test：测试相关
• chore：构建工具或依赖修改

示例：

feat(user): 实现用户注册功能
fix(login): 修复验证码过期时间错误
docs: 更新README.md

3. PR 合并方式选择（GitHub）

GitHub 提供三种合并方式，推荐用法：

• Squash and merge：把 feature 分支的所有提交合并成一个提交到 develop，保持历史干净（推荐）
• Rebase and merge：变基合并，保持线性历史
• Create a merge commit：产生合并提交，保留所有历史（用于 release 和 hotfix 合并到 master）

五、其他常见工作流对比

✅ 面试建议：重点掌握 Git Flow，知道它的 5 种分支和完整流程。提到其他工作流能说出区别即可。

六、新手最容易犯的错误

七、核心要点

Git Flow 的本质是把不同阶段的代码隔离在不同分支，通过标准化的流转流程保证代码质量和发布安全。

• 新功能：feature → develop
• 版本发布：release → develop + master
• 线上 bug：hotfix → develop + master

第五部分：总结

本文是一篇全面的Git进阶教程，重点介绍了远程仓库协作、分支管理和企业级Git工作流。主要内容包括：

本文适合有一定Git基础的用户，内容涵盖从日常开发到团队协作的全流程Git操作，特别适合准备面试或需要规范团队Git流程的开发者。