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

时间:2017-05-18 13:57:03

标签: git version-control git-commit git-push git-remote

我有两个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.可以这样做吗?

感谢。

2 个答案:

答案 0 :(得分: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无意中取决于45中的内容,则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)

现在我的建议是尽快完成对45的验收测试,然后强制推送masterproduction并删除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)

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

答案 1 :(得分:-1)

在测试仓库中,运行:

git format-patch hotfix~..hotfix

将生成补丁文件。在生产仓库中,运行:

git am the.patch