Git => ワークフローのタイプの分析

備考

Gitのようなバージョン管理ソフトウェアを使うと、最初は少し怖いかもしれませんが、分岐に特化した直感的な設計は、さまざまな種類のワークフローを可能にします。あなた自身の開発チームに適したものを選んでください。

Gitflowのワークフロー

もともとVincent Driessenによって提案されたGitflowは、gitといくつかの事前定義ブランチを使用した開発ワークフローです。これは、 Feature Branch Workflowの特殊なケースと見なすことができます。

この1つのアイデアは、開発中の特定の部分用に別々のブランチを予約することです。

masterブランチは常に最新のプロダクションコードです。実験コードはここに属しません。
developブランチには最新の開発がすべて含まれています。これらの発展的な変化はほとんど何でもあり得ますが、より大きな機能はそれぞれのブランチのために予約されています。ここのコードはリリース/デプロイメント前に常に作業され、 releaseに統合されます。
hotfixブランチは、次のリリースまで待つことのできない小さなバグの修正用です。 hotfixブランチはmasterから外れ、 masterとdevelop両方にマージされます。
releaseブランチは、 developからmaster新しい開発をリリースするために使用されます。バンプするバージョン番号などの最後の変更は、リリースブランチで行われ、その後、マージされてmaster戻され、 developます。新しいバージョンをデプロイするときは、将来の参照と簡単なロールバックのために、 master現在のバージョン番号（たとえば、セマンティックバージョニング）をタグ付けする必要があります。
featureブランチは、より大きな機能のために予約されています。これらは、特に指定された支店で開発されて一体化されているdevelop終えたとき。専用のfeatureブランチは、開発を分離し、 完了した機能を互いに独立して展開できるようにします。

このモデルの視覚的表現：

このモデルの元の表現：

フォークワークフロー

このタイプのワークフローは、このトピックで言及された他のワークフローと根本的に異なります。すべての開発者がアクセスできる1つの集中リポジトリを持つ代わりに、各開発者はメインリポジトリから分岐した独自のリポジトリを持っています。これの利点は、開発者が共有リポジトリではなく、独自のreposに投稿でき、管理者は、必要に応じて、フォークされたリポジトリからの変更をオリジナルに統合できることです。

このワークフローの視覚的表現は次のとおりです。

集中ワークフロー

この基本的なワークフローモデルでは、 masterブランチにはすべてのアクティブな開発が含まれています。寄稿者は、開発を継続する前に最新の変更を取り入れることを特に確認する必要があります。このブランチは急速に変化するためです。誰もがこのリポジトリにアクセスし、変更をマスターブランチにコミットできます。

このモデルのビジュアル表現：

これは、SubversionやCVSのような古いシステムが構築された古典的なバージョン管理のパラダイムです。このように動作するソフトウェアは、集中バージョン管理システム（CVCS）と呼ばれます。 Gitはこのように動作することができますが、すべてのプルにマージを先行させる必要があるなど、大きな欠点があります。チームがこのように動作することは非常に可能ですが、一定のマージ競合の解決によって多くの貴重な時間が掛かることになります。

これが、Linus TorvaldsがGitをCVCSとしてではなく、Mercurialに似たDVCS 、またはDistributed Version Control Systemとして作った理由です。この新しい方法の利点は、このページの他の例で示されている柔軟性です。

機能ブランチワークフロー

機能ブランチワークフローの背後にある重要なアイデアは、すべての機能開発がmasterブランチではなく専用ブランチで行われることです。このカプセル化により、複数の開発者が主要なコードベースを乱すことなく、特定の機能を簡単に操作できます。また、 masterブランチには壊れたコードが含まれることはなく、これは継続的な統合環境にとって大きな利点です。

機能の開発をカプセル化することで、プルリクエストを活用することも可能になります。これは、ブランチの周りでディスカッションを開始する方法です。彼らは他の開発者に、公式プロジェクトに統合される前に機能を承認する機会を与えます。また、機能の途中で立ち往生した場合は、同僚からの提案を求めるプルリクエストを開くことができます。要点は、プルリクエストによって、あなたのチームがお互いの仕事についてコメントすることが非常に簡単になります。

Atlassianチュートリアルに基づいています。