创建feature分支并保持与mainline同步的方法及最佳实践

1. 创建feature-redesign分支的具体步骤&命令 #

先确保本地mainline分支是最新状态，再创建新分支：

• 切换到mainline分支：

  git checkout mainline
  

• 拉取远程mainline的最新代码，避免基于旧版本创建分支：

  git pull origin mainline
  

• 创建并切换到feature-redesign分支：

  git checkout -b feature-redesign
  

• 将新分支推送到远程仓库，让团队成员可见：

  git push -u origin feature-redesign
  

（-u参数会关联本地分支和远程分支，后续推送直接用git push即可）

2. 保持feature-redesign与mainline同步 #

有两种常用方式，根据团队协作习惯选择：

方式一：合并mainline更新（适合公开协作的分支） #

• 切换到feature-redesign分支：

  git checkout feature-redesign
  

• 拉取远程mainline的最新代码并合并到当前分支：

  git pull origin mainline
  

• 如果出现冲突，手动修改冲突文件，标记冲突已解决：

  git add <冲突文件名>
  

• 提交合并结果：

  git commit -m "Merge mainline into feature-redesign"
  

• 推送到远程分支：

  git push
  

方式二：变基到mainline（适合个人开发或小团队，历史更整洁） #

• 切换到feature-redesign分支：

  git checkout feature-redesign
  

• 将当前分支的提交重新基于最新的mainline：

  git rebase origin/mainline
  

• 若出现冲突，解决后执行：

  git add <冲突文件名>
  git rebase --continue
  

  （如果要放弃变基，执行git rebase --abort）
• 变基后需要强制推送到远程（注意：仅当分支只有你在开发时使用，避免覆盖他人提交）：

  git push -f origin feature-redesign
  

3. 大型项目的最佳实践&分支命名建议 #

最佳实践 #

• 保持分支粒度小：一个分支只对应一个功能或修复，避免分支过大导致合并困难、冲突频发
• 频繁同步mainline：建议每天至少同步一次，减少后期合并的冲突量级
• 分支生命周期短：功能开发完成并合并后，及时删除本地和远程的feature分支，避免分支泛滥
• 提交规范：每个提交对应一个小的功能点，提交信息清晰（比如fix: 修复用户头像上传失败问题）
• 合并前自检：在发起PR（Pull Request）前，本地运行测试用例，确保功能正常、无语法错误
• 强制代码评审：通过PR邀请团队成员评审代码，避免潜在问题流入主分支

分支命名建议 #

用统一的前缀+描述性名称，方便识别分支用途：

• 功能分支：feature/开头，比如feature/user-profile-redesign、feature/checkout-flow-optimize
• 修复分支：bugfix/开头，比如bugfix/login-validation-error、bugfix/PROJ-456-payment-failure（可关联项目管理工具的任务编号）
• 紧急修复分支：hotfix/开头，比如hotfix/production-crash-fix
• 通用规则：全部小写，用连字符-分隔单词，避免特殊字符、空格，名称简洁明了

内容的提问来源于stack exchange，提问作者Emma Earl Kent