修补程序的正确方法是什么？
What is correct way for hotfixes?
我在 BitBucket.org 有我项目的中央（远程，源）回购。
在我的服务器上克隆实时回购
在我的机器上克隆 Dev repo
我在 dev repo 上做开发。并已将许多提交推送到 Central 回购。但是实时回购处于 cloned/initiated.
时的相同状态
我不想在 Live 服务器上做 git pull，直到我的所有开发工作最终完成。
但是...我发现了代码中的错误；我必须立即在 Live 站点上修复它。所以我去了实时服务器（这是中央服务器之后的几个提交）并更改了代码。然后我暂存了那个文件并提交了它。
现在，当我尝试将此提交推送到 Central 存储库（这样我就可以拉取 Dev 存储库）时，我得到以下信息：
# git push -u origin master
Password:
To https://xxx@bitbucket.org/xxx/xxx.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://xxx@bitbucket.org/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.
我知道 SO 上有关于快进的问题。但是，我想我做错了。我该如何正确处理这种情况？我现在该如何正确恢复？
git push origin master
To https://github.com/Joey-project/project.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/Joey-project/project.git'
是一个经常重复出现的错误。
我了解到发生这种情况的原因是不应将 his/her 分支推送到更新的远程分支。
想法是使用类似的东西：
git fetch origin; git merge origin/master
也许这个 link 可以帮助：git rejected push non-fast-forward。好像有关系。
希望对你有用，建议你看看;)
乔伊
问题是实时服务器上的 master 分支和中央仓库中的 master 分支不同。
如果您不想在实时服务器上执行 git pull（and/or 变基），因为这会带来其他不需要的更改，那么最好的恢复方法是创建一个修补程序分支在包含您的修复程序的实时服务器上，然后推送：
git checkout -b hotfix-20150127 master
git push origin hotfix-20150127
然后您可以在您的开发机器上获取该分支并将其干净地合并到 master 并使用最新的开发版本对其进行测试。然后，当您最终将实时服务器更新为最新代码时，您知道修复仍然存在。
您还应该在实时服务器上重置 master，使其 master 再次成为 origin/master 的祖先：
git branch -f master master^
这会强制 git 将 master 分支的头部更改为之前的提交（在您对实时服务器进行修复之前）。您不会丢失提交，因为它仍在 hotfix-20150127 分支上（当前已签出）。
将来避免这种情况的方法是在 开始进行任何更改之前创建修补程序分支 （这样 master 分支永远不会发散）或创建开发机器上的修补程序分支（从与实时服务器上相同的修订分支）并在那里测试它，然后将它推送到实时服务器并在实时服务器上检查它。
基本上，解决方案是在实时服务器上从稳定版本 运行 创建一个分支，并将必要的修复应用到该分支，并确保该分支的所有修复都被合并回主开发分支。在两个独立的分支上工作允许您对稳定版本进行高优先级修复，而不会干扰不稳定分支上的开发。请参阅 Git Flow 了解稍微复杂但更灵活的方法。
在这种情况下，我会在实时版本上创建一个新分支，将修复添加到新分支，然后将新分支推送到中央仓库。然后，这将让您将 master 和新的 bugfix 分支都拉到您的开发机器上，并在那里处理合并冲突。
git checkout -b bugfix
git add <fix-files>
git commit
git push origin bugfix
将来可能值得将实时版本保留在自己的分支上。这样你就可以准确地控制什么是 运行。如果您需要进一步的修复，您可以在中央仓库（在发布分支上）进行修复，然后将它们拉到实时服务器上。
要从此处恢复，请使用
git checkout -b bugfix
创建新分支，然后如 Jonathon 所说，使用
git branch -f master master^
重置 master 以与中央 repo 同步
（感谢 Jonathon 的简化）
我在 BitBucket.org 有我项目的中央（远程，源）回购。
在我的服务器上克隆实时回购
在我的机器上克隆 Dev repo
我在 dev repo 上做开发。并已将许多提交推送到 Central 回购。但是实时回购处于 cloned/initiated.
时的相同状态我不想在 Live 服务器上做 git pull，直到我的所有开发工作最终完成。
但是...我发现了代码中的错误；我必须立即在 Live 站点上修复它。所以我去了实时服务器（这是中央服务器之后的几个提交）并更改了代码。然后我暂存了那个文件并提交了它。
现在，当我尝试将此提交推送到 Central 存储库（这样我就可以拉取 Dev 存储库）时，我得到以下信息：
# git push -u origin master
Password:
To https://xxx@bitbucket.org/xxx/xxx.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://xxx@bitbucket.org/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.
我知道 SO 上有关于快进的问题。但是，我想我做错了。我该如何正确处理这种情况？我现在该如何正确恢复？
git push origin master
To https://github.com/Joey-project/project.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/Joey-project/project.git'
是一个经常重复出现的错误。
我了解到发生这种情况的原因是不应将 his/her 分支推送到更新的远程分支。
想法是使用类似的东西：
git fetch origin; git merge origin/master
也许这个 link 可以帮助：git rejected push non-fast-forward。好像有关系。
希望对你有用，建议你看看;)
乔伊
问题是实时服务器上的 master 分支和中央仓库中的 master 分支不同。
如果您不想在实时服务器上执行 git pull（and/or 变基），因为这会带来其他不需要的更改，那么最好的恢复方法是创建一个修补程序分支在包含您的修复程序的实时服务器上，然后推送：
git checkout -b hotfix-20150127 master
git push origin hotfix-20150127
然后您可以在您的开发机器上获取该分支并将其干净地合并到 master 并使用最新的开发版本对其进行测试。然后，当您最终将实时服务器更新为最新代码时，您知道修复仍然存在。
您还应该在实时服务器上重置 master，使其 master 再次成为 origin/master 的祖先：
git branch -f master master^
这会强制 git 将 master 分支的头部更改为之前的提交（在您对实时服务器进行修复之前）。您不会丢失提交，因为它仍在 hotfix-20150127 分支上（当前已签出）。
将来避免这种情况的方法是在 开始进行任何更改之前创建修补程序分支 （这样 master 分支永远不会发散）或创建开发机器上的修补程序分支（从与实时服务器上相同的修订分支）并在那里测试它，然后将它推送到实时服务器并在实时服务器上检查它。
基本上，解决方案是在实时服务器上从稳定版本 运行 创建一个分支，并将必要的修复应用到该分支，并确保该分支的所有修复都被合并回主开发分支。在两个独立的分支上工作允许您对稳定版本进行高优先级修复，而不会干扰不稳定分支上的开发。请参阅 Git Flow 了解稍微复杂但更灵活的方法。
在这种情况下，我会在实时版本上创建一个新分支，将修复添加到新分支，然后将新分支推送到中央仓库。然后，这将让您将 master 和新的 bugfix 分支都拉到您的开发机器上，并在那里处理合并冲突。
git checkout -b bugfix
git add <fix-files>
git commit
git push origin bugfix
将来可能值得将实时版本保留在自己的分支上。这样你就可以准确地控制什么是 运行。如果您需要进一步的修复，您可以在中央仓库（在发布分支上）进行修复，然后将它们拉到实时服务器上。
要从此处恢复，请使用
git checkout -b bugfix
创建新分支，然后如 Jonathon 所说，使用
git branch -f master master^
重置 master 以与中央 repo 同步
（感谢 Jonathon 的简化）