对于大多数中小团队，从简单的功能分支模型开始最稳妥，个人项目或快速迭代场景直接用主分支配合特性分支即可，不必一开始就套用复杂流程。

核心工作流与命令更新

Git 2.23 版本后引入了更语义化的命令，建议在新项目中优先使用 git switch 替代 git checkout 进行分支切换，以减少误操作风险。

# 查看分支列表
git branch
# 创建并切换新分支（推荐）
git switch -c <branch-name>
# 合并分支到当前分支
git merge <branch-name>
# 删除本地分支
git branch -d <branch-name>

实际操作流程如下：

1. 确认状态：执行 git status 确保工作区干净，如有未提交更改先暂存或提交。
2. 创建特性分支：基于主分支创建新分支，命令 git switch -c feature/login，命名建议带前缀区分用途。
3. 开发并提交：在分支上正常编写代码并提交，保持提交信息清晰。
4. 合并回主分支：切换回主分支 git switch main，执行 git merge feature/login。
5. 清理分支：合并确认后，删除旧分支 git branch -d feature/login，避免仓库分支过多。

远程协作规范

多人协作时，本地分支与远程分支的关联至关重要。新手常因未指定上游分支导致推送失败或推错位置。

推送与关联：首次推送新分支时，务必使用 -u 参数建立上游追踪。

git push -u origin <branch-name>

拉取更新：在合并前，建议先拉取远程最新代码以减少冲突。为避免产生多余的 merge commit，可配置默认使用变基拉取。

# 临时使用变基拉取
git pull `--rebase` origin <branch-name>
# 或全局配置
git config `--global` pull.rebase true

合并冲突解决实战

当多人修改同一文件的同一行时会产生冲突，Git 会暂停合并过程等待人工解决。

1. 定位冲突：执行 git status 查看显示为 both modified 的文件。
2. 编辑文件：打开冲突文件，查找 <<<<<<<、======= 和 >>>>>>> 标记，保留需要的代码，删除标记符号。
3. 标记解决：文件修改完成后，执行 git add <file-name> 标记冲突已解决。
4. 完成合并：执行 git commit 完成合并提交（若使用 merge 命令，Git 通常会自动生成合并提交信息）。

合并策略选择：Merge 还是 Rebase

选择哪种策略取决于分支的可见性和团队规范。

• 使用 Merge：适用于公共分支（如 main、develop）或需要保留完整历史记录的场景。它会产生一个合并提交节点，清晰反映分支集成点。
• 使用 Rebase：适用于本地特性分支整理提交历史。它会将当前分支的提交“移植”到目标分支顶端，保持历史线性整洁，但严禁对已推送到公共仓库的分支使用变基。

# 变基当前分支到 main
git rebase main

验证与清理

操作完成后，需确认分支状态是否符合预期。

• 查看历史图谱：使用 git log `--graph` `--oneline` `--all` 查看提交历史，确认合并点或变基点是否正确。
• 确认当前分支：检查 git branch 输出，当前分支前应有星号 * 标记。
• 远程同步：执行 git push 后查看远程仓库界面分支列表是否更新。若远程分支已废弃，使用 git push origin `--delete` <branch-name> 清理远程分支。

高频风险与排查

• 在错误分支提交：提交前务必用 git branch 确认当前分支。误提交可用 git reset `--soft` HEAD~1 撤销提交保留更改，切换分支后重新提交。
• 强制推送风险：除非明确知道后果，避免对公共分支使用 git push -f，这会覆盖他人提交导致代码丢失。
• 分支遗留：长期不删除已合并分支会导致仓库杂乱，建议合并后及时清理本地和远程分支。
• 脱离头指针：避免直接在 Commit ID 上工作（Detached HEAD），否则提交可能丢失。如需尝试请用临时分支 git switch -c temp-fix。

参考来源

• Git Official Documentation - Git Branching Basics: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
• Pro Git Book - Branching Workflows: https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows