0

私の店には、1人のコードがレビューしてプッシュし、他のすべての人がプルしてローカルで変更を加え、レビューのために1人の人に変更を送信してから、プッシュするという間抜けな設定があります。

私たちは皆、「main」と「work」の2つのローカルブランチを保持しています（「main」は静的で、「work」で動作します）。

次の手順を実行する方法を知る必要があります。1）「メイン」を元の場所に置き換えます。2）「作業」から新しく更新された「メイン」に変更をマージします。3）「メイン」を「作業」にコピーします。

手順は任意の順序にすることができますが、最新の状態に保ち、ローカルで作業するという基本的な考え方を実現する必要があります。私はドキュメントを読んでいますが、間違いを犯すのが怖いです。どんな助けでも大歓迎です。

4

2 に答える 2

1

まず、間違いを恐れてはいけません。いくつかのテストリポジトリを設定し、本番コードを操作する前に、どのように機能するかを確認してください。

私の「メイン」を原点に置き換えます

mainローカルブランチがリモートブランチと一致すると仮定すると、次のmainことができるはずです。

git checkout main
git pull

これにより、ローカルブランチがリモートブランチで最新になります。

「work」からの変更を新しく更新された「main」にマージし、「main」を「work」にコピーして戻します

先ほど、「メイン」ブランチに変更を加えないとおっしゃいました。

リモートの変更をローカルブランチにインポートしたら、次のようにそれらをブランチmainにマージします。work

git checkout work
git merge main

これは非常に典型的なワークフローです。アップストリームソースからコードを追跡し、パッチのローカルセットを維持している場合、ほぼ正確にこのようなものが表示されます。

于 2012-08-02T01:16:36.247 に答える
-1

元の質問に答える前に1つ：http ：//code.google.com/p/gerrit/を調べてください。 これは、「マスターにコードを配置できるユーザーとレビューを行うユーザー」ワークフローの多くを簡素化するホストされたコードレビューです。

トピックに戻って、いくつかの仮定から始めましょう。

  • 作業コピーには、「メイン」と「作業」の2つのブランチがあります。
  • 「main」はオリジン/メインを追跡し、「work」はローカルのみであり、オリジンサーバーにプッシュされることはありません
  • レビュー担当者のリモートを「レビュー担当者」と呼びましょう

ワークフローは次のとおりです。

  1. リモートの男は、起源のものを着陸させます
  2. 誰もがそれらの変更を取り入れたいと思っています、git fetch origin
  3. 早送りだったとしましょう。ブランチをマージするだけです。
    • git checkout main
    • git merge origin/main
  4. 2/3と同じ結果を達成するためのいくつかの選択肢がありますが、これは元々メインをトラックの原点/メインに設定したことを前提としていますが、柔軟性を高めるためにそれらを分離することを好みます
    • git checkout main
    • git pull --rebase
  5. 作業ブランチを更新するために、これにより新しいマスターの上に変更が再生され、途中で競合が発生した場合に解決する機会が与えられます。
    • git checkout work
    • git rebase -i master
  6. 変更をレビュー担当者に送り返してください。この効果のために、おそらくこの部分はすでに理解されています。
    • git push review-guy work:my-new-work-as-a-branch
于 2012-08-02T01:16:23.050 に答える