Git 开启新功能开发的流程需遵循分支管理规范（如 Git Flow、GitHub Flow），核心是隔离功能开发代码、避免影响主分支稳定性，同时兼顾协作效率。以下是通用且规范的流程（适配绝大多数团队场景），包含从分支创建到功能开发中关键操作的完整步骤：
一、前置准备：确保本地环境干净且最新
开始新功能前，先同步远程主分支代码，并清理本地未提交的变更，避免冲突：
# 1. 切换到主分支（通常是 main/master，稳定分支）
git checkout main
# 2. 拉取远程主分支最新代码（确保本地与远程同步）
git pull origin main
# 3. 检查本地是否有未提交的变更（可选但推荐）
git status
# - 若有未提交变更：
# - 需保留：git stash 暂存，开发完成后用 git stash pop 恢复
# - 无需保留：git checkout -- . 放弃所有本地修改（谨慎）
二、创建功能分支（核心步骤）
功能分支命名需规范（便于识别用途），推荐格式：feature/功能名称-版本/编号（如 feature/chat-api-v2、feature/user-login-optimize）：
# 创建并切换到新功能分支（-b = branch + checkout）
git checkout -b feature/chat-api-updates
# 验证分支是否创建成功
git branch # 会看到当前分支为 feature/chat-api-updates
分支命名规范建议：
前缀统一：
feature/（功能开发）、bugfix/（bug修复）、hotfix/（紧急修复）；名称清晰：包含功能关键词（如
pay、login），避免无意义的数字/字母；团队统一：比如结合需求编号（
feature/REQ-1234-user-profile）。
三、功能开发：高频操作（提交、暂存、同步）
开发过程中需规范提交，及时同步远程分支，避免后期冲突：
1. 常规开发与提交
# 1. 开发完成后，查看变更文件
git status
# 2. 暂存变更（按需选择，推荐精准暂存而非 git add .）
git add src/chat/api.js # 暂存单个文件
git add src/chat/ # 暂存整个文件夹
# 如需取消暂存：git reset HEAD src/chat/api.js
# 3. 提交变更（提交信息需清晰，遵循规范）
git commit -m "feat(chat): 新增聊天接口参数校验"
# 提交信息规范（示例）：
# - feat：新功能 | fix：修复bug | docs：文档 | style：格式 | refactor：重构 | test：测试 | chore：构建/工具
# - 格式：<类型>(<模块>): 描述（简洁，不超过50字）
2. 临时保存工作进度（未完成开发需切换分支时）
# 暂存当前未提交的修改（不会提交，仅临时保存）
git stash
# 切换回主分支处理其他事，处理完后切回功能分支，恢复暂存：
git stash pop # 恢复最近一次暂存，并删除暂存记录
# 或 git stash apply # 恢复暂存，保留暂存记录（可多次恢复）
3. 同步远程功能分支（多人协作同一功能时）
# 1. 首次推送功能分支到远程（创建远程分支）
git push -u origin feature/chat-api-updates
# -u：关联本地分支与远程分支，后续只需 git push 即可
# 2. 后续开发中，定期拉取远程功能分支的最新代码（避免与协作方冲突）
git pull origin feature/chat-api-updates
4. 解决冲突（拉取/合并时出现冲突）
# 1. 拉取代码后提示冲突，先查看冲突文件
git status # 标记为 "both modified" 的文件即冲突文件
# 2. 打开冲突文件，手动解决冲突（查找 <<<<<<< HEAD 标记）
# - <<<<<<< HEAD：本地代码
# - =======：分隔符
# - >>>>>>> feature/xxx：远程代码
# 保留正确代码，删除冲突标记后保存文件
# 3. 解决后，暂存冲突文件并提交
git add 冲突文件路径
git commit -m "fix(chat): 解决接口参数校验逻辑冲突"
四、功能开发完成：提测/合并前准备
1. 最终同步主分支代码（避免合并时冲突）
# 1. 切回主分支并拉取最新代码
git checkout main
git pull origin main
# 2. 切回功能分支，合并主分支最新代码（将主分支的更新同步到功能分支）
git checkout feature/chat-api-updates
git merge main
# 若合并时出现冲突，按上述“解决冲突”步骤处理
2. （可选）压缩提交记录（保持分支提交历史整洁）
如果功能开发过程中提交记录杂乱，可合并为少量清晰的提交：
# 合并最近N次提交（如合并最近5次，执行 git rebase -i HEAD~5）
git rebase -i HEAD~5
# 进入编辑界面，将除第一个提交外的 pick 改为 squash（合并），保存退出
# 编辑合并后的提交信息，完成后保存
五、功能验收：合并到主分支（或提MR/PR）
1. 团队协作场景：提合并请求（MR/PR）
主流代码托管平台（GitLab/GitHub/Gitee）推荐通过 Merge Request (MR) / Pull Request (PR) 合并，流程：
推送功能分支到远程：
git push origin feature/chat-api-updates；在平台上新建 MR/PR，目标分支选择
main，源分支选择feature/chat-api-updates；填写MR/PR描述（功能内容、测试要点、关联需求等），指定审核人；
审核通过后，执行合并（可选“合并后删除功能分支”）。
2. 本地直接合并（小型项目/个人开发）
# 1. 切回主分支
git checkout main
# 2. 合并功能分支到主分支
git merge feature/chat-api-updates --no-ff
# --no-ff：保留功能分支的提交历史（便于回溯，推荐添加）
# 3. 推送主分支到远程
git push origin main
# 4. （可选）删除本地/远程功能分支（功能已合并，无需保留）
git branch -d feature/chat-api-updates # 删除本地分支
git push origin --delete feature/chat-api-updates # 删除远程分支
六、特殊场景：功能开发中断/废弃
如果功能开发到一半需要暂停，或确认废弃：
# 1. 推送分支到远程备份（避免本地丢失）
git push origin feature/chat-api-updates
# 2. 废弃分支（可选）：
# - 本地保留：仅切回主分支即可；
# - 标记废弃：在分支名后加 -deprecated（如 feature/chat-api-updates-deprecated）；
# - 彻底删除：按上述“删除分支”步骤操作。
核心规范总结
分支隔离：功能开发必须在独立分支，禁止直接在主分支开发；
提交规范：提交信息清晰（类型+模块+描述），避免无意义的“update”；
及时同步：定期拉取主分支/协作方的功能分支代码，减少冲突；
合并审核：多人协作时，必须通过MR/PR审核后再合并，避免直接推主分支；
分支清理：功能合并后及时删除废弃分支，保持分支列表整洁。
该流程适配 Git Flow 核心思想（主分支稳定、功能分支隔离），同时兼容轻量化的 GitHub Flow，可根据团队规模（单人/多人）、项目复杂度调整（如小型项目可省略“压缩提交”“--no-ff”等步骤）。
使用 git rebase（变基）替代 git merge 将 feature/chat-api-updates 整合到 main 分支，核心优势是让提交历史更线性、整洁（无合并提交节点），适合追求干净提交记录的场景。以下是完整的操作步骤、原理说明和注意事项：
核心逻辑
git rebase 会将 feature/chat-api-updates 分支的所有提交，“重放”到 main 分支的最新提交之后，最终 main 分支的提交历史是一条直线（而非 merge 产生的分叉）。
操作步骤（推荐：先在功能分支变基，再合并到main）
步骤1：前置准备（确保 main 分支最新）
# 1. 切换到 main 分支
git checkout main
# 2. 拉取远程 main 最新代码（同步团队修改）
git pull origin main
# 3. 切回功能分支
git checkout feature/chat-api-updates
步骤2：将功能分支变基到 main 最新版本（核心）
# 把 feature/chat-api-updates 基于 main 最新提交重新构建
git rebase main
此时 Git 会先“暂存”功能分支的所有提交，然后切换到
main最新提交，再逐个“重放”功能分支的提交；若出现冲突：Git 会中断变基，提示
Resolve conflicts and then run "git rebase --continue"，解决冲突步骤如下：# 1. 查看冲突文件 git status # 2. 打开冲突文件，删除 <<<<<<<、=======、>>>>>>> 标记，保留正确代码并保存 # 3. 暂存解决后的冲突文件 git add 冲突文件路径 # 4. 继续执行变基（完成剩余提交的重放） git rebase --continue # （可选）若想放弃变基，执行：git rebase --abort
步骤3：切换到 main 分支，快速合并功能分支
变基后，feature/chat-api-updates 的提交已经基于 main 最新版本，此时合并是“快进（fast-forward）”模式，无额外合并提交：
# 1. 切回 main 分支
git checkout main
# 2. 快进合并功能分支（此时 main 直接指向 feature 分支的最新提交）
git merge feature/chat-api-updates
# 3. 推送更新后的 main 到远程
git push origin main
步骤4：（可选）清理功能分支
# 删除本地功能分支
git branch -d feature/chat-api-updates
# 删除远程功能分支（团队确认无需保留）
git push origin --delete feature/chat-api-updates
直接在 main 分支 rebase 功能分支（不推荐，仅作参考）
也可直接在 main 分支执行 rebase，但风险更高（易污染主分支），仅适合单人开发：
# 1. 确保在 main 分支且已拉取最新代码
git checkout main
git pull origin main
# 2. 直接将 main 分支变基到功能分支（等价于“吸收”功能分支的提交）
git rebase feature/chat-api-updates
# 3. 推送（若变基后 main 提交历史改变，需强制推送，谨慎！）
git push origin main --force-with-lease
# --force-with-lease：比直接 --force 安全，仅当远程 main 无他人修改时强制推送
关键注意事项
禁止对公共分支（如 main）执行变基：如果
main分支已推送到远程，且有其他团队成员基于该分支开发，变基会改写提交历史，导致他人代码冲突（这是 rebase 最核心的禁忌）；✅ 正确用法：仅对本地私有分支（如 feature/xxx）执行
rebase main，再合并到 main；❌ 错误用法：直接对远程已共享的 main 分支变基。
变基冲突 vs 合并冲突：
merge 仅需解决一次冲突（合并时）；
rebase 可能需多次解决冲突（功能分支有 N 个提交，每个提交都可能冲突）；
回滚难度更高：变基改写了提交历史，若合并后发现问题，回滚比 merge 更复杂（需用
git reflog找回旧提交）；多人协作功能分支：如果
feature/chat-api-updates已推送到远程且多人协作，也禁止对其变基（会导致他人的提交记录混乱）。
rebase 与 merge 对比（选择建议）
总结：用 rebase 整合功能分支到 main 的核心流程是「功能分支 rebase main → main 快进合并功能分支」，既保证了 main 分支历史整洁，又规避了直接修改公共分支的风险。