5

私は、組織をSVNからGitに切り替えることを主張しようとしています。現在、ワークフローは基本的に次のようになっています。

  1. 開発者は変更を加えてから、ベータブランチにコミットします
  2. QAはバグを見つけ、開発者に修正するように指示します
  3. GOTO1.少なくとも5回繰り返します。（テストスイートはありません。別の問題...）
  4. ピアコードレビュー
  5. スプリントの最後に、ブランチマネージャーは準備完了としてマークされたすべてのコードをマスターブランチにマージします。

Gitは、ステップ4と5で大いに役立つ可能性があると思います。具体的には、10のコミットがあり、その間に多くのコミットがある場合、ピアコードレビューは非常に困難です*。Gitを使用すると、コミットを簡単に元に戻すことができ、機能/バグごとに1つのコミットを作成して確認することができます。私の質問に私を導きます：

前後に長いQAを伴うシナリオに最適なGitワークフローは何ですか？

変更に対する抵抗に直面していることを忘れないでください。ワークフローが単純であるほど、採用される可能性が高くなります。また、これはWeb Devプロジェクトであるため、QAはローカルではなくベータサーバーに対してテストするため、QAスイッチングブランチは実際にはオプションではないことにも注意してください。

*つまり、このバグチケットのコミットの間に、同じファイルに他のバグチケットからのコミットがある可能性があり、以前の状態との単純な比較を行い、このチケットのコード変更を分離することは困難です。

4

3 に答える 3

3

ワークフローのより具体的な目標を挙げた方が、質問に答えやすくなります。また、ピア コード レビューの前にQA に関与しているのに、ベスト プラクティスは反対のアドバイスをしているのも奇妙に思えます。

ただし、コミットを元に戻すというあなたの言及から、あなたの主な目標の1つは、「おっと、QAは私が最後のコミットを台無しにしたことを指摘しました。これはそれを修正します。 "。もしそうなら、あなたは git の強力な履歴書き換え機能に慣れる必要があります。特に、git rebase -i. これらを使用して、新しい機能やバグ修正ごとにクリーンで簡潔な一連のコミットを作成できます。これにより、ピア レビューや今後のすべての履歴の再読み取りがはるかに簡単になります。これを行う方法の詳細については、他の無数の 場所で説明されているため、ここでは説明しません。

また、リベースするのが安全な場合 (通常は「プライベート」ブランチのみ) と安全でない (「パブリック」) ブランチ、およびその経験則を破った場合の影響についても強く認識しておく必要があります。ただし、あなたが説明したシナリオでは、ベータ サーバーで使用されるリポジトリのセットアップに QA が関与していないように思えます。その場合、おそらく安全です。

次に、機能またはバグ修正ごとに常に 1 つのブランチがあることを確認する必要があります。これにより、ピア レビューとマージの際に現在直面している問題が大幅に軽減されます。これは、論理的に関連する変更の各セットが、無関係な変更と混ざり合うのではなく、明確に分離されるためです。後者のシナリオでは、レビューと QA プロセスが混乱し、不安定になります。より洗練された git ブランチ ワークフローがあり、一部の人々はそれを気に入っていますが、git への移行から同僚を怖がらせることが心配な場合は、今のところそれらを避ける必要があるようです。github のように大規模で洗練された組織でさえ、より単純なワークフローを好みます。

于 2012-08-09T22:24:44.050 に答える
2

Gitを使用したワークフローに関する投稿を見るたびに、VincentDriessenの優れた記事「成功したGit分岐モデル」を紹介せざるを得ません。これを初めて読んだとき、電球が消え、このアプローチがほぼすべてのプロジェクトの基礎になり得ることに気づきました。

あなたのプロジェクトはWeb開発プロジェクトなので、QAサーバーにdevelopブランチをプルさせるだけです（または、QAとは別の開発サーバーがある場合は、からqaプルするブランチからdevelop）。したがって、改訂されたワークフローは次のようになります。

  1. 開発者は変更を加え、feature-Xまたはbugfix-Yブランチにコミットします。
  2. 開発者は、機能またはバグ修正をサーバーにマージdevelopしてサーバーにプッシュします。
  3. QAはバグを見つけ、バグレポートを提出します。
  4. GOTO1.X回繰り返します。
  5. 各機能のマージコミットはその機能のすべての変更を指定するため、ピアレビューは特定の機能に関連する変更をアトミックにレビューし、それを承認/改訂/拒否できます。
  6. スプリントの最後に、ブランチマネージャーはすべてのコードをからにマージdevelopしてQAを実行し、最終的な検証を行うか、特別なリリースブランチが必要ない場合はrelease-candidate直接にマージします。master

ご覧のとおり、特定のニーズに合わせてアプローチを調整することができます。ワークフローは比較的単純ですが、開発者は機能/バグ修正ブランチで作業し、終了時にマージするというアイデアに慣れる必要があります。

于 2012-08-09T22:41:04.147 に答える
1

私は会社をSVNからGitに移し、その過程でGitについて多くのことを学びました。その動き以来、私はワークフローが約3年間で開発および変更されるのを見てきました...それに基づいて、また私自身の個人的な共有プロジェクトでGitを使用することに基づいています：

nvieモデルは素晴らしいです。たった2〜3人で大好きな自分のプロジェクトに使っています。ただし、コードをコミットするすべての人が上級Gitユーザーでない限り、大規模なチームに提案する方法はありません。それは、適切な場所から枝を切り、適切な場所に統合し、一般的に「適切なことをする」人々に多くの責任を負わせます。実際には、大規模なチームでは、Gitを理解せず、いくつかのコマンドを記憶し、最終的に計画全体にレンチを投げる人が何人かいます。あなたが今変化への抵抗を得ているならば、これはそれが爆発したときだけそれを悪化させるでしょう（そしてそれはそうなるでしょう）。

あなたの説明から（現在の、またはソフトウェアの慣行がない場合）、Gitがあなたの生活を楽にする1つの方法は、あなたのBetaブランチを他の開発ブランチから分離することです。だから、あなたは：

  • Betaマスターから枝を切ります
  • 仕事する。Gitは、開発者がだらしなく、テストされていない/レビューされていないコードをプッシュすることからあなたを救うことはありません。ただし、開発者は、コードをプッシュする前に（コミットのリベースまたは修正）、犯した間違いや気付いた間違いを修正する機会が得られます。
  • あなたがブランチを持っていると仮定しますdev...他の開発者はそこに開発コードをプッシュすることができます
  • Betaうまくいったら、それをとにマージしmasterますdev。
  • Beta次のリリースでは、ブランチから新しいブランチを切り取り、dev繰り返します。

だから、人々はいつでもコミットすることができるので、あなたは誰も遅くしていませんdev。Betaまた、バグ修正のみを取得しているリリース候補（ ）ブランチもあります。

コードレビューを行う前に必ずしもコードをプッシュする必要がないため、Gitもここで役立ちます。レビューボードとその仕組みを使用して、コードをローカルにコミットし、レビューを投稿します。フィードバックを受け取ったら、コードgit commit --amendを更新してレビューを更新するだけです。すべて完了したら、ではなく1つのコミットをプッシュしnます。

あなたの説明から、それはユニットテストのように聞こえます、そしてあなたの開発者からの高品質のコードに対するより多くの責任は今より良い投資です。それ自体では、Gitは問題を解決しませんが、少なくとも役に立ちます。GitのようなDVCSを使用して開発プロセスをセットアップする方法については、さらに多くのオプションがあります。そしてそれに直面しましょう...GitはSubversionよりもはるかに楽しく使用できます。：>）

于 2012-08-10T03:34:24.650 に答える