Git从入门到实战：安装配置、核心命令与分支合并全攻略

1. 项目概述

1.1 为什么Git是每个开发者绕不开的技能

在做版本控制这件事上，Git几乎是现代软件开发的默认答案。不管你是刚接触编程的新手，还是在团队里写了好几年代码的老兵，每天都要和git命令打交道。提交代码、切换分支、合并冲突、回滚版本，这些操作看着基础，但真到了关键时候，很多人会卡在某个细节上。热搜词里出现了“git安装及配置教程”、“git常用命令总结”、“git分支合并”，说明大家的需求很一致，就是想把Git这块的基础彻底弄明白。

这篇笔记我会按照一条完整的脉络来讲，从环境准备、核心命令、分支操作，一直到进阶技巧和问题排查。所有内容都是我在实际项目里用过的、踩过坑之后梳理出来的，不是那种只讲理论的操作手册。适合的人群很广：刚开始接触Git的同学可以照着一步步做，有经验的开发者也可以跳着看，重点看后面常见问题那部分，说不定能帮你解决一些一直没搞定的疑难杂症。

1.2 这篇笔记的组织逻辑

我见过太多人学Git的方式是背命令，今天记了明天忘，遇到问题再去搜，下次还是不会。原因在于没有建立起一个整体的认知框架。Git的本质是一个分布式的文件快照系统，你做的每一次提交都是给整个项目拍了一张照片，然后你可以随时回到任意一张照片的状态。

围绕这个认知，我把内容拆成了六个板块。前两块解决“怎么把Git装好、配好”的问题，这是所有操作的前提；第三块讲日常使用频率最高的命令组合；第四块讲分支这个核心概念，这是团队协作的灵魂；第五块讲一些能让工作更高效或者能救急的进阶命令；最后一块针对大家经常搜的问题做集中答疑。按这个顺序读下来，你会发现自己对Git的理解是成体系的，而不是碎片化的。

2. 环境准备与初始配置

2.1 各平台安装Git的正确姿势

安装Git这件事看似简单，但有不少细节值得注意。在Windows上，最主流的方式是下载Git for Windows，也就是大家常说的Git Bash。去官网下载安装包的时候，安装过程中有几个选项容易让人犹豫，比如调整PATH环境变量的选项，建议选择“Git from the command line and also from 3rd-party software”，这样在CMD和PowerShell里也能直接使用git命令。还有一个关于换行符转换的选项，默认的签出时转换、提交时转换回LF，对于跨平台协作的项目来说比较省心，但如果你的团队全是Windows环境，选“Checkout as-is, commit as-is”更稳妥。

macOS用户相对省事，装了Xcode Command Line Tools之后系统就会自带Git，不过那个版本往往偏老。如果你需要较新的版本，建议通过Homebrew安装，终端里执行brew install git即可，干净利落，后续升级也方便。Linux这边，Debian系的用apt install git，RedHat系的用yum install git，需要留意的是不同发行版源里的版本新旧差异很大，如果需要新版本可以考虑编译安装，但对大多数场景来说，发行版自带的版本完全够用了。

安装完成后验证一下，在终端输入git --version，能看到版本号输出就说明装好了。这个动作看起来多余，但真的有人装完不知道装没装上，花几秒钟验证一下，后面才不会白忙活。

2.2 全局配置与用户身份设置

Git提交代码时，每一次commit都会记录作者信息，这个信息来自于你的配置。如果没配，Git会尝试从系统用户名主机名里猜，猜出来的结果通常不是你想要的。所以要做的第一件事是配置user.name和user.email：

bash复制git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

这两个配置项写在~/.gitconfig文件里，加了--global参数意味着对当前用户的所有仓库生效。如果你需要在某个特定项目里使用不同的身份，可以在那个项目目录下不加--global执行同样的命令，项目的配置会覆盖全局配置。

还想提醒一点，很多人配邮箱时随手填一个，过两天就忘了。等到提交记录里出现了错误邮箱，再想批量修改历史提交就比较麻烦了。所以一开始就认真填，和你的代码托管平台账号保持一致，省得后面返工。检查当前配置用git config --list，这个命令会把全局和本地的配置都列出来，方便排查问题。

2.3 SSH密钥配置与免密登录

配置SSH密钥主要解决两个问题，一个是安全认证，另一个是免密推送。你每次git push都要输入账号密码确实很烦，配置好SSH密钥之后一劳永逸。热搜词里“ssh认证失败 git”和“git免密”出现频率很高，这里重点说一下。

先检查本机是否已有密钥：

