1. 项目概述与实战场景：为什么Java开发绕不开Git回退和origin联动
做Java开发这么多年，Git几乎是每天都要打交道的工具。但说实话，绝大多数人只是停留在git add、git commit、git push三板斧的阶段，一旦遇到代码回退、远程分支同步、复杂分支合并这类稍微进阶的场景，就容易手忙脚乱。尤其是一些从SVN转过来的老Java开发，思维还停留在"集中式版本控制"的模式里，对Git的分布式模型理解不够透彻，出了问题第一反应就是"删了重新克隆"。
这篇文章我打算完整梳理Java开发中最常遇到的Git问题，重点讲三个核心主题：代码回退的多种姿势与适用场景、origin远程仓库的联动操作、以及复杂分支问题的处理思路。这三个主题看似独立，实际上在真实开发中是纠缠在一起的——比如你回退了本地代码准备强制推送，但远程分支已经被别人更新了，这个时候怎么处理？比如你基于master拉了一个特性分支开发了两天，结果master已经跑得很远了，怎么把新代码合进来又不搞乱自己的改动？
先说说这个内容的受众。如果你是一个刚入行的Java开发，平时主要用IDE自带的Git插件点按钮操作，遇到冲突就找同事帮忙，那你在这篇文章里能补上底层原理；如果你已经有两三年经验，想系统梳理一下Git的进阶操作，这篇文章同样有价值——我会把我这几年踩过的坑、试过的最优解、以及一些官方文档里不会写明白的细节全部拿出来分享。
关于环境，我后面演示的命令在Git 2.x以上版本都能跑通，IDE方面我会提到IntelliJ IDEA和VS Code里对应的界面操作，方便习惯图形界面的人对照学习。操作系统的话，Windows、macOS、Linux的命令都一样，只是路径写法略有差异，不影响核心逻辑。
2. 代码回退的底层原理：git reset三种模式和解开HEAD、暂存区、工作目录的关系
要讲清楚代码回退，必须先理解Git的三个核心区域：工作目录（Working Directory）、暂存区（Index/Staging Area）、以及版本库（Repository/HEAD指向的提交历史）。很多Java开发搞不明白为什么git reset有好几种参数，本质上就是在控制这三个区域之间的同步关系。
2.1 工作目录、暂存区、HEAD之间的关系图解
我尽量用大白话来讲。工作目录就是你电脑上看到的那些Java源文件；暂存区是个中间缓冲区，你执行git add之后文件就进入这里；HEAD则是指向当前分支最新提交的指针。一次完整的提交流程是：工作目录修改文件 →git add把改动放进暂存区 →git commit把暂存区内容固化成一个新的提交，同时HEAD向前移动。
回退操作的本质，就是让HEAD这个指针往回移动，然后决定要不要同步更新暂存区和工作目录。git reset的三个参数就是来控制这个同步范围的：
git reset --soft：只移动HEAD指针，暂存区和工作目录都不动。也就是说你的改动还在暂存区里，随时可以重新提交。git reset --mixed（默认模式）：移动HEAD，同时把暂存区重置到和HEAD一致，但工作目录不动。这意味着你已经git add的改动会被"打回原形"，变成未暂存状态，但文件内容还在。git reset --hard：移动HEAD，同时把暂存区和工作目录都重置到和HEAD一致。这个最暴力，工作目录里所有未提交的改动都会丢失。
看到区别了吗？--soft最温柔，适合"提交错了但还想保留改动"的场景；--mixed是默认行为，适合"撤销add操作"的场景；--hard最危险，适合"彻底不要这些改动了"的场景。我在实际开发中用的频率排序是：--mixed最多（因为经常想撤销add）、--soft偶尔用（提交信息写错了想重新提交）、--hard最少用（除非确定改动完全没用）。
2.2 Java项目中最常用的回退方案：soft、mixed、hard怎么选
场景一：你刚提交了一个commit，结果发现提交信息写错了，或者忘提交了某个文件。这个时候用git reset --soft HEAD~1，然后重新git add、git commit。--soft的好处是不会动你暂存区里的东西，也不会动工作目录，改完直接重新提交就行。
场景二：你git add了一些不该加的文件（比如target目录、IDE配置文件），想把这些文件从暂存区撤回来。用git reset --mixed HEAD <文件路径>或者更精确的git rm --cached <文件路径>。--mixed不会动工作目录里的文件，只是把它们从暂存区移除，对Java项目来说这个操作特别实用，因为经常会有编译产物被误加入版本控制。
场景三：你改了半天的代码发现思路完全错了，想直接回到某个历史提交的状态。用git reset --hard <commit-hash>。注意，这个操作会把你工作目录里所有未提交的改动全部删除，而且不可恢复（除非你提前用git stash保存过）。所以我给自己定了个原则：--hard之前必须先git stash或者把工作目录的改动备份一下。另外，如果你的Java项目里有未提交的数据库脚本、配置文件等关键内容，--hard前更要反复确认，这种低级错误我犯过一次，后来再也不敢不做备份就操作了。
场景四：你不想彻底删除历史提交，只是想"撤销"某一次提交造成的影响，同时保留这次提交的记录。那应该用git revert而不是git reset。revert会生成一个新的提交，这个提交的内容是"逆向操作"目标提交，相当于把那次改动反向执行了一遍。这个操作在团队协作里特别重要，因为它不会改写历史，后续push的时候也无需强制推送。
注意：
git revert不是简单的"回到过去"，而是"在当前状态上反向执行"。所以如果目标提交之后又有人改了相同位置的文件，revert可能产生冲突，需要手动解决。
2.3 git revert与git reset的本质区别：什么时候用哪个
这两个命令是很多Java开发最容易混淆的。我打个比方：reset是时光机，直接跳回过去，历史记录里中间的过程全部消失；revert是时光倒流但保留日记，你在日记里记了一笔"我撤销了那次改动"，之前的记录都还在。
团队开发中，最忌讳的就是用reset --hard去回退已经推送到远程的分支。因为这会改写历史，其他同事拉取代码时会遇到git pull报错，提示"您的本地分支与远程分支分叉"，必须用git pull --rebase或者强制重置才能解决。而revert因为是新增提交，不会改写历史，其他人正常git pull就同步了。
那什么场景用reset，什么场景用revert？我的经验是：提交还没推送到远程，随便用reset，哪怕--hard也无所谓（反正只有本地）；一旦提交已经推送到远程，优先用revert。除非你自己就是仓库的唯一开发者，或者团队只有你一个人用这个分支，否则不要用reset去回退远程分支。
还有个细节：git revert支持一次撤销多个提交，但要注意顺序。比如git revert A B C会按顺序生成三个回退提交，如果其中两个提交改动了相同文件可能产生冲突。更安全的做法是从新到旧逐个revert：git revert HEAD~2..HEAD。
3. origin背后的远程仓库联动：从remote add到push、fetch、pull的完整链路
origin可以说是每个Git仓库都会用到的默认远程仓库名。但我发现很多Java开发其实并不清楚origin到底是什么，以及本地分支和远程分支的关联关系是怎么建立的。理解这些，才能正确处理"代码推不上去"、"拉取下来一堆冲突"这类问题。
3.1 远程分支版本库的创建与关联：从克隆到remote add
当你执行git clone <url>的时候，Git会自动把远程仓库命名为origin，并且把远程分支全部拉下来。但如果你在本地用git init新建了一个仓库，然后想关联到远程空仓库，就需要手动添加：
git remote add origin <repository-url>这里有个关键问题：repository-url可以是本地目录吗？答案是可以。Git支持本地文件系统路径作为远程仓库，这在单机开发、学习测试、或者局域网内U盘同步代码时非常实用。比如：
git remote add origin /path/to/bare-repo.git git remote add origin ../shared/project.git不过要注意的是，如果使用本地路径作为远程仓库，路径必须指向一个裸仓库（用git init --bare创建的仓库），或者一个正常的Git仓库。如果是普通仓库，Git会提示"remote HEAD refers to nonexistent ref"，虽然能用但不够规范。
对Java开发来说，最常见的remote add场景有两种。第一种：公司自建GitLab或者Gitea，管理员创建好空项目后给你一个HTTPS或者SSH地址，你在本地git init之后用git remote add origin <url>关联。第二种：自己本地建了一个裸仓库作为"中央仓库"，然后用git remote add origin /path/to/repo.git关联。我个人的建议是，多人协作一定要用GitLab这类服务端，不要用本地路径共享，因为本地路径方案没有权限控制，也不方便做CI/CD集成。
添加完远程仓库后，可以通过git remote -v查看当前配置了哪些远程仓库，以及对应的fetch和push地址。要删除错误关联的远程仓库用git remote remove origin，改地址用git remote set-url origin <new-url>。
3.2 push和fetch的完整链路讲解：远程跟踪分支与本地分支的关系
很多Java开发对远程分支和本地分支的关系是模糊的。我用一个例子来说明。假设你执行git clone之后，在本地看到了一个叫master的分支，但实际上这个master是一个本地跟踪分支，它关联着远程的origin/master。这个关联关系是Git自动建立的。
当你执行git push origin master的时候，Git会把本地master分支推送到远程的master分支，同时更新本地的远程跟踪分支origin/master（这个分支是只读的，你看到的refs/remotes/origin/master就是它）。当你执行git fetch origin的时候，Git会从远程拉取最新的提交信息，但不会自动合并到你的工作分支，它只更新origin/master这个远程跟踪分支。
很多人在理解fetch和pull的区别时卡住了。git pull实际上是git fetch+git merge的组合命令，默认把origin/master合并到当前分支。对于Java开发来说，我特别推荐优先使用git fetch+git merge或git rebase，而不是直接git pull，因为你控制不了pull内部执行的是merge还是rebase，容易产生一堆无意义的合并提交。在IDEA里，git pull按钮默认也是fetch后merge，反而会让分支历史变得很乱。
我自己的习惯是这样的：看到git pull提醒，先执行git fetch看远程改了什么，如果远程只是小改动（比如同事加了个方法签名），我就直接git merge；如果远程和本地改动重叠比较大，我会选择git rebase把本地提交"搬到"远程最新代码之上，保持线性历史。关于rebase和merge的取舍，后面专门用一个小节讲。
3.3 本地分支与远程分支的关联和解除：配置upstream的细节
本地分支和远程分支的关联关系，术语上叫"upstream"（上游分支）。当你执行git push -u origin feature-login时，-u参数的作用就是为本地feature-login分支设置上游为origin/feature-login。设置之后，以后直接执行git push和git pull就不用再输入远程仓库名和分支名了。
查看当前分支的上游关系用git branch -vv，输出里会显示类似[origin/feature-login]的信息。如果某个本地分支没有上游分支，git push时会报错提示你要用--set-upstream来设置。还有一种情况：本地分支的上游是一个已经不存在的远程分支（远程分支被删了），git branch -vv会显示[origin/old-branch: gone]，这个时候需要手动解除关联。
解除关联用git branch --unset-upstream <分支名>，或者直接删除本地分支。对于Java开发来说，最常见的上游问题出现在切换分支的时候。比如你在IDEA里切到一个新分支时，如果IDE提示"Set upstream"还是"Push"之类的选项，建议选择push并勾选set upstream，这样后续提交推送就不用每次都指定远程分支了。
提示：如果你发现
git push报错"fatal: The current branch has no upstream branch"，先检查一下你是基于哪个分支创建的新分支。用git branch -vv看当前分支的上游设置，然后根据实际需要git push -u origin <分支名>即可。
3.4 删除远程分支与本地残留分支的处理
分支删不干净是Java开发中特别常见的问题。本地删除分支用git branch -d <分支名>（安全的删除，会检查是否还有未合并的提交）或git branch -D <分支名>（强制删除，不管是否已合并）。但很多人删了本地分支之后，发现远程分支还在，或者远程分支删了但本地还残留着origin/xxx这样的远程跟踪分支。
删除远程分支的正确命令是：
git push origin --delete <分支名>或者等价的：
git push origin :<分支名>很多教程只写了第一种，我把第二种也放出来，因为有时候你在看别人写的脚本时会遇到冒号这种写法。命令的意义是推送一个空的源分支到远程，远程那边就删掉了。
远程分支删掉之后，本地的远程跟踪分支origin/xxx并不会自动删除。你需要执行：
git fetch --prune这个命令会清理本地已经失效的远程跟踪分支。在IDEA里对应的是Fetch按钮旁边的小箭头下拉菜单里的Prune，在VS Code里对应的是Git面板右上角刷新按钮的Fetch (Prune)选项。我每次删完远程分支都会习惯性地执行一次git fetch --prune，防止时间长了积累一堆"幽灵分支"。
4. 复杂分支管理实操：用master覆盖、特性分支同步、冲突解决与代码回退的联动
分支操作是Git中最容易出现事故的地方，很多Java开发在多人协作时遇到冲突就非常头大。这一节我结合实际开发中的高频场景，把分支管理的操作细节和注意事项讲透。
4.1 用master最新代码覆盖分支的正确操作
场景描述：你有一个功能分支feature-xxx，上面已经提交了一些改动，现在master已经被别的同事更新了，你想用master的最新代码覆盖掉你的功能分支，让你的分支和master完全一致（放弃本分支上的所有改动）。
这个操作要分两种情况。第一种：你想放弃功能分支的所有本地改动，直接用master的代码顶上。可以用：
git checkout feature-xxx git reset --hard master这样feature-xxx分支的HEAD就指向master的最新提交，工作目录和暂存区也同步更新了。第二种：你想保留功能分支的改动，但把master的最新代码合并进来，这种叫做"同步最新master"，用的是：
git checkout feature-xxx git merge master如果遇到冲突，就手动解决。但如果你不想生成一个合并提交，而是想把本地提交"重新应用到"master最新代码之上，那就用git rebase master。
reset --hard的方式我在实际项目中用得很少，因为大多数情况下功能分支上还是有价值的改动，不该直接丢掉。更多时候是同事跟你说"你那个分支上代码不要了，以master重新拉一个吧"，这种就没必要折腾Git命令了，直接在IDEA里新建一个分支指向master最新提交就行。
4.2 merge还是rebase：Java团队协作中的分支同步策略
这可能是Java团队里争论最多的一个问题。我先把两者的核心区别说清楚：merge会把两个分支的提交历史"接起来"，生成一个额外的合并提交；rebase会把本地分支的提交一个个"搬到"目标分支之后，相当于重新播放了一遍你的提交，历史是一条直线。
用merge的好处是安全，不会改写已有提交的哈希值，适合公共分支；坏处是历史里会有分叉和合并节点，git log --graph看到一堆拐弯，阅读成本高。用rebase的好处是历史线性，阅读起来很清爽；坏处是它会改写提交的哈希值，如果这个分支已经被别人拉取了，就会出问题。
我的实践建议是：公共分支（master、develop、release）一律用merge，禁止rebase；个人特性分支在同步master最新代码时，大胆用rebase。因为特性分支是你自己的，别人不会拉取，rebase之后即便历史变了也没有影响，还能让最终合入master时保持线性历史。
在Java团队多人协作中，我见过一个特别好的约定：master上禁用rebase和push -f，代码通过pull request合入，确保所有人都基于同一个历史提交往下走。特性分支每隔半天git rebase master一次，最后合并回master时用git merge --no-ff生成一个合并节点，代表一个完整的功能合并。
4.3 切换分支与未提交改动的保护机制
Java开发中最容易犯的错误是：在一个分支上改了代码，没提交就切换到另一个分支，结果改动"丢了"。实际上Git有保护机制，如果你在切换分支时有未提交的改动，Git会尝试把这个改动带到新分支上。如果两个分支的对应文件没有差异，切换会成功；如果有差异，Git会拒绝切换，报错说"Your local changes to the following files would be overwritten by checkout"。
正确做法是先用git stash暂存当前改动，切换分支，回来之后再git stash pop恢复。或者直接先commit当前改动，再切换分支，回来之后用git reset --soft HEAD~1（如果想保持改动在暂存区）或者git reset --mixed HEAD~1（如果想撤销暂存但保留改动）。
不习惯命令行的Java开发，在IDEA里操作更简单：IDEA在切换分支时会自动检测未提交的改动，弹窗让你选择"Smart Checkout"（自动stash）或"Force Checkout"（丢弃改动）。这里我强烈建议选"Smart Checkout"，但要注意，自动stash后如果忘了恢复，一段时间后可能发现自己某次改动"消失了"，所以最好切完分支后马上恢复或者记住stash名。
4.4 冲突解决的全流程与Java文件冲突常见陷阱
冲突是Java开发中最常见的Git痛点。当两个分支修改了同一个文件的相同区域时，Git无法判断谁对谁错，就会把冲突标记留在文件里。解决冲突的本质是：打开冲突文件，手动选择保留哪部分代码。
一个典型的Java文件冲突标记长这样：
<<<<<<< HEAD public void doSomething() { System.out.println("version from current branch"); } ======= public void doSomething() { log.info("version from feature branch"); } >>>>>>> feature-login<<<<<<< HEAD到=======之间是当前分支的代码，=======到>>>>>>> feature-login之间是合并进来的分支的代码。你需要手动编辑这个文件，保留想要的逻辑，删除冲突标记，然后git add标记为已解决，最后git commit完成合并。
Java项目冲突中最容易踩的坑有三个。第一个是版本号冲突：pom.xml里加了一个新依赖，两个分支加的位置一样但内容不同，需要手动取舍；第二个是配置文件冲突：application.yml或者application.properties，大家经常在同一个文件里加配置项，合并时冲突概率极高；第三个是编译器生成文件：target目录下的东西不该提交，但有些人配了.gitignore不规范，导致编译产物频繁冲突。
解决Java文件冲突时我的建议是：先看看冲突文件是不是自动生成的（target、out目录、IDEA的workspace.xml），如果是，直接删掉然后git checkout --ours/theirs选一边覆盖；如果是源码文件，不要盲目选其中一边，要理解两边的代码逻辑，必要的话把两边的小段代码都保留，然后手动整理成正确的Java语法。
4.5 特性分支开发周期过长的处理：分叉合并、cherry-pick与分支同步
特性分支开发周期长了之后，会遇到一个非常头疼的问题：分支已经严重落后于master，合并时产生了大量冲突。这时候有些人会想"我能不能不合并master，等做完了再一次性合"，这是最糟糕的选择——冲突一旦积累起来，后期会花数倍时间解决。
更好的方案是定期同步master。具体做法是：
git checkout feature-xxx git fetch origin git rebase origin/master每同步一次解决一部分冲突，把冲突控制在可处理范围内。如果某个冲突反复出现（比如两个分支都在大量改动同一个Java类），说明你们的代码结构可能有问题——一个类承担了太多职责，应该考虑拆分。我在实际项目中遇到过UserServiceImpl这种上帝类，几乎所有开发都在改它，每天合并都有冲突，最后把这个类拆成了UserQueryService和UserCommandService，冲突概率骤降。
如果某些功能分支上的提交只需要部分"借用"到另一个分支，可以用git cherry-pick <commit-hash>。这个命令会把指定的提交应用到当前分支。对Java开发来说，cherry-pick最常见的场景是：热修复提交到了master，但发布分支也需要同样的修复；或者某个功能分支上有一个独立的小修复，想拿过来单独发布。注意两点：一是cherry-pick会复制出一个新提交，哈希值变了；二是如果源提交和当前分支有冲突，也需要手动解决。
5. 常见问题与排查技巧实录：GUI工具、命中报错与恢复误删的补救
最后这个部分我整理一下Java开发中用Git时经常遇到的报错和问题，全部来自我自己的开发经历和同事们的血泪教训。按"问题现象—排查思路—解决方案"的方式组织，方便大家直接对照处理。
5.1 IDEA未显示代码分支的处理
IDEA 2023版本偶尔会出现一个奇怪的问题：代码仓库明明有好多分支，但IDE的Git工具栏里就是显示不出来，或者只显示当前分支。我排查下来，大概率是git branch -r显示的远程分支列表没有更新，因为IDE的Git分支列表默认读取的是本地缓存的远程跟踪分支。
解决办法有两种。第一种：打开IDEA的终端（Terminal），执行：
git fetch --prune然后回到Git工具栏刷新，分支列表一般就恢复了。第二种：在IDEA的设置里重新配置Git路径，路径不对也会导致分支识别异常。具体位置是Settings → Version Control → Git，把Path to Git executable重新指向你本地的git.exe路径。
还有一种情况：你在IDEA里右键项目没有"Git"菜单，说明项目还没纳入版本控制。VCS → Enable Version Control Integration → Git，选完Git后项目会关联到本地仓库，但如果是新项目还需要重新remote add origin。
5.2 VS Code清理已删除分支的方法
VS Code的Git面板有一个问题：远程分支删除后，本地origin/xxx的远程跟踪分支依然存在，下拉列表里总能看到一堆失效分支。命令行里用git fetch --prune可以清理，但VS Code界面里没有直接的"Prune"按钮。
操作方法是：打开VS Code的命令面板（Ctrl+Shift+P/Cmd+Shift+P），输入"Git: Fetch (Prune)"并执行。这个命令等同于命令行里的git fetch --prune。执行之后，失效的远程跟踪分支会从列表里消失。
如果VS Code偶尔出现分支和远程不一致的情况，多执行几次Git: Refresh刷新视图。我还遇到过一个问题：VS Code的Git插件版本和Git版本不匹配导致分支识别异常，更新插件或者升级Git的git version就能解决。
5.3 Git提交后忘记推送的补救
这种问题太常见了：本地commit了，以为推送了，结果第二天发现远程仓库没有。排查方法是git status看本地分支和远程分支的领先/落后状态，或者git log origin/master..HEAD查看本地比远程多出哪些提交。
补救很简单：直接git push就行。但如果你已经在本地上做了多次commit，想把这些commit合并成一个再推送，可以：
git reset --soft origin/master git add . git commit -m "合并后的提交信息" git push这个方法对Java开发来说特别实用，尤其适合在推送到远程之前把本地的一堆杂碎commit整理成几个有意义的提交。不过要注意：这里的reset --soft动了HEAD，但提交还没推送到远程，所以是安全的。
5.4 Git回退后代码丢失的找回：reflog的救命用法
我在前面反复提醒git reset --hard很危险，因为会丢失工作目录的改动。但万一你真的操作了并且后悔了，还有一个救命工具：git reflog。
reflog记录的是HEAD指针的历史移动轨迹，包括reset、commit、checkout等所有操作。比如你执行了git reset --hard HEAD~3，之前HEAD指向的提交哈希值在reflog里依然能找到。找回方式：
git reflog # 找到reset之前的那条记录，记下哈希值 git reset --hard <找回的哈希值>我职业生涯中靠reflog救回来过两次重要的代码，一次是手误--hard掉了同事的几个提交，一次是切换分支时选择了"Force Checkout"把改动丢了。所以我对所有Java开发的建议是：不管做什么危险操作，先看一眼git reflog还在不在。
注意：
reflog只在本地仓库中有效，如果你克隆了一个新仓库，reflog是空的。另外，reflog记录也有过期时间，默认是90天，超过90天的记录会被清理。
5.5 Java项目中的OutOfMemoryError与Git的关系
热搜词里有一个java: OutOfMemoryError: insufficient memory，这其实是Java服务运行时的报错，和Git没有直接关系。但我在实际开发中碰到的场景是：Git操作时JVM内存溢出。比如在IDEA里执行大型代码重构、同时打开多个大模块的Gradle/Maven项目时，Git索引和JVM缓存叠加，内存占用飙升。
解决办法：调整IDEA的JVM内存参数（Help → Change Memory Settings，给到2GB以上）；优化Maven/Gradle构建内存（MAVEN_OPTS、GRADLE_OPTS）；如果命令行执行git时遇到"insufficient memory"（多见于Windows），可以调整git config --global core.packedGitWindowSize和core.packedGitLimit参数，或者在C:\Users\用户名\.gitconfig里增加：
[core] packedGitWindowSize = 16m packedGitLimit = 256m这个是Git在处理大型仓库时的内存优化项，实测对某些老项目有效。不过说实话，每次Java项目出现这种报错，我最先排查的还是自己的IDE插件和构建工具配置，Git自身的内存问题占比不高。
5.6 企业多分支协作的Git规范建议
最后分享一点我在团队中推行过、且效果不错的分支管理约定。这些不是Git官方规范，但都是实战沉淀下来的经验。
分支命名：feature/xxx、bugfix/xxx、hotfix/xxx、release/xxx，不要用dev、test这种语义不明确的名字。提交信息：遵循约定式提交，feat:、fix:、docs:、refactor:加描述，Java项目里我非常推荐在提交信息里写上改动的类名或模块名，方便后期检索。合入策略：master禁止直接push，必须通过MR/PR合入；特性分支至少每天同步一次master；凡是推送前用rebase整理提交历史，合入master时用merge --no-ff保留合并节点。
回退策略：远程公共分支禁止reset --hard和push -f；必须回退时用revert生成逆操作提交。紧急修复：从master拉hotfix分支，修完同时合入master和当前发布分支，有条件的话用cherry-pick只挑需要修复的提交。
这些规范的核心目标只有一个：让任何一个人在任何时间点都能讲清楚当前代码在哪个分支、做了哪些改动、为什么这么改。Java项目动辄几十上百人协作，没有清晰的Git规范，光靠"大佬记得哪个分支是对的"这种模式是走不下去的。
