人人都会AI编程

Git 常见工作流命令模板与冲突解决指南

更新时间：2026-07-11

<span style="font-family:inherit;font-size:16px;font-weight:400;">以下模板均为企业级开发通用标准，可直接套用执行，覆盖日常 90% 以上的协作场景。</span>

一、Feature 分支开发工作流（GitHub Flow 轻量版）

适用场景：中小团队、持续交付模式、单主干迭代，是目前最主流的轻量协作工作流。
核心规则：main/master 为唯一生产主干，所有功能开发都在独立 feature 分支完成，通过 PR/MR 评审后合并回主干。

完整执行步骤

1. 基于主干创建功能分支

# 切换到主干并拉取最新代码，保证分支基于最新版本
git checkout main
git pull origin main

# 创建功能分支，命名规范：feature/需求ID-功能描述
git checkout -b feature/123-user-login

2. 日常开发与提交

# 编码后提交，建议遵循 Conventional Commits 规范
git add .
git commit -m "feat: 完成用户登录接口与参数校验"

# 开发过程中可多次小步提交
git commit -m "fix: 修复登录验证码过期逻辑"

3. 定期同步主干代码（关键步骤，减少最终冲突）

开发周期超过 1 天时，建议每天同步一次主干更新：

# 暂存本地未提交的半成品代码
git stash

# 切换主干拉取最新内容
git checkout main
git pull origin main

# 切回功能分支，用变基方式同步，保持提交历史线性整洁
git checkout feature/123-user-login
git rebase main

# 恢复之前暂存的半成品代码
git stash pop

4. 开发完成，推送并发起合并

# 最终同步一次主干后推送到远程
git push origin feature/123-user-login

推送后在代码托管平台（GitHub/GitLab/Gitee）发起 Pull Request / Merge Request，指定合并目标为 main 分支，等待代码评审。

5. 合并通过后收尾清理

# 切换回主干，拉取合并后的最新代码
git checkout main
git pull origin main

# 删除本地已完成的功能分支
git branch -d feature/123-user-login

# 清理远程已删除的分支引用（可选）
git fetch -p

二、标准 Git Flow 工作流