bash复制ls ~/.ssh/id_rsa.pub

如果没有，生成一个新的：

bash复制ssh-keygen -t rsa -b 4096 -C "你的邮箱"

执行后一路回车即可，默认存储位置是~/.ssh/id_rsa。生成完成后查看公钥内容：

bash复制cat ~/.ssh/id_rsa.pub

把输出的一大串内容复制下来，登录你的代码托管平台，比如Gitee或GitHub，在设置里找到SSH公钥管理的入口，把内容粘贴进去保存。之后用SSH协议的仓库地址拉取推送代码就不再需要输入密码了。

SSH认证失败的原因大多数时候并不是密钥配置错了，而是你连的仓库地址写成了HTTPS形式，或者本机有多个密钥没有通过~/.ssh/config文件指定。排查思路是先用ssh -T git@gitee.com测试连通性，根据返回信息判断问题出在密钥本身还是地址协议上。请注意，这里只讨论密钥配置和仓库地址相关的技术问题，不涉及任何其他内容。

2.4 .gitignore过滤文件与常见陷阱

很多项目里都会有一个.gitignore文件，它的作用是告诉Git哪些文件不需要纳入版本管理。第一次建仓库的时候就应该把这个文件写好，不然把node_modules或者target目录提交上去就是一场灾难。热搜里的“git的过滤文件没有作用”说明很多人配了但没生效。

.gitignore不生效的原因主要有两种。第一种是文法写错了，比如漏了斜杠导致路径匹配不上，或者用了错误的通配符。第二种，也是最常见的一种，是这个文件在你添加.gitignore之前就已经被Git跟踪了。Git的规则是，已经被跟踪的文件不会因为.gitignore规则的加入而自动停止跟踪，你必须手动把它从索引里移除：

bash复制git rm -r --cached node_modules

执行完之后再git add .，规则才会生效。这个操作很实用，很多新手在这块卡很久，其实原理很简单：.gitignore只管未被跟踪的文件，已经被纳入版本的得先用--cached参数把跟踪关系解除。

3. 核心操作实战与原理剖析

3.1 工作区、暂存区、仓库的概念

理解Git的三个区域是掌握所有命令的基础。工作区是你直接编辑文件的目录，暂存区是提交前的缓冲区，仓库则是Git保存历史快照的地方。用生活化的比喻来说，工作区是你在厨房里准备好的食材，暂存区是放在备菜台上的待炒菜品，仓库是已经做好的成品菜。你每做一道菜之前，得先把食材挑好放到备菜台上，这个过程对应的就是git add，炒好出锅对应git commit。

这三个区域的区分解释了为什么Git要设计成两步提交的模式。有些版本控制工具是保存即提交的，但Git让你把修改分成多个逻辑单元再提交，这样历史记录更清晰。比如你改了三个文件，其中两个属于同一个功能，另一个是无关的格式修正，完全可以分两次提交，每次只add对应的文件，保持提交粒度的合理化。

查看各区域状态有一个万能命令就是git status。它会把工作区、暂存区的情况一目了然地展示出来，包括哪些文件已修改未暂存、哪些已暂存未提交。养成频繁敲git status的习惯，比记住一大堆命令更有用。

3.2 一次完整的提交流程

一个标准的提交流程应该是这样的：

bash复制git status
git add 具体文件或目录
git commit -m "feat: 添加用户登录模块"
git push origin main

git add支持多种参数，git add .会把当前目录下所有未跟踪和已修改的文件加入暂存区，git add src/可以只添加指定目录，git add -p则是交互式地逐块确认哪些修改要暂存，这个命令在改动比较碎的时候特别好用，能避免把无关修改混进同一次提交。

git commit的提交信息规范值得多说几句。我建议团队统一采用约定式提交的格式，常见的几种前缀包括feat表示新功能，fix表示修bug，docs表示文档变更，refactor表示重构。格式大概是类型(可选范围): 描述，比如feat(login): 添加短信验证码登录。这样看历史日志的时候，扫一眼就知道每次提交做了什么，配合git log --oneline查看精简版历史，效率很高。

3.3 查看历史与版本回退

提交完成之后，查看历史的常用命令是git log。默认输出比较详细，我实际使用中最常用的是这几个变体：

bash复制git log --oneline --graph --all

--oneline让每条记录只显示一行摘要，--graph展示分支图形，--all包含所有分支的记录。这条命令能让你对项目的整体演进脉络有一个直观的图景。如果只想看某个文件的修改历史，用git log -- 文件名。

