原帖 ｜ 刘子奇 ｜ 2026-03-03 14:26 ｜ 👍4 ｜ 阅读约1
因此，你必须掌握一套日常工作中使用 Git 的常用命令流：连贯、贴近真实开发场景，能稳定把代码推到公司服务器/远程仓库，并且不会给团队制造麻烦。
下面我会按照「基础准备→核心开发流程→日常问题处理」的逻辑，给出新手也能轻松上手的 Git 常用命令流，每个命令都附带清晰的解释。
一、环境配置准备
如果是第一次操作项目，先完成 Git 基础配置和代码克隆：
1. 配置全局用户信息（提交记录会显示，需和仓库平台账号一致）
git config --global user.name "你的用户名"
git config --global user.email "你的注册邮箱"
团队注意：有些公司还会要求开启 GPG 签名或统一邮箱域名；如果你提交记录显示陌生邮箱，可能会导致贡献统计/审核失败。
2. 克隆远程仓库到本地（替换为你的仓库地址）
企业环境更常用 SSH（免频繁输密码/Token），HTTPS 也可用但可能需要 Token：
SSH（推荐：公司 GitLab/内网常用）
git clone git@github.com:xxx/xxx.git
HTTPS（可用：可能需要 token/2FA）
git clone
- 进入项目目录（后续所有命令都在该目录下执行）
cd 项目文件夹名称
二、日常开发核心命令流
日常开发建议遵循「主分支不直接开发，功能分支独立开发」原则，核心流程如下：
团队注意：大多数公司会对 main/master 开启保护分支：不允许直接 push 主分支，必须走 MR/PR + CI + Code Review。你本地能合并不代表你能推上去。
步骤1：拉取主分支最新代码
确保本地主分支（main/master）是最新的，避免后续冲突：
切换到主分支
git switch main
如果是 master 分支：git switch master
拉取最新代码时，建议用更安全的方式避免“无意义 merge commit”：
推荐1：只允许快进（最稳，失败就说明你本地落后/有分叉，需要处理）
git pull --ff-only origin main
推荐2：用 rebase 保持线性历史（很多团队喜欢）
git pull --rebase origin main
为什么不直接 git pull：
git pull 默认 = fetch + merge，可能自动生成 merge commit，让历史变乱，新手更容易踩坑。
--ff-only 或 --rebase 更符合团队协作习惯。
步骤2：创建并切换到功能分支
分支命名建议规范（如 feature/功能名、bugfix/问题编号）：
创建并切换到新分支（示例：开发用户登录功能）
git switch -c feature/user-login
团队注意：如果公司有分支命名规范（如需带 JIRA/禅道编号），以团队约定为准。
步骤3：开发过程中的常规操作
1. 随时查看文件修改状态（必用，确认修改范围）
git status
2. 查看你到底改了什么（强烈建议养成习惯）
git diff # 看工作区改动
git diff --staged # 看暂存区改动（add 之后）
3. 将修改的文件加入暂存区
git add . # 添加全部修改
git add src/login.vue # 仅添加指定文件
- 提交代码（提交信息要清晰）
提交信息建议统一格式：类型(模块): 描述
类型示例：feat(新功能)、fix(修复)、docs(文档)、style(格式)、refactor(重构)等
git commit -m "feat(登录): 实现手机号+验证码登录功能" - （可选）提交后发现漏改，如何补救更安全？
情况A：还没 push（最适合 amend）
git add 遗漏的文件路径
git commit --amend
情况B：已经 push（不建议 amend，避免改历史影响同事）
git add 遗漏的文件路径
git commit -m "fix(登录): 补充遗漏修改"
团队注意：commit --amend 会改变提交 SHA。
未 push：随便用；已 push：尽量别用，否则你很可能需要强推，影响协作。
步骤4：推送分支到远程仓库
第一次推送该分支，用 -u 关联远程分支：
git push -u origin feature/user-login
后续修改后直接推送：
git push
团队注意：如果你 rebase 过并且分支已 push，可能需要强推。强推请用更安全的方式：
git push --force-with-lease
--force-with-lease 会在远端分支被别人更新时拒绝强推，比 -f 安全得多。
步骤5：功能完成后合并到主分支
方式1：本地合并（仅适合小型团队/主分支不受保护）
1. 切回主分支并拉取最新代码
git switch main
git pull --ff-only origin main
2. 合并功能分支到主分支
git merge feature/user-login
3. 推送合并后的主分支到远程（很多公司会禁止）
git push origin main
团队注意：如果 main/master 是保护分支，你会 push 失败，这是正常的。
方式2：提 MR/PR（GitLab/GitHub，推荐团队协作 ）
无需本地合并：你只需要把功能分支推上去，然后在平台上提交「合并请求（MR/PR）」
审核通过后由管理员或平台规则合并，并自动跑 CI。
推荐原因：
有 Code Review
有 CI 检查（单测/构建/安全扫描）
合并策略统一（squash/rebase/merge 由团队规定）
主分支更安全
步骤6：清理分支（合并后删除）
删除本地功能分支：
git branch -d feature/user-login # 仅删除已合并的分支
git branch -D feature/user-login # 强制删除未合并分支（谨慎）
（可选）删除远程功能分支：
git push origin --delete feature/user-login
团队注意：很多平台在 MR/PR 合并后可以一键删除远程分支，你也可以在网页端操作。
三、日常问题处理常用命令
1. 撤销工作区修改（未 add 的文件）
恢复文件到最近一次 commit 的状态：
git restore 文件名
示例：
git restore src/login.vue
说明：git restore 比 git checkout -- 文件名 更直观，不容易误解。
2. 撤销暂存区修改（已 add 但未 commit）
将文件从暂存区退回工作区，可重新修改：
git restore --staged 文件名
示例：
git restore --staged src/login.vue
3. 查看提交日志
一行显示所有提交（版本号+提交信息）：
git log --oneline
更推荐带图形结构，排查分支/合并更直观：
git log --oneline --graph --decorate --all
查看指定文件的提交记录：
git log 文件名
4. 解决合并冲突（重点）
合并冲突最常见的触发时机，就是你执行 git merge 或 git rebase 时。
冲突触发的原理
当你合并两个分支时，Git 会尝试自动合并：
如果修改的是不同文件或同文件不同位置 → 自动合并完成；
如果两边修改了同一文件同一行（或相邻行） → Git 无法判断保留哪份 → 中断并提示冲突。
此外，git pull 也常触发冲突（因为 pull = fetch + 合并/变基），所以我们前面推荐用 --ff-only 或 --rebase 来减少不必要的混乱。
示例：merge 触发冲突并解决
1. 切到主分支，拉取最新代码
git switch main
git pull --ff-only origin main
2. 执行合并，触发冲突（Git 提示合并失败）
git merge feature/user-login
输出类似：
Automatic merge failed; fix conflicts and then commit the result.
查看冲突文件（关键步骤）：
git status
会标注冲突文件，比如：
both modified: src/login.c
打开冲突文件，手动修改冲突标记：
<<<<<<< HEAD
主分支的验证码逻辑
=======
功能分支的验证码逻辑
feature/user-login
修改保存后标记为已解决：
git add src/login.c
完成合并提交：
git commit -m "merge: 解决登录功能合并冲突，统一验证码逻辑"
如果合并到一半想放弃：
git merge --abort
补充：如果你用的是 rebase 同步 main（也可能冲突）
git fetch origin
git rebase origin/main
解决冲突后：
git add 冲突文件名
git rebase --continue
想放弃这次 rebase：
git rebase --abort
团队注意：rebase 会“改写历史”。
个人分支 rebase 很常见；
共享分支（尤其 main）一般禁止 rebase。
5. 回滚已提交的代码（务必谨慎）
这里分两种场景：共享分支（main/master） 和 个人分支，做法不同。
场景A：回滚共享分支（main/master）——推荐 git revert
revert 会生成一个“反向提交”，不改历史，团队最安全：
1. 查看提交日志，找到要回滚的提交号
git log --oneline
2. 反向提交（撤销某次提交）
git revert 版本号
如需一次回滚多个提交，可连续 revert 或按团队规范操作
3. 推送
git push origin main
场景B：回滚个人分支（未合并/未共享）——可用 reset（谨慎）
软回滚：保留修改，可重新提交（常用）
git reset --soft 版本号
硬回滚：彻底丢弃后续所有修改（谨慎！）
git reset --hard 版本号
如果分支已经 push，强推请用更安全的方式：
git push --force-with-lease
强推是团队协作大坑：强推前务必确认没人基于你的旧分支继续开发。
（救命）误操作找回：reflog
不小心 reset/hard 了，也可能找得回来：
git reflog
git reset --hard reflog里的某个版本号
总结
日常开发核心流程：「拉取主分支最新代码 → 创建功能分支 → 开发提交 → 推送 → 提 MR/PR 合并 → 清理分支」，避免直接在主分支开发。
养成高频习惯：git status + git diff，提交信息和分支命名要规范，团队协作更顺。
撤销/回滚操作要分场景：共享分支优先 revert；强推尽量用 --force-with-lease，请你尽量不要随手 push -f。
附件：
- 搞软件开发，如果你不会用 Git，可能会被这个时代淘汰.pdf（2.1MB）
相关笔记
- 📁 返回本主题 MOC
- 有个紧急的问题，关于vscod