Git 基础工作流从暂存区到分支协作Git 的价值不只是“把代码传到 GitHub”。它记录每一次有意义的变更让个人开发可以回退、团队协作可以审查问题定位也有可靠的历史线索。## 1. 先区分四个位置日常命令之所以容易混乱通常是没有区分数据所在位置| 位置 | 含义 | 常见命令 || — | — | — || 工作区 | 当前正在编辑的文件 | 编辑器、git status|| 暂存区 | 准备进入下一次提交的变更清单 |git add|| 本地仓库 | 已提交的本地历史 |git commit、git log|| 远程仓库 | 托管平台上的共享历史 |git push、git pull|git add并不是上传它只是在本地选择“这次提交包含哪些变化”。理解这一点后提交粒度会更容易控制。## 2. 一个最小而完整的提交流程bashgit statusgit add src/app.py README.mdgit commit -m feat: add article metadata parsergit push origin main提交前先看git status确认没有把本地配置、模型文件、日志或临时产物加入暂存区。.gitignore用于声明长期不应追踪的文件但已经被 Git 跟踪的文件不会因为后来加入规则而自动停止跟踪。## 3. 提交信息要说明意图好的提交信息不只是“update”。它应该让后来查看历史的人知道变更目的例如textfeat: add batch prediction endpointfix: ignore padding labels in evaluationdocs: clarify public dataset boundary一次提交尽量只解决一类问题。把功能、格式化、依赖升级和大量无关文件混在同一提交中会增加 code review、回退和冲突处理的成本。## 4. 分支是隔离变更的工具在修改主线前创建功能分支bashgit switch maingit pull --ff-onlygit switch -c feature/article-publish功能开发完成后通过 Pull Request 或合并操作把分支变化集成回主分支。分支不是“复制一份文件夹”而是指向提交历史中某个节点的引用因此创建和切换通常很轻量。## 5. 处理冲突的正确顺序冲突表示 Git 无法自动判断两处改动该如何组合不表示文件损坏。处理步骤应当是1. 阅读冲突标记两侧的改动和共同上下文。2. 按实际业务意图手工合并而不是机械保留其中一侧。3. 本地运行相关测试或至少检查编译。4.git add已解决文件再执行提交或继续 rebase。不要在不了解当前状态时用强制覆盖命令解决冲突。先使用git status和git diff确认范围能减少误删他人改动的风险。## 6. 回退与恢复要先确认目标不同场景的处理方式不同- 想取消尚未暂存的局部修改先用git diff查看再针对具体文件恢复。- 想撤销一次已经公开的提交优先使用git revert新建一个反向提交。- 想临时切换到历史版本查看使用git switch --detach commit避免误以为自己仍在分支上开发。对共享分支直接改写已推送历史可能影响其他人应优先采用可追踪的回退方式。## 7. 每天可执行的检查清单text开始开发git status确认分支和工作区是否干净提交前git diff --staged确认暂存内容与意图一致推送前运行必要测试检查敏感文件没有进入提交合并前同步目标分支处理冲突并复测## 总结Git 的核心闭环是“明确变更 - 选择暂存内容 - 留下可读提交 - 同步共享仓库”。只要坚持小提交、先检查再操作、共享历史优先可追踪回退版本控制就会从负担变成开发过程的安全网。