1. 先聊透一件事Git的全生命周期到底包含什么很多人学了几个月Git还是在靠“记住命令”硬撑今天clone明天push遇到冲突就慌了神。我最早也是这个状态直到有一次我把一个项目的.git目录不小心部署到生产服务器上被人直接下载了源码才真正意识到Git不是“几个命令的组合”而是一套覆盖代码从出生到上线的完整生命周期管理系统。这篇文章我打算从一个项目的真实案例出发把Git全生命周期里的所有关键节点过一遍环境搭建、配置与免密、本地版本库的日志与回退、分支管理与冲突处理、rebase和储藏再到远程仓库协作、标签发布甚至连如何自己搭一台Git服务器都讲清楚。适合两种人看一种是刚接触Git、对命令一知半解的新手另一种是已经用了几个月但遇到分支合并、版本回退、冲突解决时心里没底的同学。文章里所有的命令我都按实际场景写带参数说明也会写我踩过的坑照着操作基本能跑通。2. 环境准备是第一步Git安装、配置与免密登录2.1 Windows与Linux安装别在这块浪费时间如果你用的是Windows最常见的安装方式就是去官网下载安装包。官网下载慢的话国内有很多镜像源可以用搜“git国内镜像”一般能直接找到企业级镜像站点下载速度能快不少。安装的时候有一步很关键选择调整PATH环境变量的方式一定选“Git from the command line and also from 3rd-party software”否则后面你在CMD或者VS Code终端里会提示“git无法识别”。还有个小细节行尾转换的设置建议选“Checkout as-is, commit as-is”也就是不自动转换换行符。Windows和Linux的换行符不一样如果选错了同一个文件在不同人手上改一次就会产生一堆没必要的diff排查起来非常痛苦。Linux下则简单得多。Debian/Ubuntu系直接用apt安装就行版本可能不是最新的但稳定够用如果想用最新版就得走源码编译。编译Git并没有想象中复杂核心依赖是make、gcc、libssl-dev、libcurl4-openssl-dev、zlib1g-dev缺一不可。抄一段我给Debian服务器装Git用的命令sudo apt install -y make gcc libssl-dev libcurl4-openssl-dev zlib1g-dev wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.40.1.tar.gz tar -zxvf git-2.40.1.tar.gz cd git-2.40.1 make prefix/usr/local all sudo make prefix/usr/local install git --version编译过程大约五分钟期间如果报错大多是缺依赖包缺什么补什么就行。装完之后一定要执行一下git --version确认版本很多坑都源于系统里同时存在多个Git版本。2.2 全局配置和SSH免密配置一次就够装完第一件事就是配置身份信息。这个不配会怎样提交的时候Git会用你机器的主机名加一串随机字符作为提交人到后面看日志你会看到一堆不明来历的提交记录根本分不清是谁写的。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有一个进阶玩法如果同一台机器上有多个Git账号比如公司用GitLab自己用Gitee不要全用global。可以在项目目录里单独执行git config user.name和git config user.email不带--global这样只对当前仓库生效。判断当前仓库有效配置用git config --list会先显示全局配置再显示本地配置本地配置会覆盖全局配置。接着是SSH免密配置。为什么强调这个因为你不想每次push都输入一次账号密码尤其是高频提交的时候输入密码会打断思路。生成密钥的方式ssh-keygen -t rsa -b 4096 -C 你的邮箱生成过程中会问保存路径和密码直接回车使用默认路径、空密码就行。然后去用户目录.ssh文件夹下找到id_rsa.pub文件把内容复制到GitHub/Gitee/GitLab的SSH公钥设置里。测试连接用ssh -T gitgitee.com看到成功欢迎信息就说明通了。免密配置中最常见的问题就是“为什么我配了还是让我输密码”。排查顺序第一看当前仓库的远程地址是不是SSH格式git开头而不是HTTPS格式第二确认密钥文件权限Windows下一般没问题Linux下私钥文件权限不能是644必须是600第三确认你用的平台和公钥是否一一对应很多人把GitHub的公钥复制到Gitee上当然连不通。2.3 关于.git目录泄露这个坑一定要规避Git本地仓库根目录下会生成一个.git文件夹里面保存了完整的历史记录。很多人在部署项目时图省事直接执行git clone拉代码到服务器或者本地打包的时候把.git目录也带上传到Web服务器这就是所谓的“git目录泄露”。只要攻击者访问到http://你的域名/.git/config就可以下载整个.git目录再用工具重构出全部源码和历史版本。我见过不止一个团队因为这个问题导致核心代码被人扒走。规避方法其实很简单线上部署一律不拉.git目录用代码包或CI/CD发布如果必须用git拉代码在Web服务器的配置里显式禁止访问.git路径。这一点属于多年实战经验换来的教训希望你不要像我一样靠踩坑记住。3. 本地版本库实战日志、版本回退与标签3.1 初始化到第一次提交整个生命周期从本地版本库开始。新建一个项目目录进入后执行git init就建立了一个本地仓库。这时候如果输入git status你会看到一堆Untracked文件意思是你还没告诉Git该跟踪哪些文件。git init git add . git commit -m feat: 初始化项目git add .会把当前目录下所有未被忽略的文件加入暂存区。我只用到.gitignore某次忘记把node_modules加进去结果提交了数万个文件仓库直接膨胀后续每次操作都变慢。所以第一件事永远是先写好.gitignore再git add尤其是IDE配置目录、依赖目录、编译产物、本地环境配置文件全部忽略掉。3.2 回到过去git log、git reset与git revert的区别git log是查看提交历史的入口。带参数看更高效git log --oneline --graph --all --decorate这条命令能把所有分支的关系以图的形式展示出来分支分叉、合并一目了然。版本回退是新手最容易搞混的知识点。本质上你需要理解三个地方工作区你正在编辑的文件、暂存区git add后存放的位置、版本库git commit后生成的历史节点。git reset --soft HEAD~1只把HEAD指针回退到上一个版本工作区和暂存区的文件都不动相当于撤销commit但保留更改。git reset --hard HEAD~1直接丢弃所有更改包括工作区的内容回到上一个版本的快照。git revert commitId不移动指针而是产生一个新的提交把该提交之前的变更反向应用回去。实际项目里如果代码还没有push到远程回退用reset比较方便一旦已经push了且别人可能已经拉取了这时用revert更安全因为它在历史上留下了一条“撤销”的记录后续合并不会被旧更改干扰。我记得有一次重构项目时误删了一个功能模块当时发现得比较晚开发分支上已经有几十个提交了。翻git log翻到删除提交的commitId用git revert加了反向恢复一点都没影响到别人的工作。3.3 标签发布版本的锚点分支会随着开发不断变化如果上线遇到问题想快速回到发布时刻的代码就得靠标签。标签相当于给某个提交打上固定的名字一般用semver语义化版本号管理git tag -a v1.0.0 -m 发布1.0.0版本 git push origin v1.0.0-v后加参数是因为我要用附注标签保存打标签的人、时间、说明。轻量标签不带注释日常临时标记还行要当发布锚点不够严谨。拉取远程标签用git fetch --tags删除标签用git tag -d v1.0.0同时还要删除远程的git push origin :refs/tags/v1.0.0。我习惯在上线前打一个tag这样出问题时直接在tag上开fix分支修完后重新发patch版本思路非常清晰。4. 分支管理实现多线并行开发的核心能力4.1 分支的创建、切换与合并分支的底层其实就是指向某个提交的指针创建成本极低所以Git才鼓励你频繁使用分支。实际场景里每个人的工作区应该是一个独立的功能分支而不是所有人在main上开发。git branch feature/login git checkout feature/login # 或简写 git checkout -b feature/login切换分支之前一定要git status确认工作区是干净的否则未提交的修改会跟着分支跑轻则造成混乱重则把半成品带到别的分支上。合并分支是分支管理里最高频的操作git checkout main git merge feature/loginGit默认会用Fast-forward模式合并就是直接移动指针不产生合并节点。如果你希望保留分支合并的痕迹要加--no-ff参数这在大型项目里更常用因为可以看到清晰的分支历史。4.2 冲突处理别慌冲突只是Git在保护你最让新手头疼的就是合并时出现CONFLICT提示。我的看法是冲突不是事故而是Git在告诉你“这里两边修改有重叠我无法自动判断谁对谁错”。这时Git会在冲突文件里插入类似这样的标记 HEAD 这是合并前当前分支的代码 这是另一个分支的代码 feature/login手动处理后删掉标记行再git add和git commit就能完成合并。还有一个细节判断合并时出现冲突如果你对某一方的代码不熟不要硬合。先和同事沟通或者看git log和git blame确认每段代码的意图。我曾经因为“自认为很熟”直接合掉了同事的重构分支结果丢了一段逻辑后来测试阶段才发现代码审查时被狠狠diss了一回。4.3 rebase与stash两个被低估的实用命令merge和rebase是两条完全不同的分支合并思路。merge保留分叉历史rebase则是把当前分支的提交“平移”到目标分支的最新提交之上让历史变成一条干净的直线。git checkout feature/login git rebase mainrebase最有价值的用法不是代替merge而是在提交Pull Request之前把目标分支的新提交同步到自己的分支提前解决冲突让最终合并时一条命令就完事。rebase也有坑不要对已经push到远程的分支执行rebase因为它会重写提交ID一旦别人已经拉过这个分支会造成两边历史不一致。真遇到这种情况大概率需要强制推送协作上很危险。再说stash这个命令专门处理“临时切换分支但暂存区和工作区不能丢”的场景。比如你在feature分支改了三个文件突然要切回main修一个线上bug但改动还没完成不想提交。执行git stash # 切走、修改、提交回来 git stash pop改动就完整回来了。需要保存多个stash条目时就加上备注git stash push -m WIP: 登录模块。恢复时指定编号git stash list查看git stash pop stash{0}恢复。如果应用stash之后发现冲突解决方式跟merge冲突完全一样。5. 远程仓库协作从克隆到发布的全流程5.1 克隆、远程分支与推送拉取远程仓库是团队协作的基础。把本地仓库和远程关联有三种方式clone已有仓库、远程仓库为空时add remote、以及远程仓库存在但本地还没有任何内容时fetch下来再track。最常用的是git clone gitgitee.com:你的账号/项目名.gitclone下来的仓库会自动创建一个指向远程的别名叫origin。查看关联关系用git remote -v。如果要换远程地址或加多个远程比如同时关联GitHub和Gitee用git remote add或者直接修改.git/config文件。推送拉取是整个章节里最需要理解清楚的动作git push把本地已有提交推到远程分支。git pull等于fetch加merge先拉取远端更新再合并到当前分支。git fetch只下载远程数据不改变本地工作区。工作中我常跟团队说pull之前先看看自己的分支和远程分支有没有分叉git fetch之后再git log --oneline origin/main看看。因为git pull自动执行merge远程更新如果波及了你正在改的文件会直接产生合并节点甚至冲突让人莫名其妙。拉取远程的新分支也是一样的道理git fetch origin git checkout -b feature/login origin/feature/login这样就在本地创建了一个跟踪远程分支的新本地分支。后续push和pull就不用带参数了Git会自动关联。5.2 合并远程分支与rebase的协作流程团队协作中纯靠merge会让历史变乱两步走是我推荐的协作方式开发完功能后先rebase一下远程的最新commit到自己的分支解决本地冲突后再push。推送的时候如果远程分支有更新的提交Git会拒绝报“non-fast-forward”错误这时候不要直接加--force强推先pull --rebase同步远程代码然后重新提push。有次我在一个共享分支上执行了git push -f结果把同事刚推上去的修复直接覆盖了。那次事故让我记住了共享分支上永远不要用force push。如果用rebase改写历史也必须明确这个分支是你专属的功能分支不会影响别人。5.3 搭建自己的Git服务器当项目涉及隐私且不想用公有平台时自建Git服务器是最后的归宿。最轻量的方式是利用Git自带的裸仓库协议通过SSH访问。基本原理在服务器上创建一个--bare的裸仓库它没有工作区只保存历史数据然后本地克隆或添加远程地址push到这个仓库。# 服务器上 mkdir /srv/git/project.git cd /srv/git/project.git git init --bare # 本机上 git remote add origin ssh://用户名服务器IP/srv/git/project.git git push -u origin main走SSH协议不依赖额外服务进程只要有账号和SSH服务就能用。但只有裸仓库的Git服务器没有权限管理和Web查看界面团队大了之后体验很差。这时就该上GitLab或者Gitea。Gitea部署非常轻量适合小团队GitLab功能全但吃内存4G以下内存的服务器跑起来很吃力。我在生产环境部署过一台Gitea整个过程半小时搞定用户管理、仓库权限、Web控制台全都具备。之后团队就彻底告别“通过共享文件夹传代码”的模式了。6. 常见问题速查那些排查到怀疑人生的错误6.1 命令执行报错git无法识别这个问题高频出现在Windows环境。在CMD里输入git返回“git无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”原因八成是安装时忘了勾选“Git from the command line”或者安装后PATH没有刷新。解决方案重新安装Git安装时选择把Git加入PATH如果不想重装手动把Git的cmd目录如C:\Program Files\Git\cmd加入系统环境变量。如果是在VSCode的终端里遇到这个问题还要注意终端可能没有继承最新的PATH重启VSCode或者重开一个终端窗口就能解决。6.2 push/pull时的认证失败login failedcheck api token or gitlab version这条报错常见于用IntelliJ IDEA或VS Code的Git插件连GitLab时。它看起来像是Git证书的问题实际与Git本身关系不大。印象里IDEA 2021版本的GitLab集成插件对GitLab版本有一定的兼容性要求版本过旧时就会提示“login failed. check api token or gitlab version”。排查思路第一步在终端手动执行git pull/push确认Git本身的认证是正常的排除SSH和HTTPS凭据问题第二步如果终端正常就检查IDE的GitLab设置确认填写的是Personal Access Token而不是Git密码。GitLab的新版本大多要求用Token方式来认证密码登录已经被禁用了。6.3 查看中文文件名出现转义core.quotepath特殊场景Linux服务器上Git提交了中文文件名在Windows克隆下来后显示成“\346\265\213\350\257\225”或者反过来。这是因为Git默认把非ASCII字符转义了。解决命令git config --global core.quotepath false设置后就会正常显示中文文件名。这个参数在实际协作中很容易被忽略很多人在提交记录里看到一串八进制数字还以为文件出错了。上面这条经验也提示了一个细节很多“疑难杂症”本质上只是Git的默认安全设置了解参数含义比死记硬背命令更有价值。6.4 忽略文件怎么配置推荐给出常用模板.gitignore的作用是让Git自动忽略指定文件或目录。我给出一个通用模板适配大部分前后端项目# 依赖目录 node_modules/ vendor/ # 编译产物 dist/ build/ target/ # 日志 *.log logs/ # 系统文件 .DS_Store Thumbs.db # 环境配置 .env .env.local编写时有个容易忽略的细节如果你执行git add之后才发现忘了忽略某个文件直接修改.gitignore是没用的因为该文件已经在版本库的跟踪名单里了。需要先把对应文件移出跟踪git rm -r --cached node_modules git add .gitignore git commit -m chore: 移除误提交的node_modules--cached参数很重要它只移除跟踪关系不会删除磁盘上的文件。这个操作在生产环境维护中也经常用到比如发现某个conf文件包含服务器地址而不该提交时就用它把文件摘出版本控制。7. 写在最后几个我养成的Git使用习惯前前后后用Git有八九年了踩过的坑远比这篇文章写到的多得多。最后分享几个自己一直在用的习惯未必适合所有人但确实帮我省了不少事。第一提交信息尽量写清楚“为什么”而不是“干了什么”。“修bug”这种提交信息没有任何检索价值等三个月以后回来翻历史你根本不知道改了什么。我自己的提交格式偏向于feat(模块): 具体描述。feat表示新功能fix表示修复chore表示杂项docs表示文档更新。这是一个非常轻量的约定没有任何工具强制但团队达成一致之后效率会提高很多。第二push之前自查三件事git status是不是干净的、git log是不是已经包含了最新变更、分支名是不是对的。我在生产环境见过有人把功能分支的代码推到main就是因为没有检查分支名。多一秒钟的自查能省掉后面一整天的恢复操作。第三不要怕用强制推送但一定要清楚它的适用范围。自己专属的分支怎么rebase怎么改历史都无所谓一旦涉及共享分支强制推送绝对说“不”。如果确实需要修正共享分支的历史让大家停下手头的工作集中同步再走一次干净的流程永远比强行覆盖安全。第四也是最重要的一点Git是帮助你理解代码演变的工具不是束缚你的命令手册。当你理解了提交、指针、索引这几个核心概念后所有命令都能推导出来不再需要背。把精力放在理解模型上比背一百条命令更值钱。 Git全生命周期实战：从安装配置到分支管理与远程协作
1. 先聊透一件事Git的全生命周期到底包含什么很多人学了几个月Git还是在靠“记住命令”硬撑今天clone明天push遇到冲突就慌了神。我最早也是这个状态直到有一次我把一个项目的.git目录不小心部署到生产服务器上被人直接下载了源码才真正意识到Git不是“几个命令的组合”而是一套覆盖代码从出生到上线的完整生命周期管理系统。这篇文章我打算从一个项目的真实案例出发把Git全生命周期里的所有关键节点过一遍环境搭建、配置与免密、本地版本库的日志与回退、分支管理与冲突处理、rebase和储藏再到远程仓库协作、标签发布甚至连如何自己搭一台Git服务器都讲清楚。适合两种人看一种是刚接触Git、对命令一知半解的新手另一种是已经用了几个月但遇到分支合并、版本回退、冲突解决时心里没底的同学。文章里所有的命令我都按实际场景写带参数说明也会写我踩过的坑照着操作基本能跑通。2. 环境准备是第一步Git安装、配置与免密登录2.1 Windows与Linux安装别在这块浪费时间如果你用的是Windows最常见的安装方式就是去官网下载安装包。官网下载慢的话国内有很多镜像源可以用搜“git国内镜像”一般能直接找到企业级镜像站点下载速度能快不少。安装的时候有一步很关键选择调整PATH环境变量的方式一定选“Git from the command line and also from 3rd-party software”否则后面你在CMD或者VS Code终端里会提示“git无法识别”。还有个小细节行尾转换的设置建议选“Checkout as-is, commit as-is”也就是不自动转换换行符。Windows和Linux的换行符不一样如果选错了同一个文件在不同人手上改一次就会产生一堆没必要的diff排查起来非常痛苦。Linux下则简单得多。Debian/Ubuntu系直接用apt安装就行版本可能不是最新的但稳定够用如果想用最新版就得走源码编译。编译Git并没有想象中复杂核心依赖是make、gcc、libssl-dev、libcurl4-openssl-dev、zlib1g-dev缺一不可。抄一段我给Debian服务器装Git用的命令sudo apt install -y make gcc libssl-dev libcurl4-openssl-dev zlib1g-dev wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.40.1.tar.gz tar -zxvf git-2.40.1.tar.gz cd git-2.40.1 make prefix/usr/local all sudo make prefix/usr/local install git --version编译过程大约五分钟期间如果报错大多是缺依赖包缺什么补什么就行。装完之后一定要执行一下git --version确认版本很多坑都源于系统里同时存在多个Git版本。2.2 全局配置和SSH免密配置一次就够装完第一件事就是配置身份信息。这个不配会怎样提交的时候Git会用你机器的主机名加一串随机字符作为提交人到后面看日志你会看到一堆不明来历的提交记录根本分不清是谁写的。git config --global user.name 你的名字 git config --global user.email 你的邮箱这里有一个进阶玩法如果同一台机器上有多个Git账号比如公司用GitLab自己用Gitee不要全用global。可以在项目目录里单独执行git config user.name和git config user.email不带--global这样只对当前仓库生效。判断当前仓库有效配置用git config --list会先显示全局配置再显示本地配置本地配置会覆盖全局配置。接着是SSH免密配置。为什么强调这个因为你不想每次push都输入一次账号密码尤其是高频提交的时候输入密码会打断思路。生成密钥的方式ssh-keygen -t rsa -b 4096 -C 你的邮箱生成过程中会问保存路径和密码直接回车使用默认路径、空密码就行。然后去用户目录.ssh文件夹下找到id_rsa.pub文件把内容复制到GitHub/Gitee/GitLab的SSH公钥设置里。测试连接用ssh -T gitgitee.com看到成功欢迎信息就说明通了。免密配置中最常见的问题就是“为什么我配了还是让我输密码”。排查顺序第一看当前仓库的远程地址是不是SSH格式git开头而不是HTTPS格式第二确认密钥文件权限Windows下一般没问题Linux下私钥文件权限不能是644必须是600第三确认你用的平台和公钥是否一一对应很多人把GitHub的公钥复制到Gitee上当然连不通。2.3 关于.git目录泄露这个坑一定要规避Git本地仓库根目录下会生成一个.git文件夹里面保存了完整的历史记录。很多人在部署项目时图省事直接执行git clone拉代码到服务器或者本地打包的时候把.git目录也带上传到Web服务器这就是所谓的“git目录泄露”。只要攻击者访问到http://你的域名/.git/config就可以下载整个.git目录再用工具重构出全部源码和历史版本。我见过不止一个团队因为这个问题导致核心代码被人扒走。规避方法其实很简单线上部署一律不拉.git目录用代码包或CI/CD发布如果必须用git拉代码在Web服务器的配置里显式禁止访问.git路径。这一点属于多年实战经验换来的教训希望你不要像我一样靠踩坑记住。3. 本地版本库实战日志、版本回退与标签3.1 初始化到第一次提交整个生命周期从本地版本库开始。新建一个项目目录进入后执行git init就建立了一个本地仓库。这时候如果输入git status你会看到一堆Untracked文件意思是你还没告诉Git该跟踪哪些文件。git init git add . git commit -m feat: 初始化项目git add .会把当前目录下所有未被忽略的文件加入暂存区。我只用到.gitignore某次忘记把node_modules加进去结果提交了数万个文件仓库直接膨胀后续每次操作都变慢。所以第一件事永远是先写好.gitignore再git add尤其是IDE配置目录、依赖目录、编译产物、本地环境配置文件全部忽略掉。3.2 回到过去git log、git reset与git revert的区别git log是查看提交历史的入口。带参数看更高效git log --oneline --graph --all --decorate这条命令能把所有分支的关系以图的形式展示出来分支分叉、合并一目了然。版本回退是新手最容易搞混的知识点。本质上你需要理解三个地方工作区你正在编辑的文件、暂存区git add后存放的位置、版本库git commit后生成的历史节点。git reset --soft HEAD~1只把HEAD指针回退到上一个版本工作区和暂存区的文件都不动相当于撤销commit但保留更改。git reset --hard HEAD~1直接丢弃所有更改包括工作区的内容回到上一个版本的快照。git revert commitId不移动指针而是产生一个新的提交把该提交之前的变更反向应用回去。实际项目里如果代码还没有push到远程回退用reset比较方便一旦已经push了且别人可能已经拉取了这时用revert更安全因为它在历史上留下了一条“撤销”的记录后续合并不会被旧更改干扰。我记得有一次重构项目时误删了一个功能模块当时发现得比较晚开发分支上已经有几十个提交了。翻git log翻到删除提交的commitId用git revert加了反向恢复一点都没影响到别人的工作。3.3 标签发布版本的锚点分支会随着开发不断变化如果上线遇到问题想快速回到发布时刻的代码就得靠标签。标签相当于给某个提交打上固定的名字一般用semver语义化版本号管理git tag -a v1.0.0 -m 发布1.0.0版本 git push origin v1.0.0-v后加参数是因为我要用附注标签保存打标签的人、时间、说明。轻量标签不带注释日常临时标记还行要当发布锚点不够严谨。拉取远程标签用git fetch --tags删除标签用git tag -d v1.0.0同时还要删除远程的git push origin :refs/tags/v1.0.0。我习惯在上线前打一个tag这样出问题时直接在tag上开fix分支修完后重新发patch版本思路非常清晰。4. 分支管理实现多线并行开发的核心能力4.1 分支的创建、切换与合并分支的底层其实就是指向某个提交的指针创建成本极低所以Git才鼓励你频繁使用分支。实际场景里每个人的工作区应该是一个独立的功能分支而不是所有人在main上开发。git branch feature/login git checkout feature/login # 或简写 git checkout -b feature/login切换分支之前一定要git status确认工作区是干净的否则未提交的修改会跟着分支跑轻则造成混乱重则把半成品带到别的分支上。合并分支是分支管理里最高频的操作git checkout main git merge feature/loginGit默认会用Fast-forward模式合并就是直接移动指针不产生合并节点。如果你希望保留分支合并的痕迹要加--no-ff参数这在大型项目里更常用因为可以看到清晰的分支历史。4.2 冲突处理别慌冲突只是Git在保护你最让新手头疼的就是合并时出现CONFLICT提示。我的看法是冲突不是事故而是Git在告诉你“这里两边修改有重叠我无法自动判断谁对谁错”。这时Git会在冲突文件里插入类似这样的标记 HEAD 这是合并前当前分支的代码 这是另一个分支的代码 feature/login手动处理后删掉标记行再git add和git commit就能完成合并。还有一个细节判断合并时出现冲突如果你对某一方的代码不熟不要硬合。先和同事沟通或者看git log和git blame确认每段代码的意图。我曾经因为“自认为很熟”直接合掉了同事的重构分支结果丢了一段逻辑后来测试阶段才发现代码审查时被狠狠diss了一回。4.3 rebase与stash两个被低估的实用命令merge和rebase是两条完全不同的分支合并思路。merge保留分叉历史rebase则是把当前分支的提交“平移”到目标分支的最新提交之上让历史变成一条干净的直线。git checkout feature/login git rebase mainrebase最有价值的用法不是代替merge而是在提交Pull Request之前把目标分支的新提交同步到自己的分支提前解决冲突让最终合并时一条命令就完事。rebase也有坑不要对已经push到远程的分支执行rebase因为它会重写提交ID一旦别人已经拉过这个分支会造成两边历史不一致。真遇到这种情况大概率需要强制推送协作上很危险。再说stash这个命令专门处理“临时切换分支但暂存区和工作区不能丢”的场景。比如你在feature分支改了三个文件突然要切回main修一个线上bug但改动还没完成不想提交。执行git stash # 切走、修改、提交回来 git stash pop改动就完整回来了。需要保存多个stash条目时就加上备注git stash push -m WIP: 登录模块。恢复时指定编号git stash list查看git stash pop stash{0}恢复。如果应用stash之后发现冲突解决方式跟merge冲突完全一样。5. 远程仓库协作从克隆到发布的全流程5.1 克隆、远程分支与推送拉取远程仓库是团队协作的基础。把本地仓库和远程关联有三种方式clone已有仓库、远程仓库为空时add remote、以及远程仓库存在但本地还没有任何内容时fetch下来再track。最常用的是git clone gitgitee.com:你的账号/项目名.gitclone下来的仓库会自动创建一个指向远程的别名叫origin。查看关联关系用git remote -v。如果要换远程地址或加多个远程比如同时关联GitHub和Gitee用git remote add或者直接修改.git/config文件。推送拉取是整个章节里最需要理解清楚的动作git push把本地已有提交推到远程分支。git pull等于fetch加merge先拉取远端更新再合并到当前分支。git fetch只下载远程数据不改变本地工作区。工作中我常跟团队说pull之前先看看自己的分支和远程分支有没有分叉git fetch之后再git log --oneline origin/main看看。因为git pull自动执行merge远程更新如果波及了你正在改的文件会直接产生合并节点甚至冲突让人莫名其妙。拉取远程的新分支也是一样的道理git fetch origin git checkout -b feature/login origin/feature/login这样就在本地创建了一个跟踪远程分支的新本地分支。后续push和pull就不用带参数了Git会自动关联。5.2 合并远程分支与rebase的协作流程团队协作中纯靠merge会让历史变乱两步走是我推荐的协作方式开发完功能后先rebase一下远程的最新commit到自己的分支解决本地冲突后再push。推送的时候如果远程分支有更新的提交Git会拒绝报“non-fast-forward”错误这时候不要直接加--force强推先pull --rebase同步远程代码然后重新提push。有次我在一个共享分支上执行了git push -f结果把同事刚推上去的修复直接覆盖了。那次事故让我记住了共享分支上永远不要用force push。如果用rebase改写历史也必须明确这个分支是你专属的功能分支不会影响别人。5.3 搭建自己的Git服务器当项目涉及隐私且不想用公有平台时自建Git服务器是最后的归宿。最轻量的方式是利用Git自带的裸仓库协议通过SSH访问。基本原理在服务器上创建一个--bare的裸仓库它没有工作区只保存历史数据然后本地克隆或添加远程地址push到这个仓库。# 服务器上 mkdir /srv/git/project.git cd /srv/git/project.git git init --bare # 本机上 git remote add origin ssh://用户名服务器IP/srv/git/project.git git push -u origin main走SSH协议不依赖额外服务进程只要有账号和SSH服务就能用。但只有裸仓库的Git服务器没有权限管理和Web查看界面团队大了之后体验很差。这时就该上GitLab或者Gitea。Gitea部署非常轻量适合小团队GitLab功能全但吃内存4G以下内存的服务器跑起来很吃力。我在生产环境部署过一台Gitea整个过程半小时搞定用户管理、仓库权限、Web控制台全都具备。之后团队就彻底告别“通过共享文件夹传代码”的模式了。6. 常见问题速查那些排查到怀疑人生的错误6.1 命令执行报错git无法识别这个问题高频出现在Windows环境。在CMD里输入git返回“git无法将‘git’项识别为 cmdlet、函数、脚本文件或可运行程序的名称”原因八成是安装时忘了勾选“Git from the command line”或者安装后PATH没有刷新。解决方案重新安装Git安装时选择把Git加入PATH如果不想重装手动把Git的cmd目录如C:\Program Files\Git\cmd加入系统环境变量。如果是在VSCode的终端里遇到这个问题还要注意终端可能没有继承最新的PATH重启VSCode或者重开一个终端窗口就能解决。6.2 push/pull时的认证失败login failedcheck api token or gitlab version这条报错常见于用IntelliJ IDEA或VS Code的Git插件连GitLab时。它看起来像是Git证书的问题实际与Git本身关系不大。印象里IDEA 2021版本的GitLab集成插件对GitLab版本有一定的兼容性要求版本过旧时就会提示“login failed. check api token or gitlab version”。排查思路第一步在终端手动执行git pull/push确认Git本身的认证是正常的排除SSH和HTTPS凭据问题第二步如果终端正常就检查IDE的GitLab设置确认填写的是Personal Access Token而不是Git密码。GitLab的新版本大多要求用Token方式来认证密码登录已经被禁用了。6.3 查看中文文件名出现转义core.quotepath特殊场景Linux服务器上Git提交了中文文件名在Windows克隆下来后显示成“\346\265\213\350\257\225”或者反过来。这是因为Git默认把非ASCII字符转义了。解决命令git config --global core.quotepath false设置后就会正常显示中文文件名。这个参数在实际协作中很容易被忽略很多人在提交记录里看到一串八进制数字还以为文件出错了。上面这条经验也提示了一个细节很多“疑难杂症”本质上只是Git的默认安全设置了解参数含义比死记硬背命令更有价值。6.4 忽略文件怎么配置推荐给出常用模板.gitignore的作用是让Git自动忽略指定文件或目录。我给出一个通用模板适配大部分前后端项目# 依赖目录 node_modules/ vendor/ # 编译产物 dist/ build/ target/ # 日志 *.log logs/ # 系统文件 .DS_Store Thumbs.db # 环境配置 .env .env.local编写时有个容易忽略的细节如果你执行git add之后才发现忘了忽略某个文件直接修改.gitignore是没用的因为该文件已经在版本库的跟踪名单里了。需要先把对应文件移出跟踪git rm -r --cached node_modules git add .gitignore git commit -m chore: 移除误提交的node_modules--cached参数很重要它只移除跟踪关系不会删除磁盘上的文件。这个操作在生产环境维护中也经常用到比如发现某个conf文件包含服务器地址而不该提交时就用它把文件摘出版本控制。7. 写在最后几个我养成的Git使用习惯前前后后用Git有八九年了踩过的坑远比这篇文章写到的多得多。最后分享几个自己一直在用的习惯未必适合所有人但确实帮我省了不少事。第一提交信息尽量写清楚“为什么”而不是“干了什么”。“修bug”这种提交信息没有任何检索价值等三个月以后回来翻历史你根本不知道改了什么。我自己的提交格式偏向于feat(模块): 具体描述。feat表示新功能fix表示修复chore表示杂项docs表示文档更新。这是一个非常轻量的约定没有任何工具强制但团队达成一致之后效率会提高很多。第二push之前自查三件事git status是不是干净的、git log是不是已经包含了最新变更、分支名是不是对的。我在生产环境见过有人把功能分支的代码推到main就是因为没有检查分支名。多一秒钟的自查能省掉后面一整天的恢复操作。第三不要怕用强制推送但一定要清楚它的适用范围。自己专属的分支怎么rebase怎么改历史都无所谓一旦涉及共享分支强制推送绝对说“不”。如果确实需要修正共享分支的历史让大家停下手头的工作集中同步再走一次干净的流程永远比强行覆盖安全。第四也是最重要的一点Git是帮助你理解代码演变的工具不是束缚你的命令手册。当你理解了提交、指针、索引这几个核心概念后所有命令都能推导出来不再需要背。把精力放在理解模型上比背一百条命令更值钱。