Git新手入门：从安装到提交全流程详解

说实话我见过太多新手倒在了 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 a1b2c3Git 会自动识别。而且哈希值不是随机乱码它由提交内容和时间等信息计算得出所以“同一个提交在同一时刻只能存在一个地方”。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% 的情况* textauto *.js text eollf *.ts text eollf *.json text eollf3. 提交背后的原理三大区域与版本回退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 footertype必填表示本次提交的类型。scope可选表示影响范围比如哪个模块。subject必填简洁描述变化中文英文都行但建议全文保持一种语言。body可选补充说明背景、原因。footer可选一般用来写 Breaking Changes 或关闭 Issue。常用的 type 有这些type含义例子feat新功能feat(log): 增加日志导出功能fix修复 bugfix(order): 修复订单超时未支付状态docs文档变更docs: 更新 README 安装说明style格式调整不影响逻辑style: 统一代码缩进refactor重构不影响功能和 bugrefactor(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”等文件。解决方案是先把远程内容合并到本地再重新 pushgit pull origin main --allow-unrelated-histories git push origin main--allow-unrelated-histories是比较关键的一个选项因为远程仓库和本地仓库完全没关联如果不加Git 会因为两边没有共同历史而拒绝合并。这个场景在新建仓库时非常常见理解了原理以后就不会慌。第四种Permission denied (publickey)。要么 SSH 公钥没配置要么密钥不匹配。回到 5.1 检查一下确认ssh -T gitgithub.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看看自己的仓库状态再带着报错信息去搜索问题基本都能解决得比想象中快。