3

次のシナリオに最適なワークフローについて質問があります。

現在、2 つのブランチがあります。

  • 主人
  • 発達

master は、承認されたマージ リクエストを介したコードのみを受け入れます。

2 人の開発者が同じ機能の異なる部分に取り組んでいる場合、この機能のマージ リクエストを作成する最善の方法は次のとおりです。

  1. 各開発者は自分自身を作成し​​ますか? (進行するために、互いに直接プッシュおよびプルしたため、両者は互いのコードを持っています)
    • マージリクエストを最初に作成すると他の変更が発生するため、これにより問題が発生することはありませんか? 一度に 1 つのコミットをプッシュするのは非常に面倒です。たぶん、ローカルの変更だけでブランチを維持し、統合ブランチを作成しますか? しかし、マージ リクエストは単独では機能せず、あまり意味がありません。
  2. それらの 1 つは、両方の「完全な」マージ リクエストを作成しますか?
    • コードの量が多く、一度に 2 人のマージ リクエストの所有者を持つことができないため、レビューは非常に大きな仕事になります。
4

3 に答える 3

2

両方の開発者が独立していない場合は、アプローチ番号 2 をお勧めします。1 人の開発者が両方のジョブを含むマージ リクエストを作成します。ただし、次の方法でこれを少し難しくすることができます。

- 各開発者に、自分の仕事のコード レビューを小さな部分に分けて実施してもらいます。これにより、メイン ブランチに送られる作業全体のコード レビューが回避されるわけではありませんが、却下が少なくなることは間違いありません。

- 大きな機能については、可能な限り、各開発者は、他のジョブに依存しないジョブの小さな部分 (「アトミック コミット」) を生成する必要があります。この部分は、開発ブランチにマージされ、他の開発者からプルされて、作業を続行できます。仕事。このように、機能が完了すると、開発者のトピック ブランチではなく、既に開発ブランチに存在します。

あなたの説明によると、開発者はすべての作業を含むトピック ブランチを持っていると思います。トピック ブランチの観点から、両方を簡単に分離することはできません。したがって、アプローチ番号 2 に進み、両方の開発者が署名してください。

于 2016-06-13T17:15:48.377 に答える
1

フォークされたワークフローは、プル リクエストを使用して開発者の個人的なフォークからプライマリ リポジトリのリポジトリに変更を送信するこの状況で非常に魅力的になります (そして Github とうまく機能します)。

  • 「オリジン」リモートは、サーバー上のプロジェクトの開発者の個人的なフォークを指します (通常、Github などの個人的な領域に保存されます)。
  • 一部のサーバーの公式リポジトリでの「上流」リモートポイント。
  • 「開発」は定期的に公式リポジトリの「マスター」にマージされます (逆はありません)。
  • 公式リポジトリの 'development' と 'master' はどちらも常にクリーンにビルド/テストする必要があります。
  • 開発者は、開発に基づいてローカル ブランチを作成し、特定の問題/ストーリーのサブセットを処理します。
  • コードがレビューの準備が整い、すべてのテストに合格したら、開発からローカル ブランチをもう一度リベースし、次にgit pushブランチをプライベート フォーク リポジトリにリベースし、プライベート フォーク/ブランチからマスター リポジトリ/開発ブランチへのプル リクエストを作成します。 .

開発者が「i903-description-of-issue」という名前のブランチ (903 は私たちの github issue 番号) を持っており、開発に対してリベースする必要があると仮定します。

git fetch upstream
git checkout development
git merge --ff-only upstream/development
git checkout i903-description-of-issue
git rebase development
git push origin i903-description-of-issue

したがって、開発者は、自分の個人用ブランチがメイン リポジトリの公式の「開発」ブランチと常に一致していることを確認する責任があります (リベースを介して)。プル リクエストを使用して、複数のコミットを 1 回でメインの「開発」ブランチにマージします。この Github (およびその他のツール) のプル リクエスト モデルを使用すると、PR を受け入れる前にコード レビューを行うことができます。

「開発」ブランチを QA サーバーに継続的に展開する機能を壊す破壊的な機能ブランチになる場合は、おそらく、新しい機能をより小さなビットに分割して、混乱を少なくする必要があります。

于 2016-06-16T09:44:55.380 に答える
1

両方のプログラマーが作業する単一の機能ブランチを (マスターから) 作成します。レビュアーの仕事が簡単になるように、どちらのエンジニアも「アトミック コミット」を使用する必要があります。この機能の開発中に master にマージする他の多くのエンジニアがいる場合は、master から定期的にリベースを実行して、ビルドの整合性を確保してください。

于 2016-06-13T17:14:40.460 に答える