为什么要掌握一套清晰的 Git 工作流
说白了，Git 不只是工具，它是团队沟通的一种语言。大家知道什么时候开始改、谁改了什么、为什么改了、如何把改动合并——这些信息靠工作流来保证。没有统一的流程，代码就会像没有说明的拼图块，碰上合并冲突或回退需求时就很痛。
从零开始：核心概念，用比喻讲清楚
- 仓库（repository）：就像一个文件夹，记录了历史快照。
- 工作区（working directory）：你当前看到并编辑的文件集。
- 暂存区（staging/index）：把你准备提交的改动放在这里（像购物车）。
- 提交（commit）：把暂存区的内容做成一个有说明的历史节点。
- 分支（branch）：平行的开发线，像树枝，便于并行工作。
- 远程（remote）：团队共享的中央仓库（例如 GitHub、GitLab）。
- 合并（merge）/变基（rebase）：把分支的改动整合回主线，方式不同，历史表现不同。
- 标签（tag）：给某个提交打上版本号，便于发布回溯。
准备工作：安装与基础配置（几分钟搞定）
先装 Git，然后设定身份信息和常用选项：
实战演练：HelloWorld 仓库完整工作流
下面用一个真实但精简的流程演示，从初始化到发布，步骤是你可以照着做的。
1. 初始化仓库并首次提交
本地新项目时：
- git init：初始化本地仓库。
- 创建 README.md、.gitignore（排除 node_modules、.env 等），然后：
- git add . 把文件放入暂存区，git commit -m “init: add README and gitignore” 提交。
2. 关联远程并推送
在托管平台创建仓库后：
- git remote add origin git@host:org/helloworld.git
- git push -u origin main （或 master，团队约定）
3. 创建功能分支并开发（推荐工作流）
每次新功能都在独立分支做，便于审查与回退。
- git checkout -b feature/add-greeting：新建并切换到 feature 分支。
- 实现功能，做到小步提交：git add + git commit -m “feat(greeting): add hello endpoint”。
- 频繁 git push origin feature/add-greeting，保持远程备份。
4. 提交 PR（Pull Request）并做代码审查
发起 PR，写清楚变化、测试步骤与影响范围（这是高效审查的关键）。CI 会自动运行测试，处理好反馈后再合并。
5. 合并策略（merge vs rebase）
两种常见方式：
- merge：保留分支历史，生成一次合并提交；优点是历史完整，缺点是会有额外合并节点。
- rebase：把分支改动在目标分支顶部重放，历史更线性；优点是干净，缺点是在公开分支上操作需小心，避免改变别人提交。
通常做法：在 feature 分支上用 git rebase main 本地整理（如果没有公开给别人看），最后在平台上通过合并按钮把内容合入主分支；团队可约定使用哪种策略（例如 GitHub 的“squash and merge”也很常见）。
6. 打标签与发布
合并到主分支后，生成语义化版本标签：
- git tag -a v1.0.0 -m “release v1.0.0”
- git push origin v1.0.0
这样运维或自动化部署就能基于标签做回滚或打包。
常用命令速查表
| 命令 |
用途说明 |
| git status |
查看当前工作区和暂存区状态 |
| git add <file> |
把文件变更放入暂存区 |
| git commit -m “msg” |
提交暂存区到本地仓库 |
| git push |
把本地提交推送到远程 |
| git pull |
从远程拉取并合并到当前分支 |
| git checkout -b branch |
创建并切换分支 |
| git merge branch |
合并分支到当前分支 |
| git rebase target |
把当前分支变基到目标分支 |
| git revert <commit> |
通过新提交撤销历史提交（安全） |
| git reset –soft/hard |
回退 HEAD（危险，慎用） |
冲突的实用处理流程（别慌）
发生冲突时按这个顺序做通常能最快恢复：先暂停（深呼吸），然后：
- 查看冲突文件：git status
- 打开文件，找到 <<<<<<< HEAD 标记，手动合并内容
- 合并后 git add 冲突文件，再 git rebase –continue 或 git commit 完成合并
- 必要时，把改动先保存到临时分支，再回到主线整理
修改历史：revert、reset 与 reflog 的区别
一两句记住要点：
- git revert：生成一个新的提交来“反做”某次提交，安全用于公共分支。
- git reset –soft：回退 HEAD，但保留暂存区（用于合并提交）。
- git reset –hard：彻底回退，工作区也会丢掉改动，谨慎使用。
- git reflog：如果把 HEAD 改丢了，reflog 通常能帮你找回丢失的提交。
团队工作流范例（简单、可扩展）
这里给个常见且实用的小团队约定：
- 主分支（main）始终可发布（绿色、能部署）；
- 开发分支（develop）可选，或直接 feature -> main；
- 每个 feature 在独立分支，带上 issue 编号：feature/ISSUE-123-add-login；
- PR 必须通过至少一位审查与 CI 通过才允许合并；
- 合并策略统一（例如：squash merge 或者合并并保留历史），并写在团队文档里。
CI/CD 与本地钩子、Git LFS 简介
把 Git 和自动化结合，能把出错率降很多：
- CI：在 PR 提交时跑单元测试、静态检查、构建；不通过就不合并。
- pre-commit hooks：本地运行 linters 或格式化（例如使用 Husky + lint-staged），防止垃圾提交。
- Git LFS：大文件（模型、视频）不要直接进 Git，使用 LFS 或对象存储。
常见坑与对策（实用小贴士）
- 不要在公共分支上重写历史（rebase 后强推会让同事懵）；
- 提交不要太大，一个变更点一条 commit，更容易回退与 review；
- 写清楚 commit message（首行概述，空行，详细描述），便于未来定位问题；
- 遇到权限或 SSH 问题，先检查公钥是否绑定、remote 地址是否用 SSH 或 HTTPS；
- 经常拉取主线并解决小冲突，别拖到最后一刻一次性爆发。
工具选择与 GUI 的使用场景
命令行是最稳的（也最容易教别人跟着），但图形化工具（SourceTree、GitKraken、VSCode 的 Git 插件）在可视化冲突、查看分支图时很有帮助。学会在 CLI 做命令，再用 GUI 看图，会更高效。
关于提交信息的一个简单模板（推荐采用）
写提交信息时可以遵循这样的小模板：
- 首行（简短总结，50 字以内）：type(scope): short summary
- 空行
- 详细描述，说明为什么改、如何验证、可能的副作用
例如：feat(api): add greeting endpoint 然后详细写测试方法与兼容性注意点。
最后一点实操建议（像朋友碎碎念）
每天把未完成的工作 push 到个人分支（备份和心安都很值），遇到复杂冲突先在本地开个临时分支试验解决方案，确认无误再把结果并回去。学会用 git log –oneline –graph 看历史，慢慢你会觉得 Git 不再是魔鬼。
