Git 工作树 (worktree)、合并 (merge) 流程、拉取请求 (PR) 机制，以及基线分支概念

提升效率：掌握 Git 工作流中的高阶技巧与基线管理

在团队协作和复杂项目开发中，高效使用 Git 远不止 commit 和 push 这么简单。掌握 git worktree、规范的合并流程和 PR 机制，是提升开发效率的关键。本文将为您梳理这些核心概念及其在实际工作中的应用。

git worktree 允许你在同一个 Git 仓库中创建多个独立的工作目录。这完美解决了需要频繁切换分支来处理紧急任务（Hotfix）的痛点。

创建新的工作树：从 main 分支切出 hotfix 分支，并在新目录中开始工作。
Bash
```
# 在主仓库目录执行
git worktree add ../hotfix-branch hotfix
```

在工作树中开发：进入新目录进行修改、提交、推送。

Bash 

cd ../hotfix-branch
git add .
git commit -m "fix: 修复紧急 bug"
git push origin hotfix

合并与清理：在主仓库目录完成合并后，清理工作树。

Bash 

# 在主仓库目录执行
git worktree remove ../hotfix-branch
# 手动删除目录 (如 Windows)
rmdir /s /q D:\CPP_ws\hotfix-branch

当你试图在主仓库切换到已被工作树使用的分支时，会收到报错：

fatal: 'feature-a' is already used by worktree at 'D:/CPP_ws/feature-a-branch'

解决办法：要么进入该工作树目录继续操作，要么使用 git worktree remove <路径> 将其移除。

合并的最终目的是将一个分支（如 dev 或 feature）的变更安全、完整地集成到另一个分支（如 master）。

前提：确保本地 dev 分支上的所有工作都已 commit 并 push 到远程 origin/dev。

切换到目标分支：切换到要接收变更的 master 分支。
Bash
```
git checkout master
```
更新目标分支：拉取远程 master 的最新状态。
Bash
```
git pull origin master
```
执行合并：将远程的 dev 分支（即 origin/dev）合并到当前的本地 master 分支。
Bash
```
git merge origin/dev
```
推送到远程：将合并后的本地 master 推送到远程，完成集成。
Bash
```
git push origin master
```

提 PR 是团队协作中将特性分支合并到基线分支的标准流程，它确保了所有代码都经过了审核和质量检查。

本地开发与推送：
- 从基线分支（如 develop）创建新的特性分支。
- 完成工作后，提交并推送到远程仓库：git push -u origin my-new-feature。
发起 PR（平台操作）：
- 在 GitHub/GitLab 等平台上，选择将 my-new-feature 合并到 develop（或 main）。
- 清晰填写 PR 标题、描述，并指派审核人。
代码审查与迭代：
- 接收审核人反馈，在本地分支进行修改、提交。
- git push 到远程，PR 将自动更新。
合并与关闭：
- 审核通过后，点击 Merge 按钮合并到目标基线分支。
- （重要）在平台上删除已合并的特性分支，保持仓库整洁。

基线分支是一个项目管理概念，指的是一个稳定、可靠、被认可作为开发起点的分支，用于确保代码质量和项目稳定。

基线分支	角色定位	特点与用途
`master` / `main`	生产环境基线	永远只包含已发布、随时可部署的代码。通常只能接收来自 `release` 分支的合并，禁止直接提交。
`develop`	开发集成基线	包含了所有已完成并通过审核的功能。所有新的特性分支（`feature/`）都必须从 `develop` 拉出。

所有新功能：都应该基于 develop 分支创建。
PR 目标：日常开发的 PR 目标通常是 develop 分支。
发布时：从 develop 切出 release/vX.X 分支进行最后的测试和 Bug 修复，完成后再合并到 master 和 develop，以同步修复。