版本回退是全量级的重型操作，需要格外谨慎。如果你是刚提交完发现写错了，想撤销这次提交，可以用git reset --soft HEAD~1，这个命令只把指针往回移，暂存区和工作区的改动都还在，你还有机会重新提交。git reset --hard HEAD~1则会连工作区的文件一并回退，文件内容直接变成上一个版本的状态，这个操作不可恢复，用之前务必想清楚。

还有一点提醒，如果这个错误提交已经推送到远程并被人拉取了，不要用reset去改写历史，改用git revert去生成一个反向提交更安全。这个属于多人协作时的基本修养，不影响协作的前提下保留历史真实记录。

3.4 远程仓库关联与拉取推送

本地仓库要和远程仓库关联，用的是git remote系列命令。添加远程地址：

bash复制git remote add origin git@gitee.com:用户名/仓库名.git

origin是远程仓库的默认别名，你完全可以自己命名，但所有教程和团队习惯都用origin，保持一致就好。查看当前关联的远程地址用git remote -v，修改地址用git remote set-url origin 新地址。

git push origin main是把当前main分支推送到远程，第一次推送时如果远程仓库是空的，可能要加-u参数建立追踪关系：

bash复制git push -u origin main

之后就可以直接敲git push了。拉取远程更新的命令有两个，git fetch和git pull的区别是fetch只把远程内容拉到本地仓库但不合并到工作区，pull则会直接合并。实际使用中，如果你不确定远程改动会影响哪些文件，建议先git fetch再手动看差异，确认后决定怎么合并，避免pull自动合并产生意想不到的冲突。

4. 分支管理与团队协作

4.1 分支的本质是什么

分支是Git里最重要的概念，理解它的关键在于认识到分支只是一个指向某个提交的指针。你创建分支，本质上不是复制了文件，而是创建了一个可以移动的指针。这个设计让Git创建分支的成本极低，也是它区别于SVN那一代集中式版本控制系统最大的优势。

创建分支：

bash复制git branch feature/login

切换分支：

bash复制git checkout feature/login

新一点版本的Git还提供了git switch feature/login和git switch -c feature/login，后者是创建并切换一步到位。如果你用2022年以后发布的Git，推荐优先用switch，语义更清晰，避免checkout同时承担切换分支和恢复文件两个功能带来的歧义。

查看当前分支用git branch，加上-a参数可以看到包括远程分支在内的所有分支。删除一个已经合并的分支用git branch -d 分支名，如果分支没合并但确实不要了，用-D强制删除，这个操作同样不可恢复，慎用。

4.2 合并分支的两种方式

分支合并是团队协作中频率很高的操作。git merge和git rebase都能把两个分支的内容合并在一起，但结果形态差别很大。

git merge会生成一个新的合并提交，保留两个分支的历史轨迹，特征是你的提交历史里能看到分叉点。好处是历史真实可靠，不会改写已有提交，坏处是当分支很多时，历史图会变得复杂。git rebase则是把当前分支的提交逐个重放到目标分支的最新提交之上，结果是形成一条直线，历史非常干净，但代价是会改写提交的哈希值。

我个人的建议是，如果你在维护一个长期分支，定期把主分支的更新合并进来用merge更稳妥；如果你负责的是一个功能分支，准备合回主分支时用git rebase主分支让历史更线性，合并前先rebase再merge。热词里“git merge”被反复搜索，说明这是日常操作里最常用也最容易困惑的环节，把这两个概念理清楚，协作效率会有质的提升。

4.3 Merge冲突的产生与解决

合并冲突几乎是每个Git使用者都会遇到的场景。产生冲突的根本原因是两个分支修改了同一个文件的同一段代码，Git无法自动判断该保留哪个版本，只能交给人来处理。

冲突标记长这样：

code复制<<<<<<< HEAD
你的代码
=======
对方分支的代码
>>>>>>> feature/login

你需要手动编辑这个文件，保留正确的代码，然后删掉这些标记，再重新提交。解决冲突时有一个小建议，不要一个人闷头改，最好和另一方确认代码意图。很多冲突之所以改完之后又出bug，就是因为处理冲突的人凭感觉删了某一段，实际上那段代码承担了某些隐含职责。

避免冲突的方法是保持分支短生命周期、频繁地同步主分支代码。分支开得越久，冲突就越多，这是铁的规律。在大型团队里，还可以通过拆分子模块、约定各自的负责目录来从源头减少冲突发生的频率。

4.4 分支管理规范

