Deployment分支领先master分支：如何优化Git部署合并流程？

嘿，这个问题我之前也踩过坑！本质是你每次合并master到deployment时，用了Git默认的非快进合并（--no-ff），导致每次都生成一条额外的合并提交，久而久之deployment就比master多了一堆无意义的记录。下面给你几个靠谱的解决方案，按需选择：

1. 用快进合并（Fast-Forward）保持历史干净 #

如果你的deployment分支平时没有自己的独立提交（除了之前从master合并来的内容），快进合并是最优解——它不会生成新的合并提交，让deployment的提交历史和master完全对齐：

# 切到deployment分支
git checkout deployment
# 只允许快进合并，如果deployment有独立提交会直接报错（避免乱合并）
git merge --ff-only master
# 推送到远程仓库
git push origin deployment

小提醒：如果deployment有自己的修改（比如临时的部署配置），--ff-only会失败，这时候你得先把这些修改迁移到master（比如cherry-pick），再回来合并。

2. 用Rebase变基替代合并 #

如果deployment有少量必须保留的独立提交，变基可以把这些提交“接”在master的最新提交后面，同样不会产生合并提交：

# 切到deployment分支
git checkout deployment
# 把deployment的提交变基到master的最新状态
git rebase master
# 推送到远程（因为变基修改了提交历史，需要强制推送，记得确认没人在这个分支上工作！）
git push origin deployment --force-with-lease

注意：强制推送要谨慎，最好只在你独自维护deployment或者团队成员都清楚变基操作的前提下用，别不小心覆盖了别人的工作。

3. 精准部署用Cherry-Pick #

如果有时候你不想把master的所有提交都部署，只想挑特定的几个上线，那cherry-pick就很合适：

# 切到deployment分支
git checkout deployment
# 把master上指定的提交应用到deployment
git cherry-pick <你要部署的提交哈希值>
# 推送到远程
git push origin deployment

这种方式适合分批部署的场景，但如果是全量部署的话，前面两种方法更高效。

4. 重构分支流程（长期最优方案） #

其实最省心的是把deployment变成只读的部署分支——永远不在上面直接修改，每次部署时直接把master的内容推过去覆盖：

# 先确保本地master是最新的
git checkout master
git pull origin master
# 直接把master的内容推送到deployment分支（强制覆盖）
git push origin master:deployment --force-with-lease

这种方式彻底消除了合并提交的问题，deployment的历史永远和master完全一致，干净清爽。

总结一下：如果deployment没独立提交，优先用快进合并或直接推送master到deployment；有少量独立提交就用rebase；需要精准部署用cherry-pick。长期来看，把deployment设为只读分支是最省心的选择。

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