为什么你改了代码，服务器上一动没动
不少人在本地把代码改得热火朝天，推上去之后跑到服务器上一看，还是老版本，多数情况下不是操作失误，而是你压根没理解git的工作方式。git只负责记录版本和同步历史，本身不会自动把服务器上的工作区变成你想要的样子，想让代码和服务器一致，本质上是在远程仓库、本地仓库和服务器三个节点之间完成一次方向明确的对齐。
场景很常见：你在本地提交了三次，git push成功，登录服务器执行git pull，结果提示Already up to date，你心里犯嘀咕，明明改了一堆东西，更新在哪？这类问题大多出在服务器上的分支和远程分支已经分叉,或者服务器上有人在错误的分支上做了提交。
快速让服务器代码回到和仓库一模一样的基准线
先确认服务器当前处于哪个分支
在服务器项目目录下执行：
git branch --show-current
这个命令直接告诉你当前在哪个分支上，如果显示的不是你希望同步的分支，先用git checkout切换到目标分支，不少人在这里翻车,搞了半天发现一直在别的分支上拉代码。
拉取远程最新状态，不急着合并
git fetch origin
fetch和pull的区别在于，fetch只把远程的提交记录下载下来，不会动你当前的工作区，这一步的意义是让服务器知道远程仓库现在有哪些新东西，但还没决定怎么处理本地状态，很多git教程跳过这一步直接pull,遇到冲突时就懵了。
用reset硬重置到远程分支的状态
这是让代码和服务器一致的核心操作：
git reset --hard origin/你的分支名
reset –hard会把当前分支的HEAD直接指向远程分支的位置，同时把工作区和暂存区的文件全部替换成远程版本的内容，执行完之后，服务器上的代码和远程仓库完全一致，本地任何未提交的改动都会被丢弃，这一条要心里有数。
清理掉那些多余的文件
有时候你的服务器上存在远程仓库没有的文件，可能是之前手动上传的配置，也可能是测试生成的临时文件，reset不会删除这些文件,如果想让服务器做到真正的干净：
git clean -fd
这条命令会删除所有未被git跟踪的文件和目录，执行之前建议先跑git clean -ndf看看会被删掉哪些东西，确认无误再动手。
不建议在存有重要配置文件的目录里盲目执行clean，比如某些生产环境下的.env文件,一旦删除很难恢复。
怎么避免本地和服务器之间越搞越乱
很多人遇到的问题是：本地有提交，服务器也有提交，两边都对远端有差异，强行同步直接冲突,这里提供几种比reset更稳妥的处理方式。
用stash保存临时改动
服务器上有时会有一些正在改但没改完的文件，这类改动可能不想提交，但也舍不得丢,先执行：
git stash
把当前未提交的改动暂存起来，工作区回到干净状态，然后执行git pull拉取最新代码，最后用git stash pop把改动重新应用回来，这个流程避免了reset –hard带来的全量覆盖,适合服务器上确实有在途修改的情况。
重建分支来对齐远程状态
当服务器本地分支的历史已经乱到理不清时，与其费力解决冲突,不如换个思路：
git branch -m 旧分支名 备份分支名 git checkout -b 你的分支名 origin/你的分支名
第一步把现有分支改名保存下来，第二步基于远程分支重新创建一个干净的分支，这样做的好处是保留了原有的杂乱分支作为备份，同时又让当前分支和远程完全同步，在代码一致性这件事上，果断一点往往比小心翼翼更省事。
更温和的pull方式：rebase
如果你倾向于保持提交历史的整洁，又不希望暴力重置,可以尝试：
git pull --rebase origin 你的分支名
rebase会把你本地的提交暂时挪开，拉取远程提交后再把本地提交重新放回去，相比merge，它生成的历史是一条直线，不会有分叉的记录，但rebase遇到冲突时需要逐个解决,处理起来需要一些耐心。
git 本地代码和远程仓库不一致怎么解决：从错误提示入手
常见的错误提示长这样：error: Your local changes to the following files would be overwritten by merge，这句话的意思是本地工作区有未提交的修改，而远程分支也想改同一个文件，git为了避免覆盖你的劳动成果，直接拒绝合并，这个提示出现时别慌，它不算系统错误,只是git的自我保护机制生效了。
处理逻辑很简单：要么先提交，要么先丢弃,要么先暂存。
# 方案一：提交本地改动 git add . git commit -m "保存本地修改" # 方案二：丢弃本地改动（确认不再需要时执行） git checkout -- 文件名 # 方案三：暂存起来，后面再恢复 git stash git pull git stash pop
选择哪种方案取决于你本地改动的价值，如果只是一些临时调试代码，丢弃最快；如果是重要功能,提交或暂存更合适。
日常部署中维护代码一致性的几条经验
结合业内的实际部署场景,有几个操作习惯值得养成。
在服务器上尽量少做手动改动，很多人习惯直接在服务器上改代码调试，改完也不记录，等下次部署时服务器和仓库就分叉了，正确的做法是在本地改完推送到仓库,服务器只负责拉取。
发布前记录当前版本号，执行git rev-parse –short HEAD记录下当前部署的版本，发布后对比这个值就能快速断定代码是否真的更新了，很多部署事故其实只是看错了版本号,代码本身没问题。
了解你的部署流程是哪种类型，如果你用的是宝塔面板这类可视化工具，它们通常自带git同步功能，底层原理还是拉取远程代码，如果你是纯命令行操作，上面的命令直接适用，需要留意的是，部分国内的云服务器厂商提供的git相关服务有缓存机制，推送后不一定立刻可见,建议等多十几秒再在服务器上拉取。
推送过了却发现服务器还是旧代码，还要检查这几个地方
- 服务器上是否有本地commit领先于远程分支，导致git pull产生分叉
- 是否推送到正确的远程仓库地址，执行git remote -v查看
- 分支名是否一致，比如你本地是main，服务器上还在用master
- 是否有CI/CD流水线在中间环节做了额外处理，比如自动构建后没有同步到目标目录
有相当一部分人遇到的“同步不上”问题，其实是把代码推送到了自己fork的仓库，而服务器连接的是原始仓库,这类问题不看remote配置永远发现不了。
一个不太常见但确实存在的坑：git安全目录限制
某些服务器环境（尤其是较新版本的git和root权限配合时）会出现拒绝执行git命令的情况，提示detected dubious ownership in repository，这是git出于安全考虑加的防护机制,解决办法是：
git config --global --add safe.directory /你的项目目录
注意这条命令要配置到服务器上执行git操作的用户下，如果用root登录就配root的全局配置,如果用www用户就配www的。
git 代码同步到服务器的最佳操作顺序是什么
考虑到实际部署需求，一套稳妥的操作路径是先备份现状，再清理差异，最后做验证，业内专家指出这套流程在生产环境下的容错率最高,建议在服务器上按以下顺序操作：
cd /你的项目目录 git status # 查看当前状态 git stash # 暂存未提交的改动（如果有） git fetch origin # 获取远程最新状态 git reset --hard origin/你的分支名 # 强制同步 git clean -fd # 清理多余文件（谨慎使用） git log -1 # 确认当前版本
这套组合让服务器直接指向远程分支的最新提交，同时工作区和暂存区彻底清空，版本号确认无误后，再重启服务或执行构建命令，代码和服务器就完全对齐了，如果你用的是国内主流的LAMP或LNMP环境，数据库或配置文件不在git管理范围内，这部分内容不会受影响，git只管代码文件的版本状态。
常见疑问解答
git强制覆盖本地代码会不会把服务器搞坏
只要你的项目目录在git版本控制下，强制覆盖只是让文件回到某个历史状态，如果改坏了，还能用git reflog找回之前的提交记录重新reset回去，真正要防范的是git clean误删了未跟踪的配置文件，所以clean之前务必先看dry-run的清单。
git pull和git fetch+reset效果一样吗
不一样，git pull等于fetch加merge，它会保留你本地的提交历史，遇到冲突时产生一次合并提交，而git fetch加git reset –hard是彻底放弃当前状态，直接对齐远程分支。想让代码和服务器一致且不做本地保留时，后者更可靠；既要更新代码又要保留本地修改时,前者更合适。
服务器上的git版本太旧怎么办
先执行git –version确认版本，如果确实过旧，一些新命令或参数可能不可用，常见处理方式是通过包管理器升级，比如yum update git或apt-get update && apt-get install git，如果服务器是CentOS这类老系统，默认仓库里的git版本可能较低，可以考虑编译安装或添加第三方源，多数云服务器厂商的基础镜像中的git版本足以满足日常同步需求，除非你用到较新的特性,否则不建议直接源码编译。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/700556.html
