做了三年程序员，希望我的同事比我懂这些

之前用Git，完全是”粗放式操作”，只把它当作简单的代码快照工具，每次提交全凭感觉，遇到回滚、多人协作合并代码的问题就手忙脚乱，只能临时搜教程凑活用。最近抽时间系统梳理了Git的核心用法，才发现里面藏着不少提升效率的细节。今天把这些实用技巧整理出来，一方面给自己留个备忘录，免得日后再”临时抱佛脚”；另一方面也分享给和我有过类似困惑的小伙伴

一、代码回滚

1 2	git reset --hard <commit_SHA-1> git push --force origin <branch_name>

这里要提醒一句，git reset --hard 会彻底丢弃当前工作区的修改，执行前一定要确认好目标提交的SHA-1值（可以通过git log查看）。如果是多人协作的公共分支，谨慎使用--force强制推送，避免覆盖他人的提交记录。

二、多人协作合并代码到主分支（Rebase）

变基（Rebase），和merge相比，避免分支提交历史变得杂乱无章，让提交历史保持整洁线性。
Rebase的核心逻辑是：将当前分支的提交”复制”到目标分支的最新提交之后，相当于让当前分支站在目标分支的”肩膀上”继续开发。需要注意的是，Rebase会改变提交的哈希值，因此不建议在多人协作的公共分支上使用。
步骤：

确保当前工作目录干净（没有未提交的修改，可通过git status查看）；
切换到待合并的test分支，并拉取远程最新代码，保证本地分支是最新状态：
1
2
git checkout test
git pull origin test
将test分支的提交变基到master分支的最新状态：
1
git rebase master
若过程中出现代码冲突，先手动解决冲突，然后执行git add <冲突文件>，再用git rebase --continue继续变基，重复该步骤直到变基完成；若想放弃变基，执行git rebase --abort即可。
切换回master分支：
1
git checkout master
执行快进合并（由于test分支已基于master最新状态变基，master分支可直接快进合并，不会产生新的合并提交）：
1
git merge test
（可选）将合并后的代码推送到远程仓库：
1
git push origin master

## 三、规范提交消息

1. 统一提交格式

一个完整的提交消息分为三个部分：标题、正文、页脚，格式如下：

<type>(<scope>): <short summary>
[空一行]
<body>
[空一行]
<footer>

示例

feat(user): 添加用户注册功能

实现用户注册接口，支持邮箱和手机号码注册，并增加基础数据校验。

Closes #12

2. 常用类型（type）

类型	说明
feat	新功能（feature）
fix	修复 Bug
docs	文档更新（documentation）
style	格式调整（不影响代码运行，例如缩进、空格、分号）
refactor	代码重构（不新增功能、不修复 Bug）
perf	性能优化
test	测试代码相关变更
chore	构建流程、工具或依赖更新（不影响源代码）
ci	CI/CD 配置或脚本变更
revert	回滚到某个提交

3. 写作规则

标题（第一行）
- 最多 50 字符
- 不加句号
- 用动词原形（add、fix、update、remove）
- 清晰概括核心修改
正文（可选）
- 每行 ≤ 72 字符
- 说明做了什么、为什么做
页脚（可选）
- 关联 Issue：Closes #123 / Fixes #45

4. 常见提交示例

feat(auth): 新增 JWT 登录认证
fix(ui): 修复暗黑模式下按钮颜色不正确的问题
docs(readme): 增加项目启动步骤说明
style: 格式化所有 js 文件，统一缩进为 2 空格
refactor(api): 优化用户查询逻辑，减少数据库请求次数
perf(image): 压缩首页图片大小，提升加载速度
test(user): 补充用户注册接口单元测试
chore(deps): 升级 axios 至 1.5.0 版本
ci: 添加 GitHub Actions 自动化测试工作流
revert: 回滚 commit 1a2b3c4，恢复旧的 API 逻辑

5. 小贴士

一个提交只做一件事
先 git add 相关文件，再写与之匹配的提交信息
如果不确定类型，用 chore 兜底
团队可以用 Git Hook（如 commitlint）来强制检查格式