我在本地(在我自己的分支中(开发我的应用程序，但我只能在远程开发服务器上测试它，方法是推送到服务器上的 git 存储库(我自己的分支(，然后在那里测试工作副本。
由于我找不到我的 Web 应用程序崩溃的原因，我想找到最后一个"良好"状态以了解原因。我想过使用git bisect.但它只改变了本地存储库的状态，而不是源，我无法在本地测试它是否有效。那么我应该怎么做才能轻松地在远程分支上检查不同的提交(不要在提交历史记录中造成太多混乱(？
如果我理解正确，您可以在本地开发应用程序，但您只能在远程服务器上测试它，方法是推送到服务器上的 git 存储库(然后在那里签出工作副本，我想(。
在这种情况下，您必须在远程系统上的工作副本上运行git bisect。 git bisect不会创建新的提交或新的分支，它只是检查出不同的提交(从而将您置于"分离的 HEAD"状态(。因此，您不能将git bisect创建的中间状态推送到远程(从技术上讲，您可以，但每次都必须强制推送，然后无论如何您都需要在远程工作副本中修复内容，所以这对您没有帮助(。
但正如我所看到的(如果我没有正确抓住这个想法，请纠正我(，git bisect 仅更改本地存储库的状态，而不是源。
是的，没错。确切地说，它只更改当前在本地工作副本中签出的提交。
博士：
登录到远程服务器，然后在那里运行git bisect。如果您只能通过推送到那里来访问服务器，那么您只能靠自己 - git 不支持这一点(至少不是没有一些丑陋的黑客(。
由于我只能通过推送到那里来访问服务器，最后我通过创建一个新的 bugsearch 分支并切断那里的提交来找到有毒提交：
git checkout -b konst54bugsearch
git reset --hard HEAD~1
git push origin +konst54bugsearch
[check the app, repeat reset and force push]
(实际上我可以做一些类似git reset --hard HEAD~20的事情来估计错误的位置，比如平分，但我知道它不会太远(。
当我找到提交时，我在 konst54 分支中恢复了它，在我的分支中得到了一个具有相当干净历史记录的工作应用程序，并计划现在删除混乱的 konst54bugsearch 分支。