2つのリモートgitリポジトリ間のホットフィックス

Question

2つのgitリモートリポジトリがあります.1つはテスト用で、もう1つはプロダクション用です。誰かが変更を行う場合は

 
    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

誰かがプルを行い、変更をテストし、[OK]を、生産にそれをプッシュするTIS場合。

 git push production master

私は生産にプッシュする前にテストするための様々な変化を持っているときに問題があるが、私はinmediateの修正プログラムを適用する必要があります。 プロンプトをプッシュしないでプロダクションにプッシュすることはできません。

例：

 
    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 

私は4をコミットする修正プログラムは、生産にプッシュせずに（6コミット）コミットプッシュすると5は、これを行うことは可能ですか？

ありがとうございました。

Answer 1

問題は、reposを使ってブランチの意味を決めることです。好奇心の中で、コミットが拒否された状況をどのように処理しますか（それがうまくいった後にコミットします）？

任意のソリューション（ニーズに適したブランチ戦略に移行する以外は、1つのレポだけでは十分ではないが対処しやすくなる可能性があります）は面倒です。

コミット3にコミット6をリベースすることができます。本当には、すべての開発者にとって混乱を招くように、そのリベースをテストレポに戻したいと考えています。しかし、その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) 

リベースを行います。今、あなたは今、あなたが​​をテストする必要があります

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) 

を持って対応するSHAのID

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

と、このコマンドでコミット番号を交換してください。これはこれまで存在しなかったコードの新しい状態であり、テストされていません。 6が誤って4または5の何かに依存する場合は、​​が壊れています。

テストすると、うまく動作します。生産

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) 

を得

git push production temp_master:master 

に修正プログラムを入手するには、今、私のアドバイスは、できるだけ早く4と5の受け入れテストを完了した後、productionにプッシュmasterを強制し、temp_masterを削除することです。

5の準備が整う前に4をプッシュする必要がある場合は、​​にリベースする必要があります。 （4がコミットのSHAに置き換えられ再び）

git rebase temp_master 4 
git branch -f temp_master 

。

また、​​の何かが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あなたにもそれをリベースし、ちょうど再注文したブランチにトラック輸送を続けるかもしれないと思うかもしれません生産中。テストでブランチを並べ替えるつもりがない限り（そして全員のローカルリポジトリでも）、面倒な作業ではありません。彼らは変化の同じ累積セットと同じを持っている - あなたは

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

を取得するために5をリベースしても、あなたが6と5'は同じように見えることがありますので、一日の終わりに、あなたは、共通の歴史を必要とします結果ツリーではありますが、それらは異なるコミットであり、一方をベースにした作業は他方にリベースされる必要があります。テストレポで

Answer 2

、実行します。

パッチファイルを生成します

git format-patch hotfix~..hotfix 

。生産レポでは、実行します。

git am the.patch