git的新手，并不完全理解一切是如何运作的，所以寻找一些详细的说明......
我有三个遥控器：
origin，其中进行了代码更改，开发人员进行了初步测试。一旦这些变化看起来稳定，他们就会被推到...... staging，其中多个用户（不仅仅是编写代码的用户）进行进一步测试。一旦staging被击败并且满意地走到客户面前，我就会推动...... production，应用程序公开，客户可以使用它。我的staging环境中的更改尚未准备好转到production，但现在需要立即转到production。如何在不推动production中的不稳定更改的情况下创建修补程序并将其推送到staging？
我已使用此过程将一些提交推送到staging：
获取最新代码：
git checkout master
git fetch origin
git merge origin/master
迁移数据库：
bundle exec rake db:migrate
创建新分支：
git checkout -b newbranch
（进行一些更改，在本地测试并运行测试套件）
提交更改：
git add .
git commit -m "commit message"
合并更改：
git checkout master
git merge newbranch
（在本地测试以确保合并中没有任何东西搞砸了）
推送到存储库：
git fetch origin
git merge origin/master
git push origin master
推送到staging / dev环境：
git push staging master
（在开发区进一步测试，以确保一切都很好去生产。如果需要在推动之前进行进一步的更改，重新开始。这个循环持续一段时间，直到一切看起来都很好。目前，我是在此阶段，正在测试的更改尚未准备好转到production。）
推送到production：
git push production master
所以，让我们说我创建了一个带有错误修复的新分支......这些步骤如何改变以将错误修复到生产而不会推动现在正在进行的所有不稳定的更改？
我已经做了大量的搜索，到目前为止已经发现有一种方法可以做到这一点，但我对git太不稳定了，无法弄清楚用来到那里的命令。 。提前致谢。
答案 0 :(得分：2)
master分支您写道，您经常将本地master分支推送到您的登台服务器;如果是这样，那就意味着你并不是100％确定master上的内容已准备就绪。但master不应该是你最稳定的本地分支吗？或者你有一个更稳定的（本地）分支？
如果您的本地master确实是您最稳定的分支，那么在<{1}} 之前合并未经测试的/实验性内容（例如来自newbranch）是错误的/ em>测试一切在master和origin服务器上是否有效;你用未经证实的东西“污染”你当地的staging分支机构！不好。
至少，您应该切换到不会污染本地master分支的工作流程。
这是一个想法。创建一个名为master的新本地分支，指向develop的当前提示。
master然后，假设git branch develop master
落后于您的本地origin/master分支，请将您的本地master分支重置为其上一个稳定状态（当前生产状态）：
master现在，创建并签出git checkout master
git reset --hard production/master
分支，该分支指向与bugfix相同的提交：
master然后
git checkout -b bugfix
上进行一些提交以修复错误。将您的bugfix分支推送到bugfix服务器中的master分支：
origin如果必须，强行推动。
git push origin bugfix:master
服务器上的搜索结果不满意，请返回步骤1. 一旦您对origin服务器上显示的内容感到满意，请将origin分支机构推送到bugfix服务器中的master分支
staging如果必须，强行推动。
git push staging bugfix:master
服务器上的搜索结果不满意，请返回步骤1. 最后，将staging合并到bugfix，将其删除，然后将master推送到master遥控器：
production现在您已经部署了错误修复程序，现在是时候让您的git checkout master
git merge bugfix
git branch -d bugfix
git push production master
分支更新了：
develop您的git checkout develop
git merge master
分支现在包含错误修正。您可以继续在其上开发新功能。
在develop上进行所有开发。如果您愿意，请使用中间功能分支，然后将其合并到develop。当你准备测试新东西时，
develop推送到develop服务器中的master分支;确保一切都在那里工作。origin推送到develop服务器中的master分支;确保一切都在那里工作。staging合并到develop。master推送到master服务器。答案 1 :(得分：0)
您有两个基本选项：
从您当前的生产版本创建一个修补程序分支，并在您的修补程序修补程序中创建，挑选或合并后将其与该分支合并。例如，假设 master 是您的生产分支：
git checkout -b hotfix/name-of-bug master
# code, hack, edit
git commit -am 'Apply hotfix for bug X.'
# Make sure the merge resolves as a fast-forward by rebasing.
# Skip this if you don't care about enforcing linear history.
git rebase master
git checkout master
git merge hotfix/name-of-bug master
git push
Cherry-pick特定提交到您的主分支。例如，如果要从存储库中的任何位置提取commit 7c199758：
git checkout master
git cherry-pick 7c199758
git push
如果你有多个提交或实际的开发线要合并，我会使用一个修补程序分支，而如果你只需要一小部分非常原子的提交，那么采摘樱桃通常是正确的方法。