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

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

问题在于您正在使用回购协议来执行分支的用途。出于好奇，你如何处理提交被拒绝的情况（但之后的提交没问题）？

任何解决方案（除了转向适合您需要的分支策略，之后您可能会发现单个存储库不仅足够而且更容易处理）都会变得混乱。

所有可能的选项归结为将提交 6 变基到提交 3。你真的不希望变基回到你的测试仓库，因为它会创建一个所有开发人员的混乱。但是，如果那个 rebase 没有返回测试，那么最终它也必须从生产中删除，以便使 repos 恢复同步。

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。

如果您发现必须在 5 准备就绪之前推送 4，那么它也必须重新定位到 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 存储库之间的热修复

Hot fix between two remote git repositories

git

version-control

git-commit

git-push

git-remote