在团队开发中，推荐采用以分支为中心的工作流：每个功能在独立feature分支上开发，频繁commit并push，提交PR进行代码审查，CI自动跑测试，审查通过后合并到主分支并打tag发布；遇到冲突先本地解决，必要时使用rebase保持历史整洁。并写清楚commit信息与变更日志。便于版本回溯与协同。

为什么要掌握一套清晰的 Git 工作流

说白了，Git 不只是工具，它是团队沟通的一种语言。大家知道什么时候开始改、谁改了什么、为什么改了、如何把改动合并——这些信息靠工作流来保证。没有统一的流程，代码就会像没有说明的拼图块，碰上合并冲突或回退需求时就很痛。

从零开始：核心概念，用比喻讲清楚

• 仓库（repository）：就像一个文件夹，记录了历史快照。
• 工作区（working directory）：你当前看到并编辑的文件集。
• 暂存区（staging/index）：把你准备提交的改动放在这里（像购物车）。
• 提交（commit）：把暂存区的内容做成一个有说明的历史节点。
• 分支（branch）：平行的开发线，像树枝，便于并行工作。
• 远程（remote）：团队共享的中央仓库（例如 GitHub、GitLab）。
• 合并（merge）/变基（rebase）：把分支的改动整合回主线，方式不同，历史表现不同。
• 标签（tag）：给某个提交打上版本号，便于发布回溯。

准备工作：安装与基础配置（几分钟搞定）

先装 Git，然后设定身份信息和常用选项：

• 安装：macOS 可用 Homebrew、Windows 用官方安装包、Linux 用包管理器。
• 全局配置：

  git config –global user.name “你的名” 和 git config –global user.email “你@邮件”，这两条必须有。

• SSH key：生成 ssh-keygen，把公钥加到代码托管平台，避免每次输密码。
• credential helper：在需要的环境启用凭证缓存（例如 macOS 的 credential-osxkeychain 或 Windows 的 manager）。

实战演练：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
• 打开文件，找到 <<<<<<< 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 不再是魔鬼。