git init用于在本地初始化新仓库，将普通目录转为git版本控制项目，在当前目录创建.git隐藏文件夹存储元数据，适用于新建项目或为现有项目启用版本管理。
初学者不用死记所有 Git 命令，真正高频、必会的就那 5 个操作：初始化仓库、暂存修改、提交快照、查看状态、推送远程。其余命令都是围绕它们展开的补充或纠错手段。
git init 和 git clone 怎么选？
本地已有项目想纳入版本控制，用 git init；想协作或下载别人代码，用 git clone <url></url>。
常见错误：在已有 Git 仓库里重复执行 git init —— 不报错但也没用，Git 会提示 “Reinitialized existing Git repository”，实际什么都没变。
注意点：
-
git clone默认只拉取main或master分支（取决于远端默认设置），不自动获取其他分支 - 克隆后当前目录就是工作区，
.git目录已存在，无需再init - 如果只是想“备份”当前文件夹，
git init && git add . && git commit -m "init"就够了，不必强求远程
git status 显示 “nothing to commit” 却没更新到远程？
这是新手最常卡住的地方：git status 只反映工作区和暂存区/本地仓库的差异，完全不涉及远程。
典型场景：改完文件 → git add . → git commit -m "fix" → git status 显示干净 → 以为同步完成了，其实还没推。
必须补上这一步：
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
- 首次推送分支用
git push -u origin main（-u建立上游追踪，之后直接git push即可） - 确认远程分支名：GitHub 新建仓库默认是
main，旧项目可能是master，别写错 - 如果提示 “failed to push some refs”，大概率是远程有你没有的提交（比如别人先推了），得先
git pull合并再推
git add . 和 git add -A 有什么区别？
两者都用于暂存修改，但行为边界不同，尤其影响新文件和已删除文件的处理。
git add . 只扫描当前目录及子目录，且**不跟踪已删除文件**；git add -A（等价于 git add --all）扫描整个工作区，包括新增、修改、删除的文件。
实操建议：
- 日常开发用
git add .更安全，避免误暂存根目录外的文件 - 删了文件后想让 Git 记录“已删除”，必须用
git add -A或git add -u（仅暂存已追踪文件的修改/删除） - 不确定时，先跑
git status看哪些是deleted、哪些是untracked，再决定用哪个 add
git log --oneline 太简略，怎么快速看某次提交改了啥？
git log --oneline 只显示哈希和提交信息，看不出具体变更。要看内容，直接用：
-
git show <commit-hash></commit-hash>：显示该次提交的 diff（含新增/修改/删除） -
git show HEAD~1：看上一次提交（~1表示前一个，~2是前两个） -
git diff HEAD：对比工作区和最新提交，显示未暂存的改动
注意：git log 默认不显示 merge 提交的详细 diff，加 -p 参数才能看到（git log -p --merges），但初学者几乎用不到。
容易忽略的一点：所有 git show / git diff 命令输出都是基于当前分支 HEAD 的上下文——如果你 checkout 到别的分支，看到的就不是主线上那次提交的实际内容。