分支管理是否规范，直接影响一个团队的交付节奏。常见的做法是主干分支模型或Git Flow模型。主干分支模型适合快速迭代的互联网项目，main分支保持可发布状态，feature分支从main切出，开发完合并回去。Git Flow则增加了develop、release、hotfix等固定分支，适合有明确版本周期的项目。

不管用哪种模型，有几条原则是通用的：主分支永远保持可部署状态；功能分支命名用feature/功能名格式，修复分支用fix/问题描述；代码合回主分支前要有审查，至少经过CI自动化测试。还有一个很重要的约定是不要直接在main分支上写代码，热词里“在master上写的代码怎样剪切到dev上”这类问题，根源就是直接在错误的分支上开发了。

这种情况下可用的处理办法是git stash暂存当前改动，切到dev分支，再git stash pop把改动弹出来。如果改动已经在多次提交里了，可以用git cherry-pick把特定提交复制到目标分支。总之硬切有风险，借助Git提供的机制来移动代码是更稳妥的方案。

5. 高效与进阶命令解析

5.1 Stash临时保存现场

经常出现这样的场景：正在feature-A分支开发到一半，突然有个紧急bug要修，需要立刻切换到别的分支。如果直接checkout，Git会因为工作区有未提交的修改而拒绝切换，或者把改动带到另一个分支造成混乱。这时候git stash就是救星。

bash复制git stash push -m "登录模块开发中"
git checkout main
# 修复bug、提交、推送
git checkout feature-A
git stash list
git stash pop

git stash pop会恢复到工作区并移除stash记录，如果想保留记录用git stash apply。多个stash并存时，用git stash list查看编号，恢复指定条目用git stash pop stash@{1}。实际用下来，我建议每次stash都带上-m参数写个备注，不然条目多了根本分不清哪条是哪条，这种小习惯能避免很多低级错误。

5.2 Revert与Commit Amend的正确用法

git revert和git reset都是撤销操作，但应用场景很不一样。reset是移动分支指针，相当于“抹除”历史；revert是生成一个反向提交，相当于“否认”某次提交的内容但保留该提交的痕迹。在远程仓库多人协作的情况下，revert几乎是唯一安全的撤销方式。

git commit --amend也是一个高频实用命令。它用于修改最近一次提交的提交信息，或者把遗漏的改动追加到最近一次提交里。操作方式是在补充完代码后：

bash复制git add .
git commit --amend --no-edit

--no-edit表示沿用原有的提交信息，只追加内容。如果只想改提交信息，直接git commit --amend，然后在弹出的编辑器里修改即可。需要特别注意的是，执行amend之后如果你已经推送过这提交，再push会失败，因为历史被改写了，此时要么强制推送（单人或确认无风险协作时），要么放弃这个操作。在共享分支上轻易amend别人的提交是很惹人烦的行为。

5.3 Cherry-Pick精挑细选

有时候你只需要把一个分支中的某几个提交搬到另一个分支，而不想把整个分支合并过来，这时git cherry-pick就派上用场了。

bash复制git checkout feature-B
git cherry-pick abc123  # 把feature-A上的某个提交复制过来

这在实际工作中很常见，比如一个紧急修复在main分支上做了提交，你现在希望这个修复也出现在当前开发分支上。cherry-pick相当于给指定提交做了一个补丁并应用到当前分支，效果上是精确搬运。需要注意如果两个分支的基础差异太大，cherry-pick也可能产生冲突，处理方式和merge冲突一样。

5.4 Submodule与Subtree

当项目需要依赖另一个Git仓库的部分代码时，git submodule提供了一种嵌套仓库的方案。不过我必须坦白地说，原生submodule的使用体验并不算好，常见的坑包括子模块的提交ID切换后主仓库需要手动更新、克隆项目后子模块需要额外执行初始化等。

用法是：

bash复制git submodule add git@gitee.com:用户/公共库.git libs/public
git submodule update --init --recursive

如果嫌submodule麻烦，可以考虑git subtree。git subtree是把目标仓库的某段历史作为普通目录合并进当前仓库，对使用者来说是透明的，克隆项目不需要任何额外步骤。代价是subtree合并产生的提交历史比较啰嗦。具体选哪个，取决于你的团队监控工作流和协作习惯。

5.5 常用命令速查表

为了方便查阅，我把日常最高频的命令整理成一张表。这张表不能替代实操，但可以作为你记命令的地基，遇到不确定的时候先查一眼，操作多了自然就记住了。

6. 疑难杂症与解决实录

6.1 HTTPS推送总是要求输入密码怎么办

