官方又发版了，git pull 合并Tigshop开源商城可以养成这个习惯

我给客户维护的 Tigshop 项目基本都做过二开，所以每次官方发新版，我从来不敢直接git pull覆盖上去。早年吃过一次亏，自己改过的 Service 被官方版本盖掉，排查了大半天，从那以后就养成一套固定动作。

先看官方到底改了什么

别急着合。进到php/目录，把上游拉下来对一遍日志，心里有数再动手：

cdphpgitfetch origingitlog HEAD..origin/master--oneline

一屏 commit 扫下来，是修 bug、加功能，还是动了数据库结构，大致能看出来。如果 release 说明里提到表结构变更，这次升级就得格外小心。官方仓库在 https://github.com/tigshop/Tigshop.git，配成 upstream 拉就行。

备份，两样都要

数据库导一份，代码打个 tag，缺一不可：

gittag before-merge-20260721

出事了能秒回退，别嫌麻烦。

用 merge，不用覆盖

我用 merge 不用 pull 覆盖，就是要让冲突显式暴露出来，自己一处处过：

gitmerge origin/mastercomposerinstallphp thinkclear

如果 release 里带了迁移脚本，按它的说明补一句php think migrate，别自己瞎猜命令。

冲突高发就三个地方：php/app/service/里你自己改过的业务类、根目录的.env、装修保存的那些 JSON 配置。合并时重点盯这几处，逐行看清楚再决定留谁的。.env尤其别被官方的示例配置盖掉，数据库密码、Redis、支付密钥都在里面。

二开量大的项目，长期开一条自己的分支，官方 master 只当上游来 merge，别在 master 上直接改代码，不然每次升级都是灾难。

合完先在测试环境跑主线

合并完别直接上生产。先在测试环境把下单、支付、后台这三条主线各点一遍，没问题再发。

还有个习惯：Tigshop 每次发版社区里都有讨论帖，先升的人会把坑贴出来。我一般等个一两天，扫完帖子再动手，比自己闷头 merge 稳当。