git仓库分支管理

3.8、仓库分支管理

基础认知：

基于单颗 SOC 开发多项目，单 Git 仓库 + 多平级项目分支是最优方案，兼顾代码复用、项目隔离与管理简洁性，无需维护多仓库；
Git 仓库同一本地目录下，同一时间仅能显示一个分支的代码，无分支嵌套（项目B ≠ 项目A 子分支），所有项目分支均基于空主分支 / 基础分支平级创建；
分支间的代码切换、隔离由 Git 底层「指针切换 + 文件快照」机制管理，工作目录文件会随分支切换动态更新为对应分支内容，无法手动同时显示多分支代码；
所有分支操作（创建、切换、推送、拉取、合并）必须通过 Git 命令完成，禁止手动复制 / 修改跨分支文件，避免版本混乱。

1、推荐分支结构设计

1.1、空主分支基线

适用于项目无公共 SOC 基础代码，或公共代码后续逐步沉淀的场景，核心为「空主分支 + 平级项目分支」，所有项目初始代码完全一致（空），隔离性拉满。

plaintext 复制代码

main/master（空，仓库主干）------ 所有项目分支的公共创建基线，不存放业务代码
├─ proj-A（项目A独立分支，平级）------ 存储项目A全量定制化代码，独立开发/迭代
└─ proj-B（项目B独立分支，平级）------ 存储项目B全量定制化代码，与proj-A互不关联

1.2、基础分支复用

适用于有通用 SOC 基础代码（驱动、底层 API、初始化配置等）的场景，核心为「主分支 + 基础分支 + 平级项目分支」，最大化复用 SOC 基础代码，避免重复开发。

plaintext 复制代码

main/master（稳定SOC基础代码，仓库主干）------ 存储可发布的纯净SOC核心基础代码，禁止直接提交
├─ soc-base（SOC基础分支，公共父分支）------ 基于main创建，仅维护SOC通用代码，所有项目分支的统一基线
   ├─ proj-A（项目A独立分支，平级）------ 基于soc-base创建，叠加项目A定制化代码
   ├─ proj-B（项目B独立分支，平级）------ 基于soc-base创建，叠加项目B定制化代码
   └─ proj-C（项目C独立分支，平级）------ 基于soc-base创建，叠加项目C定制化代码

1.3、分支核心规则

主分支（main）：仅做「基线创建」+「稳定代码存储」，禁止直接提交 / 修改，仅通过合并更新；
基础分支（soc-base，可选）：仅维护 SOC 通用代码，不包含任何项目定制代码，基础更新（如驱动 bug 修复）仅在此分支操作；
项目分支（proj-A/B/C）：平级创建、独立开发，仅存储对应项目的定制化代码，禁止跨项目分支合并（如 proj-A → proj-B）；
所有开发：全程在项目分支内完成，不切换到主分支 / 基础分支（除非同步公共代码）。

2、`Git`核心底层原理

仓库核心目录：.git隐藏文件夹是 Git 仓库的「大脑」，存储所有分支的完整代码快照、版本记录、分支指针，工作目录仅为代码「展示窗口」；
分支指针：每个分支对应一个指针，指向该分支的最新代码提交，分支切换本质是「指针切换」；
动态更新机制：执行git switch 分支名时，Git 会完成 2 件事
- ① 切换分支指针到目标分支；
- ② 根据目标分支最新快照，自动更新工作目录文件，匹配该分支代码状态；
轻量性：Git 分支操作仅操作指针，不复制文件，所有分支的原始数据均在.git中统一管理，高效且节省磁盘空间。

3、核心`Git`命令

3.1、仓库初始化与分支创建

管理员操作，仅初次

bash 复制代码

# 1. 克隆远程空仓库（本地无仓库时）
git clone 远程仓库地址（如GitHub/GitLab）
cd 仓库目录（如soc-multi-proj）

# 2. 本地初始化仓库（无远程仓库时）
mkdir soc-multi-proj && cd soc-multi-proj
git init
git remote add origin 远程仓库地址  # 关联远程仓库

# 3. 创建基础分支（进阶结构用，可选）
git switch -c soc-base  # 基于当前分支（main）创建并切换到soc-base
git push -u origin soc-base  # 推送远程并建立关联（-u=--set-upstream）

# 4. 创建平级项目分支（核心：先切回基线分支，保证基线一致）
## 极简版（基于空main）
git switch main
git switch -c proj-A && git push -u origin proj-A  # 创建proj-A并推送远程
git switch main
git switch -c proj-B && git push -u origin proj-B  # 创建proj-B并推送远程

## 进阶版（基于soc-base）
git switch soc-base
git switch -c proj-A && git push -u origin proj-A
git switch soc-base
git switch -c proj-B && git push -u origin proj-B

3.2、分支基础操作（查看 / 切换 / 删除）

bash 复制代码

# 1. 查看分支
git branch          # 查看本地所有分支（*标记当前分支）
git branch -a       # 查看本地+远程所有分支
git branch -vv      # 查看本地分支与远程分支的关联关系

