9

まず、これが重複していたら申し訳ありませんが、検索してみましたが、Git でブランチを作成する方法などに関するものしか見つかりませんでした。それは私が探しているものではありません。私は、さまざまな人々がワークフローに合わせて Git ブランチをセットアップする方法を理解しようとしています。

私たちの会社がどのようにそれを行うかの例を挙げましょう：

  1. 開発者は自分のブランチにローカルでコミットします
  2. 開発者はコミットをリモートにプッシュし、そこで継続的なビルド システムがそれをチェックし、別の開発者がそれをレビューします
  3. レビュー/ビルドが合格した場合、コミットは QA ブランチにマージされます (失敗した場合、レビュー/ビルドが合格するまでさらにコミットが行われます)
  4. コミットが QA に失敗した場合、元に戻すコミットが行われます。
  5. 十分な QA コミットの準備ができたら、マスター ブランチがコミットを取得します (QA ブランチはマスター ブランチに基づいているため、マージは必要ありません)。
  6. マスター ブランチから定期的にブランチが取得され、「野生に」リリースするために使用されます。ここで問題が見つかった場合は、元に戻すコミットを使用してコードを削除します
  7. リリース後、開発者は自分のブランチをマスター ブランチにリベースします (以前のコミットと他の開発者のコ​​ミットの両方を取得します)。

さて、このシステムにはいくつかの問題があります。コメントでいくつかメモしますが、「私たちのシステムを修正してください」を実際に探しているわけではありません。代わりに使用できる他の分岐オプションを確認しようとしているだけです。さまざまな可能性。

したがって、Git を使用する複数の企業で働いたことがある場合 (または、Git のセットアップを大量に見たコンサルタントの場合はなおさらです) を共有していただけますか?それらの間で）開発のさまざまな段階を容易にするために...できるだけ迷惑を最小限に抑えようとしていますか？いくつかの一般的なパターンがあるに違いないと確信しています...しかし、それらが何であるかはわかりません。

PS Git のセットアップを 1 つしか見ていないが、興味深いと思われる場合は、ぜひ投稿してください。ただし、考えられるオプションの内訳を最もよく示してくれる人に答えを与えたいと思います。それは、いくつかの Git セットアップを見た人から来ると思います。

4

3 に答える 3

6

私は現在、Git を使用しているいくつかのチームを管理しており、私たちにとって非常にうまく機能する戦略を発展させてきました。

  • マスターは、常に本番環境の正確なコピーです。コードがリリースされると、現在のブランチが master に早送りされ、タグが追加されるため、リリースが時間内にマークされ、必要に応じてコードを取得できます。
  • 開発者は、自分のブランチが行く限り好きなように作業する自由がありますが、フィーチャー ブランチの場合、通常、フィーチャーごとに 1 つのブランチがあり、複数の開発者がそのブランチとの間でマージして、そのフィーチャーの作業を共有します。
  • リリース候補の時期になると、RC_XXX ブランチが作成され、十分に離れた機能ブランチがすべてそこにマージされます。これはその後テストされ、バグ修正はこれから分岐されます。
  • すべてが完了したら、RC_XXX ブランチが本番環境にリリースされ、数日間「固執」した後、マスターに昇格し、新しい機能ブランチがそれに基づいて作成されます。

これは非常にうまく機能します。本番環境に対するホット フィックスは、マスターから分岐するだけで簡単に作成およびデプロイでき、開発者は必要に応じてフィーチャー ブランチに対して分岐して依存関係を取り込むことができるからです。

于 2010-10-11T13:30:17.003 に答える
1

これはどうですか（開発者が自分のマシンに何を持っているかは無視しています）：

  • 各開発者には、最後のマスターチェックポイント（各リリースの新しいブランチ）に基づく、承認されたパッチブランチ（ここでQAコミット）があります。
  • 各開発者には、承認されたパッチブランチ（永続ブランチ）に対して継続的にリベースされる、コミットする保留中のパッチブランチがあります。
  • すべての開発者に対してQAが行われると、受け入れられたすべてのパッチブランチがマスターにマージされます
  • 新しいQAブランチが作成され、すべての開発者が再びリベースします
于 2010-10-09T19:15:45.067 に答える
0

「リリース後、開発者はブランチをリベースします」：痛い...

私は（まだ）Gitコンサルタントではありませんが、経験上、開発者は（「リリース直後」よりも）はるかに頻繁に作業をリベースする必要があります。
そうでなければ、あなたがコメントで述べたように、それはたくさんの " git revert"につながります（これは機能しますが、一般的な修正ではなく例外的な発生のままであるはずです）。

ピアツーピアコラボレーションは可能ですが、ベアリポジトリとローカルプロトコルを設定する必要があるため、多少の規律が必要です。

于 2010-10-09T19:17:43.423 に答える