好吧，我终于做到了，我正在发布答案，以便其他人在遇到相同问题时可以从中受益.

Ok, I finally made it and I'm posting the answer so that others can benefit from that in case they meet the same problem.

出现这种现象的原因显然是以前的OpenShift部署方法在中间中断了，这使齿轮处于不一致的状态(mysql2 gem的问题就是这种情况的一个征兆).我基本上试图做的是通过捆绑并从git HEAD重新构建，将其手动恢复到一致状态.

The reason for the behavior was apparently that the previous deployment approach in OpenShift broke in the middle, which left the gear in an inconsistent state (the issue with mysql2 gem was one symptom of that). What I basically tried to do is to bring it back to a consistent state manually by bundle'ing and re-building from the git HEAD.

这不起作用.

尝试从我的开发存储库中推送git也没有用，因为自上次推送以来没有任何变化(这显然是由于某些OpenShift内部错误而导致部署中断). 最后，我对包进行了一些更改(在本例中，通过bundle update更新了一个gem)和更新的Gemfile.lock. 由于我还签入了"force_clean_build"标记，因此随后的推送从头开始重新构建了齿轮，并且使其处于一致状态.

Attempts to push to the gear git from my development repository did not work either, since nothing has changed from the last push (which resulted in deployment that broke apparently due to some OpenShift internal bugs). What I did at the end, I made some change in the bundle (in my case updated one gem by bundle update) and this updated Gemfile.lock. Since I also checked in "force_clean_build" marker, the subsequent push rebuilt the gear from scratch, also having brought it to a consistent state.

长话短说，如果OpenShift部署在中间中断，***对源进行伪造更改并将其与标记force_clean_build一起推送到齿轮的git gear deploy HEAD而不是尝试手动重建，因为后者无法清除可能发生的不一致情况.

Long story short, if OpenShift deployment breaks in the middle, it is much better to make a fake change in sources and push them in conjunction with the marker force_clean_build to the gear's git than to try to rebuild manually by gear deploy HEAD, since the latter does not clean up the possibly occurred inconsistency.