适用场景：中大型团队、版本发布周期明确、需要同时维护多版本的项目。
核心分支体系：

  • 长期分支：master（生产环境）、develop（开发集成分支）
  • 临时分支：feature/（功能开发）、release/（版本发布）、hotfix/*（线上热修复）

1. 功能开发流程（Feature）

起点：develop 分支 | 终点：合并回 develop 分支

# 1. 从 develop 创建功能分支
git checkout develop
git pull origin develop
git checkout -b feature/订单管理模块

# 2. 开发并提交代码
git commit -m "feat: 订单列表查询接口开发"

# 3. 同步 develop 最新代码
git pull --rebase origin develop

# 4. 推送远程，发起 MR 合并到 develop
git push origin feature/订单管理模块

# 5. 评审通过合并后，本地清理
git checkout develop
git pull origin develop
git branch -d feature/订单管理模块

2. 版本发布流程（Release）

起点：develop 分支 | 终点：同时合并到 master 和 develop，并打版本标签

# 1. 从 develop 创建发布分支，命名：release/版本号
git checkout develop
git checkout -b release/v1.2.0

# 2. 发布前收尾（修改版本号、修复小bug）
git commit -m "chore: 更新版本号为 v1.2.0"
git push origin release/v1.2.0

# 3. 测试通过后，合并到 master 并打标签
git checkout master
git merge --no-ff release/v1.2.0 -m "merge: 发布 v1.2.0 正式版本"
git push origin master
git tag -a v1.2.0 -m "Release v1.2.0 正式版"
git push origin v1.2.0

# 4. 同步合并回 develop，保证开发分支包含发布时的修复
git checkout develop
git merge --no-ff release/v1.2.0 -m "merge: 同步 v1.2.0 发布修改到开发分支"
git push origin develop

# 5. 删除发布分支
git branch -d release/v1.2.0
git push origin --delete release/v1.2.0

3. 线上热修复流程（Hotfix）

起点：master 分支 | 终点：同时合并到 master 和 develop，并打补丁标签

# 1. 从 master 创建热修复分支
git checkout master
git checkout -b hotfix/修复支付回调异常

# 2. 修复问题并提交
git commit -m "fix: 修复支付回调签名校验失败问题"
git push origin hotfix/修复支付回调异常

# 3. 验证通过后合并到 master
git checkout master
git merge --no-ff hotfix/修复支付回调异常 -m "merge: 修复线上支付回调异常"
git push origin master
git tag -a v1.2.1 -m "Release v1.2.1 热修复补丁"
git push origin v1.2.1

# 4. 同步修复内容到 develop
git checkout develop
git merge --no-ff hotfix/修复支付回调异常 -m "merge: 同步线上热修复到开发分支"
git push origin develop

# 5. 删除热修复分支
git branch -d hotfix/修复支付回调异常
git push origin --delete hotfix/修复支付回调异常

三、代码冲突完整解决步骤

冲突本质：多人修改了同一文件的同一行/同一块区域，Git 无法自动判定保留哪份代码，需要人工介入。

冲突标记说明

冲突文件中会出现三段标记，含义如下：

<<<<<<< HEAD    // 分割线以上：当前分支你的代码
你的代码内容
=======         // 中间分隔线
对方分支的代码
>>>>>>> 目标分支名 // 分割线以下：要合并/变基的分支代码

1. Merge 合并场景冲突处理

# 1. 合并触发冲突后，先查看所有冲突文件
git status
# 标注为 both modified 的文件即为冲突文件

# 2. 逐个打开冲突文件，手动编辑保留正确代码，删除所有冲突标记符号

# 3. 全部修改完成后，标记文件为已解决
git add <冲突文件1> <冲突文件2>

# 4. 完成合并流程
git merge --continue

# --- 应急回退 ---
# 不想解决了，放弃本次合并，恢复到合并前状态
git merge --abort

2. Rebase 变基场景冲突处理

Rebase 是逐个提交应用，可能出现多次冲突，需逐次处理：

# 1. 变基触发冲突后，查看冲突文件
git status

# 2. 手动修改冲突文件，删除标记保留正确代码

# 3. 标记当前提交的冲突已解决
git add <冲突文件>

# 4. 继续执行变基（后续可能还有冲突，重复上述步骤）
git rebase --continue

# --- 应急操作 ---
# 完全放弃本次变基，恢复到变基前状态
git rebase --abort

# 跳过当前有冲突的提交（慎用，会丢弃该提交的改动）
git rebase --skip

冲突解决实用技巧

  • 工具辅助：配置可视化工具一键解决，例如 VS Code：
  git config --global merge.tool code
  git config --global mergetool.code.cmd "code --wait --merge \$LOCAL \$BASE \$REMOTE \$MERGED"
  # 触发冲突后执行，即可唤起可视化对比界面
  git mergetool
  • 预防优先：每天同步主干代码、小步高频提交，可大幅降低冲突概率
  • 分工前置：同一模块尽量避免多人并行修改，提前沟通职责边界

四、高频应急操作模板

1. 线上版本紧急回滚

安全方案（推荐，不修改历史）：

# 找到出错的提交哈希
git log --oneline
# 生成反向提交抵消错误改动
git revert <出错的提交哈希>
git push origin master

强制回退方案（慎用，仅确认无后续提交时使用）：

git reset --hard <目标安全提交哈希>
git push --force origin master

2. 撤销一次已合并的错误合并

# 查看操作记录，找到合并前的提交ID
git reflog
# 回退到合并前的状态
git reset --hard <合并前的commit-id>

3. 代码写一半被打断，需临时切换分支

# 暂存当前未完成的工作
git stash save "半成品：商品详情页开发"

# 切换去处理紧急问题...

# 处理完回到原分支，恢复工作内容
git stash pop