这种情况通常是因为本地凭据没有被Windows凭据管理器或macOS钥匙串记住。解决办法是开启Git的凭据存储功能：

bash复制git config --global credential.helper store

执行后第一次push时输入密码，之后凭据会被明文保存在~/.git-credentials里。如果介意明文存储，可以使用manager或osxkeychain这类辅助程序。更一劳永逸的方案还是前面讲过的SSH密钥方式，配置一次，终身免密，推荐程度更高。

6.2 提交超大文件被拒

很多代码托管平台对单文件大小有限制。如果push时报错类似“file too large”，先把大文件找出来：

bash复制git rev-list --objects --all | grep 大文件的后缀

找到之后要把它从历史中移除，最简单的方案是借助BFG Repo-Cleaner工具，它能比较方便地从提交历史中批量删除文件。如果你不想引入额外工具，也可以在找到对应提交后，用交互式变基git rebase -i把那个提交从历史中去掉。这个操作会改写历史，如果你的仓库已经多人共享，需要沟通好再动。

从源头上避免这个问题，应该从一开始就把构建产物、二进制压缩包等容易膨胀的文件列入.gitignore，并考虑使用Git LFS来管理大型二进制文件。

6.3 GitHub/Gitee使用中遇到的连接问题

分别讨论两类情况来排查：本地连不上远程主机或超时，通常是网络代理配置问题；SSH认证失败显示权限被拒，通常和密钥有关。前面已经说过用ssh -T测试SSH连通性，如果报权限问题，确认你加载的密钥确实是代码托管平台上登记过的那一个：

bash复制ssh-agent bash
ssh-add ~/.ssh/id_rsa

如果你之前在平台上的账号邮箱和本地配置的邮箱不一致，某些平台也会拒绝操作。顺手检查一下git config user.email是否和平台账号绑定邮箱一致，这一步经常被遗漏。

6.4 Git目录泄露后的处置思路

关于“git目录泄露如何下载”这个问题，正规的处置思路是发现这种情况后立刻联系平台方下线对应代码库。个人开发者也要定期检查自己的仓库配置，确认没有把敏感文件提交进去。从运维层面讲，应该在服务器上屏蔽对.git目录的外部访问，比如Nginx配置里禁止以/.git开头的请求，这是常见的加固手段。从个人层面讲，永远不要在仓库里放密钥文件、环境变量、数据库密码这类敏感信息，如果真的不小心提交了，要意识到光是删除文件还不够，必须把历史中的敏感信息一并清除，因为Git的每次提交都是完整快照，历史里一定还留着旧版本。

6.5 git open /dev/null or dup failed错误处理

这个报错在Windows上比较常见，信息是/dev/null or dup failed: no such file or directory。原因一般是Git Bash环境缺失了必要的设备文件，或者杀毒软件误删了某些文件。处理办法一般是重新安装Git for Windows，安装时以管理员身份运行。如果重装后仍然报错，尝试在CMD里先执行where git确认使用的是系统安装的Git还是其他程序自带的老版本Git，有时候IDE内置的Git版本过旧会引发意想不到的问题，统一使用系统Git并配置IDE指向该版本是更稳妥的选择。

7. 实操总结与个人体会

写了这么多，回到最开始那个认知框架：Git就是给项目拍快照，然后让你能自由穿梭在任意快照之间的工具。如果你静下心来把add、commit、branch、merge这几个核心命令玩熟，再理解工作区、暂存区、仓库三者的关系，你已经能应付95%的日常开发场景。剩下的命令，包括stash、revert、cherry-pick这些，都是在特定场景下用来解决问题的工具，用到的时候再查再学，完全来得及。

我个人的体会是，学Git最忌讳的是死记硬背命令清单。把它当成一个工具箱，知道每个工具大概能干什么，用的时候再翻看说明，边用边理解，熟练掌握只是时间问题。还要养成的习惯是频繁查看状态、细心书写commit描述、合理规划分支。这些小习惯看似不起眼，但在一个项目维护数月甚至数年之后，价值会非常明显。历史记录清晰可读，分支结构干净有序，无论是自己回溯问题还是同事接手，都会节省大量时间。

最后分享一个实用小技巧。如果你不确定某条命令的效果，先在一个临时目录里建一个测试仓库，放几个文件随便操作，试试reset、revert、merge这些命令在这个沙盒环境里的表现。大胆放开手，不用害怕把测试仓库玩坏。实战踩坑积累的经验，永远比看十篇教程来得扎实。这篇笔记先到这里，祝你玩转Git。