Git 分支流程（合并分支）

一、 核心原则

1. 保护主干分支：develop 和 main 等主干分支是项目的“生命线”，必须保持稳定。禁止直接在这些分支上进行功能开发。
2. 功能隔离：每个新功能或 Bug 修复都应在独立的 feature/xxx 或 bugfix/xxx 分支上进行开发。
3. 先拉后合：在合并前，必须确保自己的主干分支是最新状态，以减少冲突。
4. 解决冲突是责任：合并时产生的冲突，由发起合并的开发者负责解决。

二、 标准合并流程（推荐 --squash 模式）

此流程旨在将一个功能分支的所有变更，以一个干净的提交合并到主干分支，保持提交历史的简洁与线性。
阶段一：合并前准备

1. 完成本地开发
   ○ 在功能分支（如 feature/ob360studio_logger）上完成所有开发和测试。
   ○ 确保代码在本地编译通过并能正常运行。
2. 提交所有本地更改
   ○ 执行 git status 检查工作区状态。
   ○ 将所有相关修改 git add . 并 git commit 提交。
   ○ 目的：确保工作区“干净”，避免合并时因未跟踪文件或未提交修改而中断。
3. 切换到目标分支
   ○ 切换到你想要合并进去的分支，通常是 develop。

   git checkout develop
   

4. 拉取最新代码
   ○ 确保你的 develop 分支是远程最新的。

   git pull origin develop
   

   ○ 目的：将其他同事的最新提交同步到本地，最大限度地减少合并冲突。
   阶段二：执行合并
5. 执行 --squash 合并
   ○ 使用 --squash 参数将功能分支的所有变更“压平”为一个待提交的变更集。

   git merge --squash feature/xxx
   

   ○ 效果：该命令会将 feature/xxx 分支上的所有文件变更，应用到你当前的 develop 分支工作区中，但不会创建任何提交记录。
6. 处理合并过程中的问题
   ○ 问题：
   ■ 原因：你在 develop 分支上有未提交的修改，而这些修改的文件在功能分支中也被改动了。
   ■ 解决：在执行 git checkout develop 前，先提交或暂存 (git stash) 你的本地修改。
   ○ 问题：
   ■ 原因：你的工作区存在一个未被 Git 跟踪的文件（例如 Logger.cpp），而功能分支中也存在同名文件。
   ■ 解决：在合并前，先处理该文件。你可以：
   ■ git add 它，使其被跟踪。
   ■ 临时重命名或移动它（如 mv Logger.cpp Logger.cpp.backup）。
   ■ 如果确定不需要，直接删除 (rm Logger.cpp)。
7. 提交合并结果
   ○ --squash 操作完成后，所有变更都处于“已暂存”状态。
   ○ 执行一次提交，将这些变更正式纳入 develop 分支。
   git commit -m “feat: add logger module from xxx”
   ○ 关键：提交信息应清晰描述本次合并的功能。

如果你在合并后对代码做了任何手动修改（包括解决冲突、调整格式、删除调试代码等），都必须重新执行 git add 和 git commit，否则这些修改不会被纳入版本控制

1. 检查修改了哪些文件

git status

2. 将修改加入暂存区

git add .

3. 重新提交（可以 amend 到上一次提交，或新建一次提交）

选项 A：合并到上一次提交（保持只有一个提交）

git commit --amend --no-edit

选项 B：新建一次提交（保留修改记录）

git commit -m "fix: adjust merged code for compatibility"

阶段三：合并后操作

1. 推送更新
   ○ 将合并后的 develop 分支推送到远程仓库。

   git push origin develop
   

2. 清理功能分支
   ○ （可选但推荐） 删除已合并的功能分支，保持分支列表整洁。
   ○ 删除本地分支：

   git branch -d feature/xxx
   

   ○ 删除远程分支：

   git push origin --delete feature/xxx
   

3. 通知团队
   ○ 通过团队沟通工具（如企业微信、钉钉、邮件）通知团队成员，某个功能已合并，可以更新代码进行联调。

三、 关键优势

● 历史清晰：主干分支的提交历史是线性的，每个功能只对应一个提交，易于追溯。
● 无冗余记录：不会产生 Merge branch ‘feature/xxx’ into develop 这样的合并提交，保持历史干净。
● 操作安全：–squash 模式将合并过程分解，开发者有充分的机会检查和确认所有变更。
● 易于回滚：如果合并后发现问题，可以通过一次 git revert 操作，轻松回滚整个功能。

四、 注意事项

● --squash 的代价：使用 --squash 后，功能分支的原始提交历史将丢失。因此，务必确保在合并前，功能分支的代码已经过充分的审查（Code Review）。
● 及时沟通：在合并大型或核心功能前，建议与团队负责人或相关开发者进行沟通。
● 自动化检查：理想情况下，合并操作应在 CI/CD 流水线中进行，自动执行代码检查、编译和测试，确保合并不会引入问题。