# 2. 切换分支（Git2.23+推荐，老版本用git checkout 分支名）
git switch 分支名    # 如git switch proj-A、git switch soc-base

# 3. 删除分支
git branch -d 本地分支名  # 安全删除已合并的本地分支
git branch -D 本地分支名  # 强制删除未合并的本地分支（慎用）
git push origin --delete 远程分支名  # 删除远程分支（如git push origin --delete proj-A）

3.3、推送 / 拉取 / 提交

核心原则：所有操作均在「当前项目分支」内完成

bash 复制代码

# 1. 确认当前分支（避免操作错误分支）
git branch

# 2. 本地开发后，暂存+提交（备注规范：项目标识+功能/修改）
git add .  # 暂存所有修改文件（也可指定文件：git add 文件名）
git commit -m "projA: 完成XX业务功能开发"  # 如projB: 修复SOC驱动适配bug

# 3. 推送到远程项目分支（首次推送加-u后，后续直接git push即可）
git push  # 等价于git push origin 当前分支名

# 4. 拉取队友的远程更新（合并到本地当前分支，无冲突直接合并）
git pull  # 等价于git fetch origin + git merge origin/当前分支名

# 5. 仅拉取远程信息，不合并（如需查看更新再决定是否合并，安全）
git fetch origin

3.4、公共代码同步

基础分支更新后，同步到各项目分支，比如soc-base/main 分支的 SOC 基础代码优化 / 修复，需同步到所有项目

bash 复制代码

# 1. 先在基础分支完成修改并推送（管理员操作）
git switch soc-base
git add . && git commit -m "soc-base: 修复UART驱动接收乱码bug"
git push

# 2. 切换到项目分支，合并基础分支（同步更新，proj-B同理）
git switch proj-A
git merge soc-base  # 将soc-base的最新代码合并到proj-A
# 若有冲突：解决冲突后→git add .→git commit -m "projA: 同步soc-base驱动bug修复"
git push  # 推送同步后的代码到远程proj-A

4、工程目录动态变化示例

以极简版结构（空 main+proj-A/proj-B）为例，全程在同一目录soc-multi-proj操作，展示分支切换时的目录变化，核心：目录路径不变，文件随分支动态更新。

前提：已创建 proj-A（含专属文件）、proj-B（含专属文件），均推送到远程

当前分支为 proj-A，目录显示项目 A 代码

bash 复制代码

git switch proj-A
git branch  # 输出：* proj-A  |  proj-B  |  main
ls -la      # 查看目录文件

目录结构（仅显示 proj-A 文件，.git 为核心管理目录）：

plaintext 复制代码

soc-multi-proj/  # 唯一工作目录，路径全程不变
├── .git/        # 隐藏目录：存储所有分支的快照、指针、版本（核心，无任何变化）
│   ├── refs/heads/  # 分支指针：proj-A、proj-B、main
│   ├── objects/     # 所有分支的代码快照（Git底层二进制存储）
│   └── ...（其他Git配置/记录文件）
├── projA_main.c     # 项目A专属代码文件
├── projA_config.h   # 项目A专属配置文件
└── README-A.md      # 项目A专属说明文档

切换到 proj-B，目录自动更新为项目 B 代码

bash 复制代码

git switch proj-B
git branch  # 输出：proj-A  |  * proj-B  |  main
ls -la      # 查看目录文件

目录结构（Git 自动移除 proj-A 文件，生成 proj-B 文件，.git 不变）：

plaintext 复制代码

soc-multi-proj/
├── .git/        # 核心目录无任何变化，仅分支指针切换
├── projB_main.c     # 项目B专属代码文件
├── projB_config.h   # 项目B专属配置文件
└── README-B.md      # 项目B专属说明文档

切换回空 main 分支，目录仅保留.git

bash 复制代码

git switch main
git branch  # 输出：proj-A  |  proj-B  |  * main
ls -la      # 查看目录文件

目录结构（无任何业务文件，因 main 为空白分支）：

plaintext 复制代码

soc-multi-proj/
└── .git/  # 仅核心Git目录，存储所有分支数据

5、多分支同时操作方案

开发中需要同时对比 proj-A/proj-B 代码，或并行编辑多分支内容

5.1、多目录克隆同一仓库

同一远程仓库，本地不同路径分别克隆，各目录绑定不同分支，独立无干扰

bash 复制代码

# 克隆仓库到目录1：绑定proj-A，专门开发项目A
git clone 远程仓库地址 soc-proj-A
cd soc-proj-A && git switch proj-A

# 克隆仓库到目录2：绑定proj-B，专门开发项目B
git clone 远程仓库地址 soc-proj-B
cd soc-proj-B && git switch proj-B

plaintext 复制代码

本地开发目录/
├── soc-proj-A/  # 显示proj-A代码，可编辑/提交/推送，独立管理
└── soc-proj-B/  # 显示proj-B代码，可编辑/提交/推送，与soc-proj-A互不影响

