调试 Heroku 应用程序时如何避免大量提交答案

【问题标题】：How to avoid tons of commits when debugging Heroku app调试 Heroku 应用程序时如何避免大量提交
【发布时间】：2011-12-12 20:03:56
【问题描述】：

在尝试使用 Heroku 上的应用程序解决错误时，我通常会收到一堆与错误修复过程相关的 Git 提交，因为我需要提交更新才能推送到 Heroku。在推送到项目的主要共享仓库之前，是否有任何巧妙的方法来清理这些提交？

【问题讨论】：

只是好奇。您是否在开发和测试环境中将 PostgreSQL 用于您的应用程序？
请问您为什么需要删除它们？它们不是像其他任何东西一样的有效提交吗？

标签： ruby-on-rails git heroku

【解决方案1】：

在您开始调试时创建一个新分支（git checkout -b debugging 或类似的），然后在那里进行所有提交，通过 git push heroku debugging:master 将它们推送到 Heroku 而不是您的主控。

然后，当您解决了问题后，您可以将调试更改压缩到单个提交中并将它们合并回 master：

git checkout master
git merge debugging --squash
git branch -D debugging

还有很多其他方法可以做到这一点，这一切都归结为您认为最合乎逻辑的方法。

【讨论】：

坏主意。压缩是不好的，因为它会阻止 Git 推理压缩前和压缩后提交之间的连接。见paul.stadig.name/2010/12/…。
@MarnenLaibow-Koser 我认为在大多数情况下这是正确的，但这里进行如此多提交的唯一原因是因为它们必须测试它们是否正确——当你不知道你是否已经解决了问题时，你通常不会提交。如果甚至不需要提交测试，那么可能只有一个提交来解决问题。
我真的不认为这会改变反对挤压的论点。如果提交了，通常应该保留它们（特别是如果它们被推送到远程仓库）；否则，Git 无法正确跟踪祖先。然而，我确实认为，OP 应该找出一种在本地进行测试的方法，这样他就不必仅仅为了测试而推送到 Heroku。
@MarnenLaibow-Koser 在我使用 Heroku 的那段时间里，有时一切都在本地而不是远程工作。如果被推送到的远程仓库是由其他开发人员拉到的，那么是的，它永远不应该被覆盖，但是 Heroku 遥控器（通常）永远不会被拉出。我不同意那些一开始就没有多大意义的提交（尤其是其中的许多）应该被保留下来，因为它们可以被压缩成一个仍然很小且被包含在内的具有更大意义的提交。说“这可能会解决问题”的提交不是很有用或没有意义。
@MarnenLaibow-Koser 当问题完全出在远程服务器上——因此无法在本地测试——并且获得对服务器的更改的唯一方法是推送提交时，如何在提交之前测试某些内容？ ?这没有任何意义，再多的存储或部分提交也不会改变这一点。这就是我的观点：这是一个特例，应该这样对待。

【解决方案2】：

您可以执行git rebase -i <commit_before_fixing_commits> 并编辑/压缩/删除提交，然后推送到 Heroku。

【讨论】：

git rebase -i 存在问题，原因与挤压相同。

【解决方案3】：

您并不想清理这些提交。您想要做的是将它们封装在合并提交中：

签出大师——git checkout master
为您的主题创建一个分支 -- git checkout -b my-cool-bugfix
在您的分支上完成工作
准备好后，再次git checkout master，然后进行非快进合并。这是必不可少的：使用 --no-ff 选项强制非快进意味着将始终创建合并提交。在这种情况下，命令将是 git merge --no-ff my-cool-bugfix。
您现在在 master 上有一个合并提交，它封装了您的所有分支提交，但保留了提交历史，以便 Git 的历史分析工具不会中断。
测试修复后，git push heroku。

【讨论】：

为什么投反对票？如果你愿意解释，我很乐意解决这个问题。