Question

我有两个git远程存储库，一个用于测试，另一个用于生产。

    git remote -v
    production      https://ejemplo@bitbucket.org/deploy/pr1.git (fetch)
    production      https://ejemplo@bitbucket.org/deploy/pr1.git (push)
    test    https://ejemplo@bitbucket.org/deploy/pr1_test.git (fetch)
    test    https://ejemplo@bitbucket.org/deploy/pr1_test.git (push)

当有人进行更改时，他们会在本地工作并推送到测试遥控器：

    git push test master

有人做出了拉动，测试了变化，如果没问题，请将其推向生产阶段。

    git push production master

问题是，在推送到生产之前，我有各种各样的测试更改，但我需要应用一个中间修补程序。我无法将修补程序推送到生产环境，而无需推动其之前的其他更改（尚未测试）。

例：

    test repository : 
    test commit 6 - hotfix (i fix something) 
    test commit 5
    test commit 4
    test commit 3 - to this point is equal to production.
    test commit 2
    test commit 1

    Production repository: 
    production commit 3
    production commit 2
    production commit 1

我想推送修补程序提交（提交6）而不推送到生产提交4和5.可以这样做吗？

感谢。

Answer 1

麻烦的是你使用repos来做分支的意思。出于好奇，你如何处理提交被拒绝的情况（但提交后的提交是好的）？

任何解决方案（除了转向适合您需求的分支策略，之后您可能会发现单个回购不仅足够但更容易处理）将会变得混乱。

所有可能的选项都可以归结为将提交6重新设置为提交3.您不会确实希望该rebase返回到您的测试仓库中，因为它会给所有人带来麻烦开发者。但是如果那个rebase 没有回去测试，那么最终它也必须从生产中移除，以便让回购同步。

Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)

Prod Repo
1 --- 2 --- 3 <--(master)

Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)

做一次改变;使用相应的SHA ID

替换此命令中的提交编号

git checkout master
git checkout -b temp_master
git rebase --onto 3 5

现在你有了

Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)

Prod Repo
1 --- 2 --- 3 <--(master)

Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
             \
              6' <--(temp_master)

现在您必须测试6' 。这是以前从未存在的代码的新状态，并且未经测试。如果6无意中取决于4或5中的内容，则6'会被破坏。

所以你测试，它的工作原理。要将修补程序投入生产

git push production temp_master:master

产生

Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)

Prod Repo
1 --- 2 --- 3 --- 6' <--(master)

Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
             \
              6' <--(temp_master)

现在我的建议是尽快完成对4和5的验收测试，然后强制推送master到production并删除temp_master。

如果您发现必须在4准备好之前推动5，那么它也必须重新定位到6'。

git rebase temp_master 4
git branch -f temp_master

（其中4再次被提交的SHA替换。

再次，停止并重新测试，因为6'中的某些内容可能会与4进行严重交互，因此4'是一种新的未经测试的代码状态。一切都很好？然后：

git push production temp_master:master

你得到了

Test Repo
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)

Prod Repo
1 --- 2 --- 3 --- 6' -- 4' <--(master)

Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
             \
              6' --- 4' <--(temp_master)

此时，您可能会认为，当您对5进行测试时，您可能会对其进行重新定位，并继续与生产中重新订购的分支进行卡车运输。不要，除非你愿意在测试中（以及在每个人的本地回购中）对分支重新排序，这将是一个麻烦。在一天结束时，您需要一个共同的历史记录，因为即使您重新定义5来获取

Local
1 --- 2 --- 3 --- 4 --- 5 --- 6 <--(master)
             \
              6' --- 4' --- 5' <--(temp_master)

您可能会发现6和5'看起来相同 - 它们具有相同的累积更改集和相同的结果树 - 但它们是不同的提交，基于一个的工作必须是转向另一方。

Answer 2

在测试仓库中，运行：

git format-patch hotfix~..hotfix

将生成补丁文件。在生产仓库中，运行：

git am the.patch

两个远程git存储库之间的热修复

2 个答案: