企业官网建设流程全解析

简介：这份 docx 文档面向刚接触版本控制或需要随时查阅命令的开发者，系统整理了 Git 常用命令及解析，覆盖基本操作、远程仓库、代码管理、分支管理、代码查看以及压缩解压等场景，可作为日常开发中的速查手册。资源包内共 1 个 docx 文件，约 11KB，体积轻巧，便于本地保存与随时翻阅。文档按功能分类罗列命令，如查看配置、提交记录、分支切换、撤销修改、摘取提交、打包解压等，并附有简要说明，帮助读者理解每条命令的用途与使用时机。目前已有 1748 人学习下载，适合需要快速上手 Git、巩固命令记忆或排查操作问题的开发者参考，也可作为团队内部培训的辅助材料。

1. git常用命令：从「只会 clone 和 pull」到能独立收拾仓库烂摊子

很多人第一次接触 git，是从git clone和git pull开始的。能拉代码、能提交，就以为够用了。直到某天遇到合并冲突、误提交了大文件、切分支切出一堆报错，才发现自己其实一直在用「阉割版」的 git。git 常用命令真正要解决的，不是背下几十条指令，而是让你在仓库出问题时能自己定位、自己修复，而不是删库重来。这篇内容面向已经装好 git、能完成基本提交，但一遇到冲突、回退、分支管理就发怵的开发者。我会按「配置 → 日常提交 → 分支与合并 → 回退与救援 → 排错」的顺序，把每条命令背后的意图、参数边界和踩坑点讲清楚，让你看完能直接在自己的项目里复现。

2. 先把 git 配置和本地仓库跑通：安装、免密、第一次提交

2.1 git 安装与最小配置清单

不管你是 Windows 装 git bash，还是 Linux 下用包管理器装，装完第一件事不是急着 clone，而是把身份和默认行为配好。否则提交记录里会出现莫名其妙的默认用户名，后面想改历史都麻烦。

# 配置全局用户名和邮箱，提交记录会带上这两个信息 git config --global user.name "your_name" git config --global user.email "your_email@example.com" # 让 git 在 pull 时默认用 rebase，避免多出一条无意义的 merge 提交 git config --global pull.rebase true # 处理换行符：Windows 用 true，Linux/macOS 用 input git config --global core.autocrlf input # 开启颜色，日志和 diff 更易读 git config --global color.ui auto # 查看当前所有配置，确认没配错 git config --list

这几条里最容易翻车的是core.autocrlf。Windows 和 Linux 混用仓库时，如果一边设true一边设false，每次提交都会看到整文件 diff，实际内容没变，全是换行符在捣乱。团队里统一约定一个值，写进项目文档，比事后排查省事得多。

pull.rebase也值得说一句。默认的git pull等于fetch + merge，多人协作时历史里会堆满「Merge branch 'xxx'」的提交。设成 rebase 后，你的本地提交会被挪到远端最新提交之后，历史是一条直线。代价是冲突要一个个解，但换来的是可读的提交记录。

2.2 免密与 SSH 认证：git 免密配置和 ssh 认证失败怎么查

热词里「git免密」「ssh认证失败 git」出现频率很高，说明这是高频卡点。免密的核心是把本地公钥放到代码托管平台，让 git 走 SSH 而不是每次输密码。

# 1. 生成密钥对，-t 指定算法，-C 是注释（一般写邮箱） ssh-keygen -t ed25519 -C "your_email@example.com" # 2. 一路回车，默认存在 ~/.ssh/id_ed25519 和 id_ed25519.pub # 3. 查看公钥内容，复制到平台的 SSH Keys 设置里 cat ~/.ssh/id_ed25519.pub # 4. 测试连接，-T 表示不分配终端，-v 是调试模式 ssh -T git@github.com ssh -T git@gitee.com

如果ssh -T报Permission denied (publickey)，按这个顺序查：先确认公钥确实粘贴到了平台，且没有多余换行；再确认~/.ssh/config里没有把 Host 指错；最后用ssh -vT看握手过程，哪一步被拒一目了然。还有一种情况是本地有多个密钥，git 默认只读id_rsa，这时需要在~/.ssh/config里显式指定：

# ~/.ssh/config 示例 Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee IdentitiesOnly yes

IdentitiesOnly yes是关键，它强制只用指定的密钥，避免 git 拿错钥匙反复试导致认证失败。

2.3 从零建仓到第一次提交的完整链路

配置好之后，把本地目录变成 git 仓库，走一遍完整流程：

# 初始化本地仓库 git init # 查看当前状态，确认哪些文件被跟踪、哪些是未跟踪 git status # 添加指定文件到暂存区 git add README.md # 添加所有改动（新增、修改、删除） git add -A # 提交，-m 后跟提交信息 git commit -m "chore: init project" # 关联远端仓库 git remote add origin git@github.com:user/repo.git # 首次推送并建立追踪关系 git push -u origin main

git add -A和git add .在老版本 git 里有区别：git add .只处理当前目录及子目录，git add -A处理整个仓库。现在两者行为基本一致，但在仓库根目录之外执行时仍要注意。提交信息建议用feat:、fix:、chore:这类前缀，后面查日志时能直接过滤。

3. 日常提交与历史查看：git commit --amend 和日志搜索怎么用

3.1 修改最近一次提交：git commit --amend 的正确姿势

git commit --amend是热词里被单独拎出来问的命令，因为它太容易用错。它的作用是修改最近一次提交，可以改提交信息，也可以把新改动的文件补进去。

# 场景一：只改提交信息，不新增文件 git commit --amend -m "fix: correct typo in config" # 场景二：漏了一个文件，补进上一次提交 git add forgotten_file.py git commit --amend --no-edit # --no-edit 表示沿用原来的提交信息，不弹出编辑器

关键边界：--amend只能改最近一次提交，而且会生成一个新的 commit hash。如果这次提交已经推到远端，amend 之后必须用git push --force-with-lease覆盖，否则远端和本地会分叉。--force-with-lease比--force安全，它会在远端有你没拉到的提交时拒绝推送，避免把别人的工作冲掉。

注意：在共享分支上，已经推送的提交尽量不要 amend。个人分支随便改，团队分支改了要提前说。

3.2 日志搜索与 diff 对比：快速定位某次改动

仓库大了之后，git log一屏屏翻效率极低。常用组合是：

# 单行显示，带分支和标签装饰 git log --oneline --decorate --graph # 按作者过滤 git log --author="zhangsan" # 按提交信息关键词搜索 git log --grep="login" # 搜索代码内容变更，-S 后跟字符串 git log -S "validateToken" --oneline # 查看某次提交具体改了什么 git show <commit-hash> # 对比工作区和暂存区 git diff # 对比暂存区和最近一次提交 git diff --cached # 对比两个分支的差异文件列表 git diff main..feature --stat

git log -S是很多人不知道的利器，它按「某字符串出现次数发生变化」来筛选提交，比--grep搜提交信息更精准。比如你想知道某个函数是什么时候被删掉的，-S直接定位。

git diff --stat只列文件名和改动行数，不展开内容，适合快速判断两个分支差多少。

3.3 暂存与清理：stash 和 clean 的边界

手头改到一半要切分支，又不想提交，用 stash：

# 暂存当前改动，-u 连未跟踪文件一起存 git stash push -u -m "wip: login form" # 查看暂存列表 git stash list # 恢复最近一次暂存并从列表删除 git stash pop # 恢复但不删除，适合需要多次应用 git stash apply stash@{0} # 删除某条暂存 git stash drop stash@{0}

git clean则是删除未跟踪文件，危险系数高：

# 先预览会删哪些文件，-n 是 dry-run git clean -n # 删除未跟踪文件 git clean -f # 连未跟踪目录一起删 git clean -fd # 连 .gitignore 忽略的文件也删（慎用） git clean -fdx

-x会把node_modules、dist这类忽略文件也删掉，执行前一定先-n看一眼。我见过有人直接git clean -fdx，把本地编译产物和依赖全清了，重新装了半天。

4. 分支与合并：git 分支合并的三种方式和冲突处理

4.1 分支创建、切换与追踪

# 创建并切换到新分支 git switch -c feature/login # 老写法，效果一样 git checkout -b feature/login # 查看本地分支，-v 带最近提交 git branch -v # 查看所有分支，包括远端 git branch -a # 删除已合并的本地分支 git branch -d feature/login # 强制删除未合并分支 git branch -D feature/login # 拉取远端分支并在本地建立追踪 git switch -c feature/login origin/feature/login

git switch和git checkout的区别：switch专门用于切分支，checkout还能恢复文件，功能更杂。新版本 git 推荐用switch和restore分开操作，语义更清晰，也不容易误操作。

4.2 合并的三种方式：merge、rebase、squash

merge：保留完整分支历史，会产生一个 merge commit。

git switch main git merge feature/login

rebase：把当前分支的提交挪到目标分支之后，历史是一条直线。

git switch feature/login git rebase main # 如果有冲突，解决后： git add resolved_file git rebase --continue # 想放弃 rebase： git rebase --abort

squash merge：把整个分支的提交压成一个，再合入目标分支。

git switch main git merge --squash feature/login git commit -m "feat: add login module"

选哪种取决于团队约定。个人分支同步主干用 rebase，功能分支合入主干用 merge 或 squash。rebase 的代价是冲突要逐个提交解决，但历史干净；merge 一次解决所有冲突，但历史会有分叉。

注意：rebase 会改写提交 hash，已经推送的公共分支不要 rebase。

4.3 冲突处理的固定流程

冲突不可怕，可怕的是乱改。固定流程是：

# 1. 查看冲突文件列表 git status # 2. 打开冲突文件，找到 <<<<<<< ======= >>>>>>> 标记 # 保留需要的代码，删掉标记 # 3. 标记为已解决 git add conflicted_file # 4. 继续合并或 rebase git merge --continue # 或 git rebase --continue

如果冲突太多想重来：

git merge --abort git rebase --abort

