同一服务器上两个非裸Git仓库的协作方案咨询

1. 直接推非裸仓库的风险 #

直接推送到非裸仓库的当前分支确实不推荐，核心原因是：

• 推送仅会更新远程仓库的分支指针，但不会同步更新它的工作区和暂存区，导致远程仓库的工作目录与分支状态脱节，后续操作极易出现冲突、文件状态混乱的问题。
• 除非你能100%确保远程仓库工作区干净（无未提交修改、与当前分支完全一致），否则推送后大概率会留下一堆难以排查的状态问题。

2. receive.denyCurrentBranch updateInstead 的实际作用 #

这个配置是Git提供的妥协方案：当推送到非裸仓库的当前分支时，Git会自动将新提交同步到远程仓库的工作区（相当于在远程执行了安全的checkout+merge操作），同时强制保持工作区干净。

• 适用场景：单人维护的极小项目、远程仓库仅作为同步节点而非协作中心，且能确保推送时远程无未提交修改。
• 局限性：如果远程仓库存在未提交的本地修改，操作会直接失败；多人同时推送时，依然可能出现状态冲突，本质上还是绕开了Git的标准协作设计。

3. 最优方案：回归裸仓库模式 #

如果项目有多人协作的可能，或想彻底规避状态混乱风险，建议创建裸仓库作为协作中心，标准流程如下：

• 在服务器创建裸仓库：git init --bare projectx-bare.git
• 将你的projectx本地仓库远程指向裸仓库：git remote add origin /path/to/projectx-bare.git，推送所有分支：git push -u origin --all
• 让dev仓库从裸仓库克隆：git clone /path/to/projectx-bare.git dev
• 后续dev提交后推送到裸仓库，projectx（prod环境）直接从裸仓库拉取合并：git pull origin main（假设主分支为main）

这种模式是Git原生设计的协作流程，完全避免了非裸仓库推送的状态不一致问题，多人协作也更安全可靠。

4. 小型项目的临时同步方案（无需裸仓库） #

如果是单人维护的极小项目，不想搭建裸仓库，还有两个更稳妥的同步方式：

• 方式一：在prod仓库主动拉取dev变更
  在projectx（prod）目录下添加dev为远程仓库：git remote add dev /path/to/dev，然后拉取合并：git pull dev main，这种方式会自动同步prod的工作区，不会出现状态脱节。
• 方式二：用git bundle打包变更
  在dev目录打包分支变更：git bundle create projectx-update.bundle main ^origin/main（打包main分支相对于origin的新提交），将bundle文件复制到prod目录后执行：git pull projectx-update.bundle main，适合无直接文件共享的场景，完全规避推送冲突。

内容的提问来源于stack exchange，提问作者phunsoft