一、什么是小步频繁提交？
小步频繁提交：把一个比较大的开发需求、大功能，拆分成一个个很小、能够独立验证的子任务，每完成一个小任务，就及时提交一次代码。
举个例子：做登录页，不要等页面布局、表单校验、短信登录、接口联调全部写完再提交。
可以拆成：
- 搭建登录页面基础布局 → 提交
- 增加账号密码输入框校验 → 提交
- 新增短信验证码模块 → 提交
每一小块能跑通、能验证就提交。
一次性大量代码提交的四大弊端
- 版本历史混乱，难以追溯：一条提交里面塞了几十处改动，以后想查某一处代码是为什么修改的，翻看日志根本分不清。
- 代码冲突风险大幅增加：改动文件多、改动行数大，和同事分支合并的时候，非常容易出现大量冲突，解决冲突费时又容易改错。
- 调试困难，不容易定位 Bug：一旦出问题，不知道是哪一部分代码引入的问题，排查范围巨大。
- 工作成果丢失风险高：长时间不提交，如果本地代码误删、编辑器崩溃，大量未保存的代码直接丢失。
小步频繁提交带来的好处
- Git 提交历史干净清晰，每一条提交对应一件小事，方便查阅
- 改动量小，合并分支时冲突更少，冲突也好解决
- 出 Bug 时可以快速定位到是哪一次提交引入的问题
- 代码持续存入本地版本库，降低代码丢失风险
- 版本回退更安全，想撤销某个改动，只需要回退对应小提交，不会误删其他正常功能
二、规范的 commit message 提交日志
团队协作，提交备注千万不要随便写 "改代码""更新""调试" 这类模糊文字，规范的提交日志，是团队代码可维护性的基础。
标准格式
类型(可选范围): 简短描述常用 5 种 type 类型
feat：新增功能fix：修复 Bugdocs：修改文档、注释style：仅调整代码格式（空格、缩进、分号，不改动业务逻辑）refactor：代码重构，既没有新增功能，也没有修复 bug，只是优化代码结构
规范示例
git commit -m "feat(login): 新增短信验证码登录功能"小提示：括号里的
login是范围，代表本次改动属于登录模块，方便快速识别改动对应的业务模块，不是必填项，团队统一约定即可。
三、基础 Git 命令作用说明
- git init
初始化本地 Git 仓库，在当前文件夹生成隐藏的.git目录，这个目录就是 Git 的版本数据库，有了它当前项目才被 Git 管理起来。 - git add .
把工作区 里所有改动的文件添加到暂存区。
注意：
.代表全部文件，正式项目有时候不要直接 add .，避免把本地配置、垃圾文件加入暂存。
- git commit -m "描述"
将暂存区中的改动，正式提交保存到本地版本库，-m后面跟上本次提交的说明文字，生成一条版本记录。 - git log
查看当前分支的提交历史记录，可以看到每一次提交的作者、时间、commit 信息、提交哈希。
最后小结
Git 不只是一个备份代码的工具，更是团队协作、版本追溯的工具。
记住两个核心习惯：✅ 小步频繁提交、✅ 提交信息规范清晰。再掌握 init /add/commit /log 这套基础流程，就能避开协作里绝大多数基础坑。