我在 BitBucket.org 上有我的项目的中央(远程、原始)存储库。
在我的服务器上克隆实时存储库
在我的机器上克隆开发存储库
我在开发仓库上进行开发。并将许多提交推送到中央仓库。但实时存储库处于克隆/启动时的相同状态。
在所有开发工作最终完成之前，我不想在 Live 服务器上执行 git pull。
但是......我发现了代码中的一个错误；我必须立即在 Live 网站上修复该问题。所以我去了实时服务器(这是中央服务器后面的几次提交)并更改了代码。然后我暂存该单个文件并提交它。
现在，当我尝试将此提交推送到中央存储库(以便我可以 pull 开发存储库)时，我得到以下信息:
# git push -u origin master
Password:
To https://<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="86fefefec6e4eff2e4f3e5ede3f2a8e9f4e1" rel="noreferrer noopener nofollow">[email protected]</a>/xxx/xxx.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="552d2d2d15373c213720363e30217b3a2732" rel="noreferrer noopener nofollow">[email protected]</a>/xxx/xxx.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
我知道有人对快进有疑问。但是，我想我做错了。遇到这样的情况我该如何正确处理呢？我现在如何正确恢复？
最佳答案
问题在于实时服务器上的 master 分支和中央存储库中的 master 分支存在分歧。
如果您不想在实时服务器上执行git pull(和/或 rebase )，因为这会带来其他不需要的更改，那么最好的恢复方法是创建一个修补程序分支在包含您的修复的实时服务器上，然后推送它:
git checkout -b hotfix-20150127 master
git push origin hotfix-20150127
然后，您可以在开发计算机上获取该分支并将其干净地 merge 到 master 中，并使用最新的开发版本对其进行测试。然后，当您最终将实时服务器更新到最新代码时，您知道修复程序仍然存在。
您还应该重置实时服务器上的 master，以便其 master 再次成为 origin/master 的祖先:
git branch -f master master^
这会强制 git 将 master 分支的头更改为之前的提交(在实时服务器上进行修复之前)。您不会丢失提交，因为它仍在 hotfix-20150127 分支上(当前已 checkout )。
将来避免这种情况的方法是在开始进行任何更改之前创建修补程序分支(这样 master 分支永远不会分歧)或创建修补程序分支在您的开发计算机上(从与实时服务器上相同的版本分支)并在那里进行测试，然后将其推送到实时服务器并在实时服务器上检查它。
基本上，解决方案是从实时服务器上运行的稳定版本创建一个分支，并对该分支应用必要的修复，并确保该分支的所有修复都 merge 回主开发分支。在两个独立的分支上工作可以让您对稳定版本进行高优先级修复，而不会干扰不稳定分支上的开发。请参阅Git Flow稍微复杂但更灵活的方法。
关于git - 修补程序的正确方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/28169592/