冲突标记里的HEAD是当前分支，另一侧是合入的分支。搞不清哪边是哪边时，先看git status提示的「ours」和「theirs」，再决定保留哪段。

5. 回退与救援：reset、revert、reflog 的避坑指南

5.1 reset 的三种模式与适用场景

# 软回退：只移动 HEAD，暂存区和工作区不变 git reset --soft HEAD~1 # 混合回退（默认）：移动 HEAD，重置暂存区，工作区不变 git reset HEAD~1 # 硬回退：HEAD、暂存区、工作区全部回到目标提交 git reset --hard HEAD~1

--soft适合「提交早了想重新组织」；--mixed适合「撤销 add」；--hard会丢改动，执行前确认工作区没有未保存内容。已经推到远端的提交，不要用 reset 回退，用 revert。

5.2 revert：安全的公共分支回退

# 撤销某次提交，生成一个新的反向提交 git revert <commit-hash> # 撤销最近一次提交 git revert HEAD # 撤销一系列提交，-n 表示不自动提交 git revert -n HEAD~3..HEAD git commit -m "revert: rollback three commits"

revert 不改写历史，适合公共分支。代价是历史里会多出反向提交，但这是可接受的。

5.3 reflog：最后的后悔药

git reflog记录 HEAD 的每一次移动，包括 reset、rebase、checkout。误操作后第一件事就是看它：

# 查看 HEAD 移动历史 git reflog # 找到误操作前的 hash，重置回去 git reset --hard <hash>

reflog 默认保留 90 天，足够你找回大部分误删的提交。但注意：reflog 是本地记录，换机器或重新 clone 就没有了。

6. 常见问题排查：fatal: not a git repository 和推送失败怎么解

6.1 fatal: not a git repository

现象：执行任何 git 命令都报fatal: not a git repository (or any of the parent directories): .git。

原因：当前目录不在任何 git 仓库内，或者.git目录被删了。

解决：pwd确认当前路径，ls -a看有没有.git。如果确实不在仓库里，cd到正确目录，或者git init新建。如果.git被误删，只能从远端重新 clone。

6.2 推送被拒：non-fast-forward

现象：git push报! [rejected] main -> main (non-fast-forward)。

原因：远端有你本地没有的提交，git 拒绝覆盖。

解决：先git pull --rebase把远端提交拉下来，解决冲突后再 push。不要直接--force，除非确认远端提交可以丢弃。

6.3 大文件误提交导致仓库膨胀

现象：提交了一个几百 MB 的二进制文件，之后每次 clone 都很慢。

原因：git 保存所有历史版本，大文件会一直留在.git里。

解决：用git filter-repo或BFG Repo-Cleaner从历史中移除。简单场景可以：

# 从当前提交中移除，并加入 .gitignore git rm --cached bigfile.zip echo "bigfile.zip" >> .gitignore git commit -m "chore: remove big file"

但这只删了最新版本，历史里还在。彻底清理需要重写历史，操作前备份仓库。

6.4 换行符导致的整文件 diff

现象：只改了一行，git diff显示整个文件都变了。

原因：core.autocrlf配置不一致，或者文件本身混用了 CRLF 和 LF。

解决：统一配置core.autocrlf，必要时用.gitattributes强制指定：

# .gitattributes * text=auto *.sh text eol=lf *.bat text eol=crlf

6.5 分支删了想恢复

现象：git branch -D删了分支，发现还有用。

解决：git reflog找到该分支最后一次提交的 hash，然后：

git switch -c recovered-branch <hash>

只要 reflog 还在，分支就能救回来。

7. 进阶技巧：用 alias 和钩子把常用命令压成一条

git 常用命令敲多了，重复输入很烦。两个提效手段：alias 和 hooks。

alias 把长命令压成短命令：

# 配置常用别名 git config --global alias.st "status -sb" git config --global alias.co "checkout" git config --global alias.br "branch -vv" git config --global alias.lg "log --oneline --decorate --graph --all" git config --global alias.last "log -1 HEAD --stat" git config --global alias.unstage "reset HEAD --"

配完之后，git st等于git status -sb，git lg直接出彩色分支图。git unstage <file>撤销暂存，比记git reset HEAD --顺手。

hooks 则在特定时机自动执行脚本。比如提交前跑 lint：

# .git/hooks/pre-commit #!/bin/sh npm run lint if [ $? -ne 0 ]; then echo "lint failed, commit aborted" exit 1 fi

保存后加执行权限chmod +x .git/hooks/pre-commit。这样每次 commit 前自动检查，避免把格式错误推上去。hooks 不会随仓库分发，团队共用需要放到项目里再软链到.git/hooks，或者用 husky 这类工具管理。

我自己的习惯是：alias 只配最常用的五六条，多了记不住反而添乱；hooks 只放真正会拦住错误的检查，太重的检查放 CI 里跑。git 的命令很多，但日常真正高频的就那二十来条，把它们用熟、用对边界，比背全集有用得多。希望帮到你。

本文还有配套的精品资源，点击获取