git：比定期推送重新定位的分支更好的选择答案

【问题标题】：git: better alternative to regularly pushing a rebased branchgit：比定期推送重新定位的分支更好的选择
【发布时间】：2012-10-05 09:15:38
【问题描述】：

我有一个网站的 git 存储库，其中 master 分支代表生产代码。我被要求设置网站的“沙盒”版本，供系统的潜在用户进行试验，这样他们就不必在生产系统中这样做。

由于站点的沙盒版本需要明确标记，并且禁用了某些功能，因此我创建了一个沙盒分支（基于 master）并在那里进行了一些提交以添加警告消息等。

然后我将两个分支都推送到上游，并在 Web 服务器上签出了单独目录中的每个分支 - 一个用于生产，一个用于沙箱。

这很好，但是当我想编写更多代码时问题就来了。一旦我将代码提交到主分支，它将在生产系统中更新，但沙箱不会看到新代码。因此，我将沙箱分支重新设置为 master，因此沙箱的提交始终位于生产之上。但是当然，一旦我这样做了，我就不能再将沙箱分支推向上游，因为它不再是快进。我必须登录 git 服务器，切换分支，进行软重置，然后重做推送。

用 git 肯定有更好的方法吗？我真正需要的是在当前签出的任何分支之上持续应用一些提交的某种方式。

【问题讨论】：

你尝试过任何提交挂钩吗？
@J-16SDiZ：不，我希望我可以使用 git 的内置功能来做到这一点，所以如果存储库移动，我不必记得复制挂钩。
沙盒服务器上的挂钩，我的意思是。你还没有一些 CI 基础设施吗？沙盒如何更新？
@J-16SDiZ：我明白，但我的意思是如果我必须将 Web 文件移动到其他地方，我希望我可以在新位置执行 'git clone' 而不必记住再次设置挂钩。钩子非常适合自动化手动任务（如果钩子失败，您可以手动执行它们），但我不喜欢因为钩子失败而丢失代码的想法！
您知道您可以使用git push remote +branch 进行非快进推送吗？然而，接收 git 存储库可以配置为拒绝这些。

标签： git branch push

【解决方案1】：

您可以使用git push remote +branch 进行非快进推送。但是接收 git 存储库可以配置为拒绝这些。

但是，如果您对旧版本的分支进行了编辑，但已将重新定位的版本推送到上游，您可能会遇到一些小问题。解决此问题的一种方法如下：

# you are on branch X and origin/X has been force-updated
git branch X-tmp   # keep a reference to your new commits
git fetch origin
git reset --hard origin/X   # now X is the same as origin/X

# now you have two options
# option 1: move the new commits from X-tmp to X by cherry-picking
# them one-by-one
git cherry-pick abc123
git cherry-pick def456

# option 2: this rebase should do the right thing and detect the equivalent
# commits in X and X-tmp
git checkout X-tmp
git rebase X

【讨论】：

这不是一个坏主意——因为你不能（或不应该）推入工作树，我有一个脚本可以在目标工作树中执行git pull。所以我可以将其更改为git reset && git pull 的形式，因为该树永远不会有需要保存的额外提交。

【解决方案2】：

我会以不同的方式执行此操作，方法是让两个代码路径都存在于 master 分支中。

例如。使用一些配置文件（不受版本控制），您可以切换到其他代码路径。或者一些环境变量——最适合你的。

【讨论】：

没错，这就是我为开发/生产版本所做的（例如，开发版本不会向真实的人发送电子邮件。）由于沙盒只是临时的，我希望我可以通过在完成后删除该分支来避免永远保留沙箱代码。