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チュートリアルに基づいています。
GitHubの流れ
多くのオープンソースプロジェクトで人気がありますが、それだけではありません。
特定の場所(Github、Gitlab、Bitbucket、ローカルサーバー)のマスターブランチには、最新の出荷可能バージョンが含まれています。新しい機能/バグ修正/アーキテクチャ変更のたびに、各開発者がブランチを作成します。
変更はそのブランチで発生し、プル要求、コードレビューなどで議論することができます。承認されると、それらはマスターブランチにマージされます。
Scott Chaconによるフル・フロー:
- マスターブランチにあるものはすべて展開可能です
- 新しいことに取り組むには、マスターから分かりやすい名前のブランチを作成してください(つまり:new-oauth2-scope)
- そのブランチをローカルにコミットし、定期的にサーバー上の同じ名前のブランチに作業をプッシュします
- フィードバックやヘルプが必要な場合や、ブランチがマージの準備ができていると思われる場合は、プルリクエストを開きます
- 他の誰かがその機能をレビューして承認した後、その機能をマスターにマージすることができます
- マージされて「マスター」にプッシュされると、すぐに展開できます。
もともとScott Chaconの個人用ウェブサイトに掲載されていました 。
画像提供: GitHub Flowリファレンス