hw

git

6 min read

Git 工作流速查

这篇速查面向已有 Git 基础的开发者，聚焦于协作场景中的常见决策点与恢复操作，而非命令全集。

假设读者已熟悉 git init、git clone、git commit 等基本操作。

场景 1：提交前的检查

提交前建议先确认变更范围，避免将临时文件或含敏感信息的配置一并纳入：

git status
git diff --cached          # 查看已暂存内容
git add <具体文件>          # 优于 git add .

若误用了 git add .，可将特定文件移出暂存区而不丢失工作区修改：

git restore --staged <文件>

场景 2：提交后发现遗漏或错误

若提交尚未推送至公共分支，可修正后重写最近一次提交：

git add <遗漏文件>
git commit --amend --no-edit
git push --force-with-lease

--force-with-lease 会在远程分支已有新提交时拒绝覆盖，降低误删他人工作的风险。

若已推送到团队共享分支（如 main），不建议 amend 或 force push。此时应追加新提交：

git commit -m "fix: 补充上一提交的遗漏文件"

场景 3：合并冲突的处理

执行 git pull 或 git merge 后，若出现冲突标记：

  1. 定位冲突文件，检索 <<<<<<< HEAD 标记。
  2. 保留所需内容，手动删除所有冲突标记线。
  3. 重新暂存并提交：
git add <冲突文件>
git commit -m "merge: 解决分支 X 与 Y 的冲突，采用方案 Z"

建议在合并提交信息中简要说明冲突的解决策略，便于后续 git log 或 git blame 追溯。

场景 4：工作现场的中断与恢复

当前分支开发至一半，需临时切换至其他分支时：

git stash push -m "描述当前进度，如：login 模块 token 验证未调通"
git checkout <目标分支>
# ... 完成其他工作 ...
git checkout <原分支>
git stash pop

stash 描述不可或缺。未加描述的 stash 在 git stash list 中仅显示默认信息，数日后再定位极为困难。

场景 5：回滚至历史状态

5.1 保留工作区修改的回滚

git log --oneline -10
git reset --mixed <commit-hash>

--mixed 为默认行为：撤回指定提交，但将变更保留在工作区，供选择性重组。

5.2 彻底丢弃当前变更

git reset --hard <commit-hash>

此操作不可逆……但可通过 reflog 在有限时间内恢复：

git reflog
git checkout -b <恢复分支> <目标hash>

reflog 默认保留 30 天，是误操作后的最后防线。

场景 6：分支同步策略

功能分支长期未同步主分支时，建议先 fetch 最新状态：

git fetch origin

再选择同步方式：

方式命令适用场景注意
Mergegit merge origin/main保留完整历史，团队偏好透明合并记录会产生合并节点
Rebasegit rebase origin/main追求线性历史，尚未 push 的个人分支已 push 的分支勿用

Rebase 若遇冲突：

# 解决冲突后
git add .
git rebase --continue
# 或放弃当前 rebase
git rebase --abort

场景 7：敏感信息误提交

尚未 push

git reset --soft HEAD~1
git restore --staged <敏感文件>
echo "<敏感文件>" >> .gitignore
git add .gitignore
git commit -c ORIG_HEAD

已 push 至远程

优先评估作废并轮换密钥是否比改写历史更经济。若必须清理历史：

git filter-repo --path <敏感文件> --invert-paths
git push origin --force

注意：改写公共历史会影响所有协作者的本地仓库，通常仅作为最后手段。

日常高频命令

git status                   # 变更概览
git diff                     # 详细差异
git log --oneline -15 --graph # 近期提交脉络

SSH 密钥配置

ssh-keygen -t ed25519 -C "邮箱"
cat ~/.ssh/id_ed25519.pub
# 将输出添加至 GitHub / GitLab 的 SSH Keys
ssh -T git@github.com        # 验证连接

若验证失败，检查 ssh-agent：

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

常见风险与规避

  1. git add . 的范围不可控。建议在 .gitignore 中预先排除日志、依赖目录、本地配置文件，并养成 git status 后再暂存的习惯。

  2. 公共分支勿用 force push。main 等共享分支的历史属于团队共同上下文，改写会导致协作者本地状态混乱。

  3. Commit message 的语义化。避免 "fix"、"update"、"ok" 等无法追溯的表述。建议采用 "<type>(<scope>): <描述>" 格式，如 "feat(auth): 添加 OAuth2 回调处理"。

  4. Stash 不是持久备份。git stash clear 会不可恢复地清空所有 stash。重要的半成品代码，建议以 WIP（Work In Progress）提交 push 至远端草稿分支，而非长期依赖 stash。

本文档基于个人工作流整理，具体实践请结合团队规范与项目需求调整。

Graph View

Backlinks