一、问题是什么

平时开发的时候，大家肯定有过这种情况：做了一个需求，提交了代码，结果组长评审的时候翻半天不知道这段代码对应哪个Jira任务，或者要调线上bug的代码，死活找不到对应的任务，导致评审没效率，需求进度也卡壳。这种Jira任务和提交代码的关联消失的情况，就是我们常说的关联断链，这次要解决的就是这个问题，重点说怎么在分支策略乱了之后，重新把提交和Jira任务绑回来。

二、先搞懂为什么会断链

很多人可能没注意，Jira和Git平台（比如Bitbucket）的关联，其实是靠一个小规则实现的：每一段提交的代码信息里，都会带对应Jira任务的唯一标识，也就是任务Key，比如PROJ-123，这个Key就像任务的身份证号，不会重复。Git平台或者Jira的插件，只要在提交信息里读到这个Key，就会自动把这段代码和对应的任务绑在一起。那为什么会断链呢？主要有两个原因：

2.1 提交没带任务Key

比如你做需求的时候，只想着改代码，忘了在提交信息里加上Jira的任务号，比如提交的时候写“修改登录按钮”，没写“feat: 修改登录按钮 #PROJ-123”，这样平台就找不到对应哪个任务了，自然就关联不上。

2.2 分支策略乱导致的对应关系错

还有一种情况是分支没有规范，比如有的同事建分支叫“我的分支”，提交的时候随手把任务号写错，比如把PROJ-123写成PROJ-12，或者把不同任务的提交混到一起，导致对应关系全乱了，就像你把张三的作业写到李四的本子上，老师批改的时候找不到对应学生。

三、怎么重建提交到任务的映射

既然知道了问题根源，那解决方法就围绕“补全任务Key，重新对应提交和任务”来，分步骤说，每个步骤都有具体操作，哪怕刚接触开发的同学也能看懂。

3.1 先定好分支和提交的规则（基础）

在修复之前，得先定一套大家都遵守的规则，避免后期再出问题，就像上课前先定好课堂纪律。规则很简单：分支命名要带任务Key，提交信息必须带任务Key。 举个例子，做PROJ-123的用户登录页功能，分支就叫feature/PROJ-123/用户登录页，提交信息就写成类似feat: 实现用户登录页的手机号输入框 #PROJ-123，这样只要看到分支名或者提交信息里的Key，就能快速找到对应任务，不会再乱。

3.2 单条提交补全任务Key

如果只有少数几次提交没带Key，不用大动干戈，直接修改提交信息就行，Git里有个工具叫rebase，就像编辑已经写好的提交记录，能帮我们改内容。 示例技术栈：Git

# 第一步：打开最近要修改的提交记录列表，比如要改最近3次提交，就输入这条命令
git rebase -i HEAD~3
# 输入后会弹出一个交互界面，把你要改的那行开头的pick改成edit，保存退出，Git就会停在那一次提交处
# 第二步：修改提交信息，把任务Key加上，比如原来的提交信息是“feat: 实现登录按钮”，改成带Key的
git commit --amend -m "feat: 实现登录按钮 #PROJ-123"
# 第三步：完成修改，让后续提交也正常生效
git rebase --continue

3.3 批量修复历史提交

如果有十几二十次提交都没带Key，一个个改太麻烦，就用批量处理的方法，写个简单的小脚本就行，不用懂复杂的编程，只要会复制粘贴改数字就行。 示例技术栈：Git

#!/bin/bash
# 批量修复最近5次提交，依次加上PROJ-121到PROJ-125的任务Key
commit总数=5
基础任务Key="PROJ-12"
# 循环处理每次提交，从最近的往远了改
for i in $(seq $commit总数 -1 1); do
  # 拿到第i次提交的唯一标识（hash）
  commit_hash=$(git rev-parse HEAD~$i)
  # 提取原来的提交内容，去掉多余的换行
  old_msg=$(git log --format=%B -n 1 $commit_hash | tr '\n' ' ')
  # 拼接新的提交内容，加上任务Key
  new_msg="$old_msg #${基础任务Key}$i"
  # 修改提交信息，不用重新写，直接用新的
  git commit --amend --no-edit -m "$new_msg"
done
# 完成后继续完成rebase操作
git rebase --continue

3.4 验证关联是否重建成功

改完提交后，一定要去Jira或者Git平台验证，比如打开Bitbucket里的提交列表，找到刚才改的那几次提交，点进去看，有没有关联到对应的Jira任务；或者打开Jira里的对应任务，看“代码”选项卡里面有没有显示这段提交的代码，这样就能确认关联成功了。

四、应用场景

这种方法最适合两种情况：一是团队刚开始用Jira和Git关联，之前没有任何规则，导致所有提交都没关联上，要一次性修复；二是迭代中期发现关联断链，需要紧急修复代码和任务的对应关系，不影响后续评审。比如某个线上bug，提交了修复代码，但对应任务找不到，影响bug的跟踪，这时候就可以用上面的批量修改方法快速修复。

五、技术优缺点

5.1 优点

最大的好处就是重新建立了提交和任务的对应关系，代码评审的时候，评审者点一下提交就能直接跳转到对应的Jira任务，不用再问“这段代码对应哪个需求”，节省大量时间；另外Jira里的任务进度能对应到具体的代码改动，方便团队跟踪需求完成情况。

5.2 缺点

修改Git的历史提交（就是上面的rebase操作），会改变提交的顺序和内容，如果有其他同事已经拉了旧的分支，再pull的时候会出现冲突，就像你改了自己的作业本，同学拿的是旧版本，合不上。所以修改的时候一定要注意，只在自己的个人分支上改，不要改主分支（比如main、master这种大家共用的分支）。

六、注意事项

  1. 改之前一定要备份分支，比如先切一个备份分支，万一改错了，还能回来；
  2. 绝对不要在主分支上改，比如线上用的主分支，一定要在自己的功能分支或者测试分支上操作；
  3. 修改完后，强制推送到自己的分支，比如用git push --force，然后告诉团队里的同事，不要pull旧分支，要把旧分支删掉，重新拉取最新的；
  4. 任务Key一定要和Jira里的完全一致，包括大小写，比如Jira里的任务是PROJ-123，不能写成proj-123，不然关联不上，就像你填身份证号少了数字，查不到人。

七、文章总结

Jira任务和代码提交的关联，核心就是“规则”，只要提交的时候带对任务Key，分支命名有规范，就不会出现断链的情况。如果之前已经断链了，也不用慌，用上面说的修改提交信息的方法，单条或者批量修复，就能重新建立映射。最重要的是，团队要统一遵守规则，从每次提交开始就带任务Key，避免后期花大量时间修复，这样代码评审和任务跟踪都会顺畅很多，团队效率也会提高。