说实话，我见过太多新手倒在了 Git 的第一道坎上。明明官方文档写得清清楚楚，网上的教程也一抓一大把，可真到自己动手的时候，不是装完不知道下一步干嘛，就是git commit完之后发现提交错了，更常见的是git push到远程，结果报错信息看都看不懂。这个标题里的关键词——安装、提交、基础操作、全流程，几乎就是每个开发新人刚接触版本控制时的必经之路。如果你现在正处于“看着命令认识、动手就慌”的阶段，或者你已经在用 Git 但提交记录乱成一锅粥，那这篇内容就是写给你看的。我会从安装开始，一直讲到把代码提交到远程仓库，中间顺手把新手最容易踩的坑都给你们指出来，尽量做到一步步都能照着抄。
1. 装好 Git 之前，先把这几件事搞清楚
1.1 Git 到底是什么，为什么新手总在“传文件”上翻车
很多人学 Git 之前已经有习惯，代码传到网盘、微信文件传输助手、U 盘拷来拷去。一开始项目小还觉得挺方便，等代码量一大，问题就全暴露了：版本覆盖、队友改的代码找不回来、两个人同时改一个文件最后合并到想哭。Git 本质上是一个“分布式版本控制系统”，它不只是在服务器上记录你的代码历史，而是每个人本地都有一份完整的仓库。这意味着你可以先在自己电脑上随便折腾、反复提交，确认好了再推到远程分支。这个过程里最核心的概念就是“提交”，就是你给某一时刻的文件状态拍一张照，以后任何时候都能退回去看。
很多新手第一次跑git init或者提交代码时，会看到一堆英文提示，立刻就头皮发麻。别慌，Git 的命令行交互看起来很原始，但每一句报错其实都在提醒你下一步怎么做。你只要理解了几个核心概念，剩下全部都是肌肉记忆。
1.2 不同系统下的安装方式与验证
先说 Windows。官方推荐的方式是下载 Git for Windows 安装包，一路 Next 安装，中途有几个比较关键的选项需要注意。一个是“Select Components”那一步，建议勾选“Git Bash Here”和“Git GUI Here”，这样右键菜单里就能直接打开 Git Bash。另一个是“Adjusting your PATH environment”，默认选中间那个“Git from the command line and also from 3rd-party software”就好，这样在终端和 VS Code 里都能直接识别 git 命令。还有一步是“Checkout as-is, commit Unix-style line endings”，这个先不动，后面讲换行符的时候我会专门解释。装完之后打开 CMD 或者 Git Bash，输入git --version，能输出版本号就说明装成功了。
macOS 用户简单一些，只需要在终端里敲git --version，系统会弹窗提示安装 Command Line Tools，点确认等它装好就行；如果你已经装了 Homebrew，也可以brew install git。Linux 用户则一般用sudo apt install git或者sudo yum install git，不同发行版指令略有区别。
我特别想强调一句：装完之后一定要先做验证，不要直接开始写代码。很多新手装完以为闪退了，其实只是没看到窗口。用git --version验证一下，能输出什么，心里就踏实了。
1.3 装上之后必做的两个全局配置
Git 装好了，理论上就能用了，但有一个特别容易忽略的步骤：告诉 Git 你是谁。这一步不做，后面的提交记录会显示成奇奇怪怪的系统用户名，而且提交时也容易触发报错。
打开终端，执行下面两条命令：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这个--global的意思是全局生效，也就是这台机器上的所有仓库都默认用这个身份。user.name和user.email会写进每次提交的记录里，所以建议用你能让同事认出来的真名，邮箱最好用你注册代码托管平台时用的那个，避免以后机器人监测到提交头像对不上号。
检查是否配置成功，可以用：
git config --global --list把这两行显式列出来，说明配置已经生效。有人会问，那我不配置直接提交行不行？有些旧版本 Git 真能提交成功，但提交记录里就会显示“author unknown”之类的信息，等团队协作的时候很不好认，到时候再改历史记录又是一笔麻烦。所以在开始提交之前，花十秒钟设置好人设，很值。
2. 从零开始提交第一份代码
2.1 初始化仓库，搞懂工作区里的文件状态
所有 Git 操作都要在一个仓库里进行。仓库的初始化命令是git init。我自己比较推荐的流程是：用 VS Code 打开一个项目文件夹，按 Ctrl+` 呼出终端，然后在终端里逐条执行命令。
假设你现在新建了一个文件夹叫my-project，里面写了一个README.md，那么初始化之后，这个目录就会被 Git 接管：
cd my-project git init执行完这行命令后，你的目录下会多一个隐藏的.git文件夹。千万不要去动它，它就是 Git 的“大脑”，所有版本记录、分支信息、历史提交都存在里面。看到它就说明仓库已经建好了。
接下来用git status看一下当前状态。刚 init 完，Git 会告诉你当前在哪个分支（默认是 master 或 main），同时把没被跟踪的文件列出来。这一步是以后用得最多的命令，它会非常直白地告诉你哪些文件被修改了、哪些文件还没暂存。新手学会看git status的输出，就已经会了一大半 Git。
2.2git add和git commit到底在干什么
很多新手第一次操作时会困惑：为什么文件改完了，还要先git add，再git commit，不能一步到位吗？这个设计其实非常巧妙。git add是把改动放进一个叫“暂存区”的地方，相当于先把要提交的内容挑出来；git commit才是真正把这些内容打包成一次提交记录。
简单理解就是：git add相当于去超市往购物车里放东西，git commit相当于到收银台结账。你可以在货架上选一会儿，放进来、感觉不对再撤掉，等购物车里的东西都满意了，再一次性付款。
所以在项目里修改了几个文件后，正确的流程是：
git status # 先看有哪些改动 git add README.md # 添加指定文件 git add src/ # 添加整个目录 git add . # 添加所有改动，但是要注意看 status 里有没有不该加的文件 git commit -m "docs: 初始化项目说明文档"这里有个关键细节：git add .是很方便，但也容易把不该提交的文件搞进去，比如编辑器配置文件、日志、临时文件。提交之前一定要先用git status查看“Changes to be committed”区域的清单，确认没有敏感信息再提交。等到后面讲了.gitignore，这一步就能轻松很多。
git commit -m后面的信息也不是随便写的。好的提交信息能帮未来的自己和同事快速理解改动意图。我见过有人提交信息写“update”“修改”，问改了什么，自己也说不清。初学者至少要做到：说明改了哪个模块、做了什么、为什么这么做。后面专门有一部分讲提交规范。
2.3 提交后怎么看记录，git log的常用姿势
第一次提交成功之后，屏幕会输出一行信息，大概意思是说当前提交是干净的工作区，没问题。此时你可以用git log查看提交记录：
git log git log --oneline git log --graph --oneline --allgit log的输出里每一个 commit 后面都有一长串 40 位的十六进制哈希值，这就是这次提交的唯一标识。--oneline会把每条提交压缩成一行，只看哈希前几位和提交信息，日常最常用。--graph会把分支走向画出来，尤其是多人协作的时候，能直接看出各自的分叉。
这里插一句：提交哈希值不是拿来背的，它相当于快递单号，用来精确定位某一次提交。日常操作中，你只需要知道哈希值的前几位就可以，比如git show a1b2c3，Git 会自动识别。而且哈希值不是随机乱码，它由提交内容和时间等信息计算得出，所以“同一个提交在同一时刻只能存在一个地方”。
2.4 第一次提交就遇到的常见小问题
第一个场景：git commit提示*** Please tell me who you are.没配置用户信息，或者配置没生效。回上一节看全局配置命令，检查git config user.name和git config user.email是不是空的。
第二个场景：提交完发现忘了一个文件没加进去。或者提交信息写错了、有笔误。这时候不要强行再提交一次“修复写错的提交”，而应该用git commit --amend。这个命令会把刚才那次提交覆盖掉，等于给已经拍好的照片重新洗一张。用法是先把漏掉的文件加进暂存区，再执行git commit --amend，它会打开编辑器让你修改提交信息。
第三个场景：Windows 用户可能会看到一条警告warning: in the working copy of 'xxx', LF will be replaced by CRLF。这是换行符差异。Windows 系统里文本文件默认用 CRLF 换行，而 Linux 和 macOS 默认用 LF。Git 在提交时会自动做转换，具体怎么处理看你的配置。对新手来说，看到这个警告不用太紧张，提交内容不会出大问题；但如果你和不同系统的队友协作，最好统一约定换行符策略。一个常见的做法是在仓库根目录放一个.gitattributes文件，把文本文件的换行符统一成 LF，这能省不少后面合并代码时的麻烦。这个文件用一个最简版本就能覆盖 90% 的情况：
* text=auto *.js text eol=lf *.ts text eol=lf *.json text eol=lf3. 提交背后的原理：三大区域与版本回退
3.1 工作区、暂存区、版本库到底怎么配合
如果只记住一条命令就上项目，那遇到需要撤销的场景一定懵。理解 Git 的三大区域模型，等于掌握了一套完整的地图。
- 工作区：就是你电脑上能看到、能编辑的文件目录。
- 暂存区：夹在工作区和版本库中间的一层，本质上是
.git/index文件，它记录了你git add过哪些内容。 - 版本库：就是
.git文件夹里的对象数据库，保存一个接一个的提交快照。
当你在文件里写代码时，改动只发生在工作区，Git 不知道。执行git add后，改动被记录到暂存区。执行git commit后，暂存区的内容被打包成一次提交，写入版本库。之后就形成了一个“三点一线”的流程：工作区改代码 -> 暂存区记录改动 -> 提交到版本库。
这个模型非常关键，它能解释很多怪异现象。比如你明明改完了代码，可是git status显示还有改动；或者git checkout之后文件被还原了。这些都是因为三个区域的状态不一致。
3.2 提交之前的最后一道检查：git diff
很多人习惯一改完代码就git add . && git commit -m "update"，等推上去才发现某个不该改的地方混进去了。更稳的做法是提交前先看差异。常用三招：
git diff # 查看工作区和暂存区的差异 git diff --staged # 查看暂存区与上一次提交的差异 git diff HEAD # 查看工作区与上一次提交的差异第一次看会很懵，觉得一堆+++和---很吓人。其实很简单：减号代表旧内容，加号代表新内容。逐行检查，确认每一次改动都是自己有意做的，再提交。这个习惯一旦养成，你的提交记录质量会有质的提升，也能避免把调试代码、测试乱改的文件一起提交上去。
如果发现某个文件已经存到暂存区但不想要了，撤销命令是：
git restore --staged <file>这个命令不会删除你的工作区改动，只是把它从暂存区“退货”回工作区。git restore是新版本 Git 推荐的做法，老版本用的是git reset HEAD <file>，效果类似。用git restore就行，直白很多。
如果是工作区的文件改砸了想撤回，用git restore <file>，不过这操作不可逆，它会直接把工作区文件恢复到上次提交的样子。所以如果真的非常重要，先备份一下，别手滑。
3.3 版本回退与git reset的三种模式
提到撤销，就绕不开git reset。这个命令的原理是把 HEAD 指针移动到指定提交位置，同时可以选择性地把暂存区和工作区一起重置。它有三种模式：
--soft：只移动 HEAD，暂存区和工作区都不动。适合提交完发现少加了一个文件，或者提交信息写错，想重新整理后再次提交。--mixed：默认模式。移动 HEAD，重置暂存区，但保留工作区改动。也就是说撤销git add，但保留代码修改。--hard：三个区域全部重置到指定提交的状态，工作区里未提交的改动全部丢弃。必须非常谨慎使用。
举个例子，你提交了一次记录，哈希值是a1b2c3，想回退到它之前的版本：
git reset --soft HEAD~1此时最后那次提交被“退回”到暂存区，你再git add补齐文件、重新git commit，就能得到一条完整的新提交。而如果不小心用了--hard，而且没有记录原哈希值，想找回就非常麻烦了。对于有经验的开发者来说，一个保命习惯是：在做任何高风险操作前，先git log记下当前提交的哈希值。如果真手滑了，可以用git reflog查看所有 HEAD 移动历史，把原哈希找回来。
这里也提醒一个常见误区：git reset是回退历史，git revert是“新增一个提交，把之前某次提交的内容反着做一遍”。如果是已经 push 到远程、别人可能已经拉了你的分支，那么不要用reset硬改历史，应该用revert增加一条反向提交。这是团队协作里非常重要的职业素养。
4. 写出让人看得懂的提交信息
4.1 为什么提交信息值得认真写
有同学觉得提交信息随便写写就行，反正代码才是重点。但到了项目维护阶段，你会发现，一段有价值的历史比代码本身更能帮人理解演进过程。比如线上出了 bug，你查git log时看到fix: 修复订单金额计算精度问题，几乎不用看代码就知道问题大概在哪；但如果看到的是“update”“修改”，排查效率就大打折扣。再比如代码 Review 阶段，规范的提交信息能直接让评审同事知道这次改动的影响范围，不需要从十几页 diff 里猜。
所以我的建议是：宁可多花几分钟写清楚，也不要图省事。这不只是好习惯，更是职业素养的一部分。团队里如果有人提交信息写得乱七八糟，等出问题的时候，所有人都会感受到那种痛苦。
4.2 一套很经典、很好上手的提交信息模板
目前最流行的提交信息规范之一是 Conventional Commits，格式大概是：
<type>(<scope>): <subject> <body> <footer>- type：必填，表示本次提交的类型。
- scope：可选，表示影响范围，比如哪个模块。
- subject：必填，简洁描述变化，中文英文都行，但建议全文保持一种语言。
- body：可选，补充说明背景、原因。
- footer：可选，一般用来写 Breaking Changes 或关闭 Issue。
常用的 type 有这些：
| type | 含义 | 例子 |
|---|---|---|
| feat | 新功能 | feat(log): 增加日志导出功能 |
| fix | 修复 bug | fix(order): 修复订单超时未支付状态 |
| docs | 文档变更 | docs: 更新 README 安装说明 |
| style | 格式调整，不影响逻辑 | style: 统一代码缩进 |
| refactor | 重构，不影响功能和 bug | refactor(auth): 抽离登录逻辑 |
| perf | 性能优化 | perf(list): 减少大列表渲染耗时 |
| test | 增加或修改测试 | test(api): 增加接口超时测试 |
| chore | 构建或工具链相关 | chore: 升级打包依赖 |
只看这张表，就能写出让同事夸赞的提交记录了。也不用太焦虑格式，刚开始只要坚持把feat:、fix:这些前缀写对，后面自然会形成肌肉记忆。
4.3 提交信息写错了怎么办，怎么合并多个提交
场景一：上一次提交信息有笔误，但还没 push，可以直接git commit --amend。这个命令会用暂存区内容生成新的提交，并替换掉上一次提交。push 前修改自己的提交信息没有任何风险。
场景二：连续提交了好几个琐碎的小提交，比如“改一下”、后来又“再改一下”，这时候可以把它们合成一条有意义的提交。用交互式变基git rebase -i HEAD~3会打开一个交互界面，把后面几条提交的pick改成squash（缩写是s），保存后就能把所有改动合并进第一条提交。注意：这条命令尽量不要动那些已经推到远程且别人基于它工作过的提交，否则容易把历史搞得很难看。
另外提一个很实用的小技巧：写提交信息时尽量不要使用中文标点里的全角括号或者奇怪的空格，不同工具对编码的兼容性稍有不同，统一风格能避免一些渲染问题。我自己的习惯是，如果这次改动不止一个文件，就必须在 body 里写清楚主要改了什么，而不是把一堆文件扔进一个 commit 不管了。
5. 提交到远程仓库：push 全流程与常见报错排查
5.1 关联远程仓库，生成并配置 SSH 公钥
本地提交只是完成了自己电脑上的版本记录，想让代码存到远程仓库，或者和别人协作，就必须先把本地仓库和远程库关联起来。以常见的代码托管平台（GitHub、GitLab、Gitee 都适用）为例，流程如下：
- 在平台上新建一个空白仓库，拿到仓库地址，形如
https://github.com/用户名/仓库名.git。 - 在本地终端执行：
git remote add origin 仓库地址 git branch -M main git push -u origin mainorigin是默认的远程仓库别名，-u的意思是建立追踪关系，之后直接git push就行，不用反复写完整命令。
实际操作中，很多人会在 push 时遇到Permission denied (publickey)之类的报错，这时应该检查 SSH 认证。生成密钥的命令：
ssh-keygen -t ed25519 -C "你的邮箱"一路回车即可，默认密钥路径是~/.ssh/id_ed25519。之后再执行cat ~/.ssh/id_ed25519.pub把公钥内容复制到托管平台的 SSH keys 设置里。公钥是用来识别你设备的，不是私钥，私钥文件千万不要泄露给任何人。
5.2git push -u origin main一直提交不上去怎么排查
这个热搜词背后的痛，我太有体会了。新手第一次跑 push 的时候，绝大多数情况下报错都是下面几种：
第一种：fatal: not a git repository。这说明你当前不在仓库目录里，或者目录里的.git被误删了。切换目录到仓库根目录再去执行。
第二种：fatal: remote origin already exists.。说明远程仓库已经关联过了，用git remote set-url origin 新地址就能替换。
第三种：error: failed to push some refs。这个非常经典，提示说远程有本地没有的提交，让你先 pull。原因可能是你在远程页面上创建仓库时勾选了“初始化 README”等文件。解决方案是先把远程内容合并到本地，再重新 push：
git pull origin main --allow-unrelated-histories git push origin main--allow-unrelated-histories是比较关键的一个选项，因为远程仓库和本地仓库完全没关联，如果不加，Git 会因为两边没有共同历史而拒绝合并。这个场景在新建仓库时非常常见，理解了原理以后就不会慌。
第四种：Permission denied (publickey)。要么 SSH 公钥没配置，要么密钥不匹配。回到 5.1 检查一下，确认ssh -T git@github.com能返回成功的提示。
第五种：could not read Username for 'https://...'。使用 HTTPS 地址 push 时，Git 会要求输入用户名和密码。现在大部分平台都不再支持密码 push，改成了需要生成访问令牌（Personal Access Token），在输入密码时粘贴 token 而不是你的登录密码。
还有一个需要提醒的：如果公司网络环境下 SSH 临时连不上或者端口不通，优先检查网络连接、DNS 设置，或者换用 HTTPS 地址加上 token 的方式。这类问题普遍是网络环境或认证问题，不要一上来就想着改一堆奇怪配置，按队列排查最快。
5.3 提交之前检查.gitignore和敏感信息
远程仓库一旦 push 上去，即使后面删掉，历史记录里也还会留着，所以提交前一定要做好防护。.gitignore就是用来告诉 Git “哪些文件不需要跟踪”的。常见的需要忽略的内容包括：node_modules、编译产物dist/、日志文件*.log、IDE 配置文件.idea/和.vscode/、操作系统临时文件.DS_Store、环境变量文件.env等。下面是一个很通用的基础模板：
node_modules/ dist/ build/ *.log .env .DS_Store .idea/ .vscode/如果项目已经提交了不少没用文件，再补.gitignore是来不及的，因为.gitignore不会自动把已经跟踪的文件移除。此时要先用git rm --cached -r node_modules这样把文件从 Git 索引中移除，注意--cached参数表示只从版本控制里删，不删本地文件。然后再提交一次，就清理干净了。
这个部分的核心原则很简单：公钥、私钥、密码、token、数据库连接串这些信息，永远不要提交进仓库。哪怕仓库是私有仓库，也不要抱有侥幸心理。万一泄露，第一时间去平台撤销 token 或密钥并重新生成，同时改掉仓库里的相关配置。
6. 我最想提醒新手的一些坑与经验
6.1 不要盲目git add .
三年前我刚带实习生的时候，看见他每次提交都是git add .然后git commit -m "update"，最后合并代码的时候问题一大堆。现在我给自己定了一个规矩：提交之前必须看一眼git status。哪怕只有一个文件，也要确认。如果需要批量提交但又想分开成多个 commit，可以用git add <目录> <文件名>精确控制，把不同业务改动的提交信息写清楚。
还有一个更高效的辅助方案是git add -p，它能让你逐块选择改动进入暂存区。比如一个文件里你改动了两段不相关的代码，按块选择之后就能分别为它们写不同的提交信息。这个功能非常值得新手掌握，它是从“会用 Git”到“用得专业”的一个明显分水岭。
6.2 分支隔离与git worktree
很多人喜欢把所有改动都堆在 main/master 分支上，等需要单独修复一个线上小 bug 时才手忙脚乱。正常开发流程应该是：每个功能或每个修复都开一个独立分支。常用命令是：
git checkout -b feature/xxx等开发完、提交完、确认没问题，再切回主分支合并。但有一个实际痛点：项目比较大时，来回切换分支很慢，又或者当前分支有未提交的改动，切换会被拒绝。这时可以用git worktree为某个分支单独开一个工作目录，这样两个分支可以同时在两个文件夹里存在，互不干扰。这个命令我现在每天都在用，尤其适合需要同时做“手头功能”和“紧急修复”的场景。不过它有一定上手成本，新手可以先把常规分支流程跑通，再尝试 worktree。
6.3 强制推送要谨慎再谨慎
新手的另一个习惯是：本地改了很多东西之后推不上去，就搜索“git push 强制覆盖”的解决方法，然后直接git push -f。-f表示 force，意思是强行让本地分支覆盖远程分支。这种操作只要不小心，就可能把队友的提交直接覆盖掉，而且很难找回来。
我整理了一个优先级：能正常 pull 再 push，就别用-f；如果真的需要覆盖远程，先和团队确认没有其他人在这个分支上工作；覆盖之前把当前分支的哈希值记录下来，至少给你留一条退路。等以后熟练了，也可以用--force-with-lease来替代-f，它会在覆盖前检查远程分支是否比本地多出提交，如果多出就拒绝强制推送，安全不少。
6.4 我的一个小习惯：提交信息遵循规范，但不要咬文嚼字
最后分享一个我自己的经验。刚开始学提交规范时，我也犯了“为了规范而规范”的毛病，每次写提交信息都纠结半天，是 feat 还是 refactor，先写还是后写。后来我想通了，提交信息的核心目的是给人类看，所以只要描述清晰、别人读得懂，完全不用追求一字不差。fix: 修复订单列表在移动端布局错乱这种信息，哪怕没有按照标准格式逐字段写，也比空泛的“update”好一万倍。
每次提交的时候试着在脑内问自己：“如果三个月后的我看到这条记录，能不能一秒想起来当时改了啥？”能，说明这条提交是好提交；不能，就回去把信息补充完整。这个标准简单，但非常有效。
现在你已经具备了从安装 Git 到配置身份、初始化仓库、提交代码、查看历史、管理远程、排查报错的完整能力。剩下的就是多练，练多了你也会形成自己的习惯。如果过程中再遇到什么问题，先用git status和git log看看自己的仓库状态，再带着报错信息去搜索，问题基本都能解决得比想象中快。