优势：操作无学习成本，各目录独立，冲突风险为 0；

适用：日常开发、代码对比、多分支并行调试。

5.2、`Git`原生`worktree`

工作区，高效进阶，熟练用户推荐，为单个本地仓库创建多个独立工作目录，共享同一个.git 目录（无需重复克隆），节省磁盘空间，单仓库统一管理

bash 复制代码

# 进入已有的主仓库目录（含.git，已创建proj-A/proj-B）
cd soc-multi-proj

# 为proj-A创建独立工作区（上级目录生成soc-proj-A，绑定proj-A）
git worktree add ../soc-proj-A proj-A

# 为proj-B创建独立工作区（上级目录生成soc-proj-B，绑定proj-B）
git worktree add ../soc-proj-B proj-B

# 查看所有工作区（确认分支绑定关系）
git worktree list

目录结构（共享.git，多目录同时显示多分支代码）：

复制代码

parent-dir/
├── soc-multi-proj/  # 主仓库目录（含.git核心目录，所有工作区共享）
├── soc-proj-A/      # proj-A工作区：显示proj-A代码，可正常开发/提交
└── soc-proj-B/      # proj-B工作区：显示proj-B代码，可正常开发/提交

常用操作：

bash 复制代码

# 进入工作区开发（与普通仓库操作完全一致）
cd ../soc-proj-A
git add . && git commit -m "projA: 修复XXbug" && git push

# 删除无用工作区（仅删除目录，不删除分支/代码，安全）
git worktree remove ../soc-proj-A

优势：共享.git，节省磁盘空间；单仓库统一管理所有分支，版本追溯更便捷；

适用：代码对比、大型项目多分支并行开发、分支调试。

6、关键注意事项

禁止分支嵌套：绝对不要将 proj-B 作为 proj-A 的子分支创建，会导致 proj-B 继承 proj-A 的定制代码，破坏项目隔离性，所有项目分支必须平级；
禁止跨分支手动操作：切勿在单目录内手动复制其他分支的文件，或修改其他分支的代码，会导致 Git 版本追踪混乱，冲突频发；
同步公共代码前拉取最新：合并 soc-base/main 到项目分支前，务必先执行git pull origin soc-base，拉取远程最新基础代码，保证基线一致；
冲突处理原则：合并基础分支到项目分支时，若出现冲突，优先保留基础分支的 SOC 核心代码逻辑，调整项目定制化代码，避免破坏底层功能；
禁止直接修改主分支 / 基础分支：主分支（main）和基础分支（soc-base）仅由管理员维护，普通开发人员禁止直接提交 / 推送，避免公共代码被污染；
提交备注规范：所有提交备注必须带项目标识（如 projA/projB），便于后续版本追溯、代码排查（如projA: 优化XX业务逻辑）；
定期清理无用分支：项目开发完成并正式发布后，若无需后续维护，及时删除对应的本地 / 远程分支，保持仓库整洁。

7、整体管理流程梳理

从初始化到日常协作，标准化步骤

仓库初始化阶段（管理员 1 次操作）
1. 远程创建空仓库（不勾选 README / 许可证，保持纯空）
2. 本地克隆仓库，初始化主分支(main)
3. （可选）创建 SOC 基础分支(soc-base)并推送远程
4. 基于基线分支(main/soc-base)创建所有项目分支，平级推送远程。
团队开发准备阶段（每个开发人员）
1. 克隆远程仓库到本地
2. 切换到自己负责的项目分支（git switch 项目分支名）
3. 确认分支关联关系（git branch -vv），准备开发。
日常开发阶段（核心，团队协作）
1. 全程在项目分支内开发，不切换其他分支
2. 本地修改后，规范提交（带项目标识）
3. 及时推送远程（避免本地代码丢失）
4. 每日开发前拉取远程更新（同步队友代码）
公共代码同步阶段（基础分支更新时）
1. 管理员在基础分支（soc-base）完成 SOC 代码修改并推送
2. 各开发人员切换到自己的项目分支
3. 合并基础分支到项目分支，解决冲突后推送远程。
项目收尾阶段（项目发布后）
1. 项目分支代码测试通过，正式发布
2. （可选）将项目分支合并到 main 分支（做版本归档）
3. 无需维护时，删除对应的本地 / 远程项目分支。

git仓库分支管理

3.8、仓库分支管理

1、推荐分支结构设计

1.1、空主分支基线

1.2、基础分支复用

1.3、分支核心规则

2、Git核心底层原理

3、核心Git命令

3.1、仓库初始化与分支创建

3.2、分支基础操作（查看 / 切换 / 删除）

3.3、推送 / 拉取 / 提交

3.4、公共代码同步

4、工程目录动态变化示例

5、多分支同时操作方案

5.1、多目录克隆同一仓库

5.2、Git原生worktree

6、关键注意事项

7、整体管理流程梳理

2、`Git`核心底层原理

3、核心`Git`命令

5.2、`Git`原生`worktree`