在团队协作开发中，Git 是版本控制与代码协作的核心工具，而分支管理则是保障开发流程高效、代码质量稳定的关键。下面结合分支管理的核心操作，补充日常开发中高频使用的 Git 知识点，帮你构建完整的 Git 协作知识体系。

一、分支基础操作（图片知识点补充说明）

先梳理图中核心分支操作的细节与易错点，避免实际使用中踩坑：

操作场景	命令	补充说明
初始化仓库并指定默认分支	git init -b <分支名称>	常用于新项目初始化，直接指定主分支为 main（而非旧版默认的 master），适配现代项目规范。
已有仓库创建分支（仅创建）	git branch <分支名称>	仅创建分支，不会自动切换，创建后需手动 checkout 或 switch 进入分支开发。
已有仓库创建并切换分支	git checkout -b <分支名称> / git switch -c <分支名称>	两种命令效果一致，git switch 是 Git 2.23+ 推出的更易读的分支切换命令，推荐优先使用。
查看分支	git branch	仅查看本地分支；git branch -a 可查看本地 + 远程所有分支，git branch -v 可查看分支最后一次提交信息。
切换分支	git checkout <分支名称> / git switch <分支名称>	切换前需确保当前分支的修改已提交或暂存，否则会导致修改被带到目标分支，引发代码混乱。
删除分支	git branch -d <分支名称>	-d 仅能删除已合并的分支；若需强制删除未合并的分支，使用 git branch -D <分支名称>，需谨慎操作，避免丢失代码。
重命名分支	git branch -m <原名称> <新名称>	若需重命名当前所在分支，可省略原名称：git branch -m <新名称>；重命名后需同步更新远程分支（删除旧分支 + 推送新分支）。
合并分支	git merge <被合并分支名称>	合并到当前分支，默认使用 “快进合并”；若存在分支分叉，会生成合并提交；合并前建议先拉取目标分支最新代码，减少冲突概率。

---

二、日常开发高频补充操作

除了基础分支操作，以下是团队协作中每天都会用到的 Git 操作，是代码协作的核心能力：

1. 远程仓库操作（拉取 / 推送 / 关联）

• 关联远程仓库：

  git remote add origin <远程仓库地址>

  关联后可通过 git remote -v 查看远程仓库配置，多远程仓库场景下通过别名区分不同仓库。

• 拉取远程代码：

  # 拉取远程指定分支的最新代码，合并到当前分支 
  git pull origin <分支名称> 
  # 等价于 fetch + merge：先拉取远程代码但不自动合并
  git fetch origin 
  git merge origin/<分支名称>

    git fetch 更安全，可先查看远程更新再手动合并，避免自动合并引发的冲突问题。

• 推送本地分支到远程：

  # 首次推送本地新分支到远程，关联远程分支
  git push -u origin <分支名称> 
  # 后续推送直接使用 
  git push

2. 提交管理（暂存 / 提交 / 修改提交）

• 暂存修改：

  # 暂存单个文件 
  git add <文件名> 
  # 暂存所有修改的文件 
  git add .

• 提交修改：

  git commit -m "feat: 完成用户登录接口开发"

  推荐使用规范的提交信息格式（如 Conventional Commits），方便版本管理与日志生成。

• 修改最近一次提交信息：

  git commit --amend

    可修改提交信息，或补充遗漏的文件到上一次提交中，仅适用于未推送到远程的提交。

3. 代码暂存与恢复（Stash）

当你在分支上开发到一半，需要临时切换到其他分支处理问题时，可使用 stash 暂存当前修改：

# 暂存当前所有修改（未提交的代码） 
git stash save "临时暂存：用户模块开发中" 
# 查看暂存列表 
git stash list 
# 恢复最近一次暂存的修改（保留暂存记录） 
git stash apply 
# 恢复并删除暂存记录 
git stash pop 
# 清空所有暂存记录 
git stash clear

4. 冲突解决

分支合并或拉取远程代码时，若出现代码冲突，Git 会标记冲突文件，手动解决后需重新提交：

1. 打开冲突文件，找到 <<<<<<< HEAD（当前分支代码）、=======（被合并分支代码）、>>>>>>> <分支名> 标记的内容，手动保留需要的代码。

2. 暂存修改后的文件：git add <冲突文件>

3. 完成合并提交：git commit -m "resolve: 解决登录接口参数冲突"

5. 分支规范与协作流程

团队开发中，合理的分支规范能大幅降低协作成本，常见的分支模型如下：

• main：主分支，始终保持可部署状态，仅合并已测试完成的代码。

• develop：开发分支，用于集成各功能分支的代码，作为发布前的统一测试分支。

• feature/*：功能分支，从 develop 分支创建，用于开发单个功能，开发完成后合并回 develop。

• hotfix/*：热修复分支，从 main 分支创建，用于线上紧急问题修复，修复完成后合并回 main 和 develop。

---

三、进阶实用操作（提升协作效率）

1. 查看提交历史

# 查看简洁的提交历史 
git log --oneline 
# 查看分支图形化提交历史，清晰展示分支分叉与合并 
git log --oneline --graph --all

2. 回退与撤销操作

• 撤销工作区修改（未暂存）：

  git checkout -- <文件名>

• 撤销暂存区修改（已 add 未 commit）：

  git reset HEAD <文件名>

• 回退到指定提交（已 commit 未推送）：

  # 软回退：保留修改，仅撤销提交 
  git reset --soft <提交ID> 
  # 硬回退：直接丢弃提交后的所有修改，谨慎使用 
  git reset --hard <提交ID>

3. 标签管理（版本发布）

在项目发布版本时，可通过标签标记版本号，方便回溯：

# 创建本地标签 
git tag -a v1.0.0 -m "release: 版本1.0.0发布" 
# 推送标签到远程 
git push origin v1.0.0 
# 查看所有标签 
git tag -l

---

四、日常协作避坑指南

1. 提交前先拉取最新代码：每次提交或合并前，先拉取目标分支的最新代码，避免基于过时版本开发，减少冲突。

2. 避免在 main 分支直接修改：所有开发都应在功能分支完成，通过合并流程同步到主分支，保障主分支稳定性。

3. 提交信息要清晰：避免使用 update fix bug 这类模糊信息，清晰的提交信息能帮助团队快速理解修改内容，也方便后续问题排查。

4. 谨慎使用强制推送：git push -f 会覆盖远程分支的历史提交，仅在明确知道风险的场景下使用，避免影响其他协作者。

---

这些 Git 操作覆盖了从个人开发到团队协作的全流程，熟练掌握基础分支操作与高频协作命令，能让你在项目开发中高效管理代码版本，避免因 Git 操作不当导致的代码丢失或协作混乱。