背景
在Git中，每个commit代表了一个特定时间点的代码快照。理想情况下，每个commit应该只包含一个或几个小的、有意义的更改。这样做的好处包括但不限于：便于代码审查（code review）、保持提交历史的清晰性、提高问题追踪的效率。然而，当一个commit尝试合并多个功能时，这些好处就会受到损害。
前提
我接到一个任务正在进行开发，开发刚完成的时候，还没提交，突然又有一个需求，然后我就一起进行了修改，然后提交了。但是这样在几个场景中处理起来就会有影响。
情景一
当我刚刚完成提交之后，然后领导突然说，刚才新的需求需要再商定，不进行投产，那么此时我的代码已经提交了，并且push到了远程分支，那么此时我只能对代码做修改，把刚才所涉及到的部分再改回去。
这样做的话，如果我修改了多个部分，那就需要一个个确认并且修改回去。不但花费时间较多，也有一定的风险。
但是如果我是分开提交的，这样就可以针对第二个进行命令的回退，例如：
echo "// This is a new comment" >> Hello.java
git add Hello.java
git commit -m "Update Hello.java with a new comment"
git push
# 回退
git revert 7a261a1382ef0426eb3124ebd625c88e2c1452da
....
情景二
当我刚刚完成提交之后，相关的负责人需要进行代码审查，但是针对这么多内容，对他来说也是比较复杂的， 可能两个功能中只有一个功能较为核心，但是混杂在一个commit中，还需要他进行仔细的区分。
情景三
同时如果一次性提交多个文件，和别人协同开发的时候也会导致更容易冲突。
情景四
另外如果较长时间运行后，发生问题后，进行问题追溯的时候，可能会忘记当时如何修改的，如果是分次提交，找问题也会更容易定位。
总结
经过以上场景的梳理，我们可以针对以下进行总结，所导致的问题包括以下几种：
- 代码回退复杂
- 代码审查困难
- 代码容易冲突
- 问题追踪困难
优化
为了避免上述问题，可以采取以下几种优化措施：
- 使用分支管理不同阶段的更改：对于大型功能或复杂的修复工作，可以将其分解为多个较小的更改，分次进行提交或者不同的分支提交。
- 采用更明确的commit规范：确保每个commit都遵循一定的命名规范，这样可以帮助团队成员更快地理解每个commit的内容，也更容易进行追溯。
