比方说，一个项目 ~/my-project ，有三个代码库：
要保持本地仓库与个人 GIT 服务器上的代码一致，但提交给与公司 /甲方服务器上的代码为魔改后的代码
目前是，本地代码 push 到公司服务器之前，运行一个脚本，对代码进行一些魔改（比如替换某些变量名），同样的，从公司服务器 poll/fetch 下来代码后，再运行另一个脚本进行反向操作，去掉代码的魔改（把变量名恢复），然后本地编写代码，抗投诉服务器下次再 push 时，再次魔改，周而复始。
然而如此操作的话，会有诸多不便，比方说，当 git diff 比较本地代码与公司服务器远程代码时，比较的是未魔改的代码与魔改后的代码，会提示大量无用信息。
有无方便的操作方式？
魔改进分支，每次 rebase 主干。
在你的场景下，最简单的是把要对比的代码先 clone 到本地，改回来(到未魔改的版本)再对比
有点理解不能，给公司的代码增加复杂度降低可读性以提高自身不可替代性？
按你的例子，比较本地代码与公司代码前把本地魔改一下不就可以了，
多建分支，早建分支，多用分支
应该把可变化的部分抽象出来，使用环境变量或者配置文件来控制。而不是什么魔改，给自己增加心智负担。
push 到个人服务器后再魔改，然后 push 到甲方服务器，最后本地删掉，从个人服务器上面 clone 回来？？？
你所说的魔改是固定规则吗？
你需要的是“实时”吗？
感觉这些是不是可以写成配置？
代码是一套的。然后配置不一样？
这样应该不要用分支，rebase 也不行吧，历史记录里还是有原始代码。
应该搞一个单独的仓库，从你源仓库同步过去以后再混淆，然后再把这个仓库推到公司服务器。这样和你自己的历史记录也可以隔离开，可以攒一大堆修改，混淆后只向公司提交一个 commit 。
另外仅仅混淆变量名是不够的，推荐进修一下 https://coderlmn.github.io/frontEndCourse/unmaintainable.html
有效降低效率减少内卷。
git format-patch master --stdout > my-patch-file.patch
做成 patchfile 每次 apply 一下
一个本地仓库不行，搞两个。一个是真实的开发仓库，一个是仅上传给甲方的仓库。
魔改的库直接派生你基础的库, 需要定制的直接就虚函数重载写不就可以了. 做一个类工厂, 实例化的时候根据需要创建基础的库 还是魔改的库.
我觉得这个场景非常符合 fork 的开发模式