Gitを使用した効率的なソースコード管理プロセス

Gitは、最も効果的で使いやすいソースコード管理ツールの1つです。ユーザー数が少ないく数か月間のプロジェクト用にGitをビルドする必要がある場合、直さなくてはならない問題はそれほど多くないはずです。リポジトリを作成するだけで、プロジェクトが完了するまで全員がそのリポジトリで操作します。

しかし、大規模で数十人が協力し、何度もリリースする必要があるプロジェクトのワークフローを構築する場合、チームが可能な限り効率的に作業するためには、十分なプロセスが必要です。

この記事では、著者が50人から100人以上のプロジェクトを通じて取り組んできたGitを使用してソースコード管理プロセスを編成する方法を紹介します。このプロセスはGitに適用できるだけでなく、svnなどの他のソースコードマネージャーにも適用できます。

マスターブランチ

これはプロジェクトの全てのソースコードを格納するメインブランチであり、製品の最もクリーンなコードブランチです。開発フェーズの後、製品をユーザーにリリースします。新しいバージョンをリリースするときのコードは、このメインブランチにマージされ、後で簡単に検索できるようにブックマークされます。

ブランチのホットフィックス

重大なバグを見つけることなく製品のテストを終了したら、リリースに進みます。ただし、リリースが完了した後、お客様から<XYZ>機能が正常に動いていないとの報告があり、至急に対応する必要があります。この段階でバグを修正することをホットフィックスと呼びます。一つの製品には、多くのホットフィックスブランチを含めます。

リリースブランチ

チーム全体で一生懸命働いた後、製品をリリースする段階に入ります。新しいバージョンのリリースに備えるコードは、メインの開発ブランチ（通常はdevという名前）から抜けて、テスト、ビルドなどの他の作業を実行するため別のブランチに配置されて、。開発プロセスは開発ブランチで続行されます。

開発ブランチ

各プロジェクトでは1つの開発ブランチが必要です。このブランチはプロジェクトの存続期間を通じて使用され、すべてのメンバーが最新のコードについてこのブランチを参照します。新しい機能を開発するとき、プロジェクトメンバーはここから最新のコードを取得して作業を続行します。

機能ブランチ

機能ブランチは、機能のソースコードがプロジェクトのさまざまなチームやメンバーによって保存される場所です。

詳細

ホットフィックス

新しいバージョンをリリースした後、ソースコードをマスターブランチにマージして1.0のタグを付けましたが、重大な不具合が発生したため、プロジェクトチームは、マスターで1.0のタグが付けられたソースコードに基づいて新しいホットフィックスブランチを作成して修正する必要がありました。それ。このプロセスは、緊急性とリスクの高さのため、経験豊富なメンバーによって行われます。至急対応して、テストを実行した後、新しいバージョンv1.1をすぐにリリースし、追跡するために1.1タグで再タグ付けします。次のリリースの準備のために、ホットフィックスのコードを開発ブランチにマージすることを忘れないでください。

リリースの準備

機能開発が完了したら、新しいバージョンをリリースするためのブランチを準備する必要があります。このブランチは、必要なコミットで開発ブランチから取得されます。リリースブランチを分割した後、リリースされる製品のテストは新ブランチで行われます。テスト中に不具合が発生した場合は、ホットフィックスと同じように修正し、各コミットは次のリリースの準備のため、リリースブランチと開発ブランチに移動します。

新機能開発

プロジェクトは機能ごとにサブチームに分けれます。新しい機能を開発するときは、メインの開発ブランチからコードを取得して、プロジェクトに必要な機能を開発します。必要なテストケースに合格したら、開発ブランチに戻ります。

チームが新しい機能を開発している間、他のチームはまだ実行中であり、それらのコードは完了後に開発ブランチにマージされます。