小規模チームへのバージョン管理分岐ポリシーの紹介
私は最近会社から始めた請負業者です。
チームは3人の開発者で、ジュニアレベルから中レベルレベルの2人の開発者で構成され、同じレベルの別の開発者がすぐに始まります。既存の両方の開発者にとって、これは大学/大学での最初の仕事であり、彼らの仕事を監督する上級開発者がいなかった。
明示的なバージョン管理ポリシーはありません。開発者はトランクですべての開発を行い、開発マシンから直接本番環境にデプロイします。既存のチームは分岐に慣れていません。
これをすべて変更し、CI、TDDテスト/ステージング/本番サーバーなどを、これを補完するバージョン管理ポリシーとともに導入します。
ソース管理システムはTFSです。これは、私がこれまで使用したことがありません。 1つの巨大なリポジトリとして構成されています。
私は彼らのためにいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正すべき他に何かありますか？
バージョン管理ポリシー
開発はトランクで行われます
変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージにより、2つが同期しなくなるのを防ぎます。
製品コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみを含める必要があります。スプリントごとに1回トランクから更新されるリリースブランチを1つ持つことも、週ごとに個別のリリースブランチを作成することもできます。
本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行い、トランクにマージして戻します。
1つのリリースブランチ戦略を採用する場合、トランクはスプリントごとに1回、スプリントの終わりに向かってリリースブランチにマージされます。
リリース戦略ごとに別のブランチを採用する場合、トランクはリリースブランチにマージされません。
一部のシナリオでは、ブランチの分岐が多すぎる場合、異なるブランチでバグを2回修正する必要がある場合があります。短いスプリントを実行している場合、これはそれほど頻繁には発生しません。
3台のサーバーを使用する予定です。リポジトリ内で常に最新のコードを実行しているテスト環境。リリース候補コードおよびUATの目的をステージング/テストするための最新のリリース候補を実行しているステージング環境、および本番環境。
私がこれを計画している理由は、これまでのところクライアントは内部ソフトウェアしか実行していないためです。最新のプロジェクトは知名度の高いメディアクライアント向けであり、チームは現在のチームよりも専門的な開発モデルを採用する必要があると感じています。
たとえば、現時点では、ユーザーはバグレポートをチームに電話で送ることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な眼球テストを行ってから、本番環境に直接デプロイします。自動テストなどはありません。
後から考えると、機能ブランチは一歩遠すぎると思うので、削除します。
したがって、本質的には、a）まったくブランチしない）b）リリースブランチとトランク、c）リリースごとのリリースブランチとトランクになります。
私は後者に傾いていた。私の最初の考えは、リリース候補とリリースの両方を別々のサーバー（UAT /本番）に同時に公開することですが、事実上、トランクはいつでもリリース候補なので、ブランチごとにリリースは非常識に傾いています。私の唯一の考えは、利害関係者に開発コードを見せたくない場合、別のリリース候補ブランチが必要になるかもしれませんが、YAGNIとそのすべて....
3〜4人の開発者のチームの場合、提案するブランチの数が多すぎます。
作成するすべてのブランチは、コスト（マージに費やした時間、場所を追跡するなど）に伴う追加のオーバーヘッドです。ブランチを持つことで得られるメリットがコストを上回ることを確認する必要があります。
ブランチの唯一の真の利点はコードの分離であることを覚えておいてください。つまり、コードを分離したい具体的な理由が必要です。
every sprintに個別のリリースブランチを用意するのは異常です。次のコードから分離された1つのスプリントのコードが必要なのはなぜですか？スプリントごとに繰り越される単一の安定版リリースブランチがないのはなぜですか？
変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージにより、2つが同期しなくなるのを防ぎます。
ほとんどすべての重要な新機能は、開発、開発者テスト、毎日の中断、その他のアクティビティなどを考慮した後、リアルタイムで少なくとも1週間かかります。
また、「通常のマージ」とは何ですか？毎日？毎週？行うすべてのマージには時間がかかります。変更後にターゲットマージブランチがビルドおよび実行されることを確認する必要があります。小規模なチームでは、頻繁なマージは多くのオーバーヘッドになります。
100万行以上のコードベースに取り組んでいる4人の開発者のチームがいて、これが私たちの運営方法です。
- すべての開発が行われるメインブランチ
- メジャーリリースごとに1つのブランチ（年に約1回行われる）
主要なルールの1つは、ビルドしないコードをチェックインしないことです。
それでおしまい。シンプルで理解しやすく、必要な分離が得られます（どのバージョンのリリースビルドでもいつでも作成できます）。
すべての開発作業を1つのブランチで実行することの利点：
- 開発者は常に互いに同期しています。 2人の開発者が互換性のない変更を作成するために数週間自分のブランチを離れていたため、面倒なマージはありません。
- 壊れたビルドは同じ日に見つかります。 mainで最新のコードを実行するナイトリービルドがあります。誰かが何らかの理由でビルドできないコードをチェックインした場合、すぐにわかります。
- 全員が常に同じコードで作業しているため、バグが発見される可能性は後ではなく早くなります。
- リリースブランチへの対象を絞った修正以外のマージオーバーヘッドはありません。小さなチームでは、これは大きなチームです。
あなたは彼らのためにいくつかの指針を書き留めましたが、-あなたが彼らがすでに使用しているものよりもあなたのアプローチが良いである理由を説明していません。これは問題があるかもしれません。 「私は6年間の専門的な経験があるので、あなたのやり方でやっていきます」という精神を持っているなら（そして、あなたの質問を読んで、それはまさにこのように見えます）、あなたのコンセプトを適用するためにできないことは何でもしようとするあなたのチームメンバー。
彼らは解決する必要のある問題を抱えていますか？最初にこの質問に答えることが重要です。彼らは実際に問題を抱えており、あなたの提案を歓迎するか、現在のように完全にうまく機能しているからです、そしてあなたは彼らにプッシュしているだけですあなたの働き方、あなたがこのように働きたいという理由だけで。
最終的に、ブランチを使用するように強制すると、非常に悪い影響を与える可能性があります。特にアジャイル環境では、トランクの操作は簡単です。開発者はトランクに変更をコミットし、最終的に小さな競合を処理します。これらの変更は、継続的インテグレーションプラットフォームによってすぐに使用されます。ブランチ付き：
開発者は、変更がどこにあるべきかを考えなければなりません、
誰かがブランチを管理し、ブランチからトランクにマージしなければなりません、
ブランチ間のマージはコミットよりも頻繁に行われません。つまり、誰かが2つのコミット間の競合よりも大きく、処理が難しい競合に対処する必要があります。
すべてのコミットが必ずしも継続的インテグレーションに到達するわけではありません。これにより、コミットがもたらす可能性のある影響（特にリグレッション）について開発者が得る情報が遅れます。
事実：
既存のチームは分岐に慣れていない
事態はさらに悪化します。私は経験の浅いプログラマーのチームで働いていました。経験の浅いマネージャーがブランチで遊ぶことにしました。これは多くの（ロット）の無駄な時間となり、締め切りのあるプロジェクトでは避けたいものです。
マインマが言うように、分岐には注意してください。数週間ごとに分岐することについておっしゃっていますが、本当にたくさんの分岐が必要ですか？
あるいは、プッシュモデルの代わりに「プル」モデルを使用することもできます。 GitまたはMercurialを使用している場合、中央サーバーにプッシュする前に、統合サーバーで変更を検証することができます。 TFSでは、 gated check-ins を使用して同様のことができます。このようにして、検証を行い、ブランチの複雑さを回避できます。