git-flowとgithub-flowの長所と短所は何ですか?[閉まっている]


124

最近、GitLabの使用を開始しました。

現在「集中型」ワークフローを使用しています。

github-flowへの移行を検討していますが、確認したいと思います。

git-flowgithub-flowの長所と短所は何ですか?

回答:


133

GitMinutesエピソード17で説明されているように、「社内のGitHubワークフロー」に関するNicholas Zakasの記事:

Git-flowは、Vincent Driessenによって作成されたGitの変更を管理するためのプロセスであり、そのフローを管理するためのGit拡張機能がいくつか付属しています
gitの流れの背後にある一般的な考え方は、異なる目的のために常に存在するいくつかの別々の枝、それぞれを持っている:masterdevelopfeaturerelease、とhotfix
機能またはバグの開発プロセスは、最終的にリリースされる前に、あるブランチから別のブランチに流れます。

一部の回答者はgit-flow、一般的に使用していると述べています。
何人かgit-flowは最初からそれから離れました。

離れる主な理由git-flowは、継続的(またはほぼ継続的)な展開モデルではプロセスを処理することが難しいためです。
一般的な感じはgit-flow、リリースが数週間に1回行われる従来のリリースモデルの製品ではうまく機能しますが、このプロセスは、1日に1回以上リリースする場合はかなり壊れます

要するに:

可能な限り単純なモデル(GitHubフローがそうであるように)から始め、必要に応じてより複雑なモデルに移動します。


あなたは興味深い実例を参照することができ、簡単な基づいてワークフロー、GitHubのフローを:で
、「シンプルgitの分岐モデルの主な要素があることで、」:

  1. master 常に展開可能である必要があります。
  2. 機能ブランチを通じて行われたすべての変更(プルリクエスト+マージ)
  3. 競合を回避/解決するためにリベースします。合併するmaster

https://a248.e.akamai.net/camo.github.com/9783623eba280ba5ace8b9e63842be52af2f0546/687474703a2f2f7374617469632e62656e65742e61692f736b697463682f666c6f772d32303133303932362d3139333431392e706e676767


実際のより完全で堅牢なワークフローについては、gitworkflow(一言)を参照してください


88

すべてのモデルが最適ではないため、全員が従うべき特効薬のワークフローはありません。そうは言っても、以下の点に基づいて、ソフトウェアに適したモデルを選択できます。

本番環境の複数のバージョン-Git-flowを使用

コードが複数のバージョンを運用している場合(オペレーティングシステム、Officeパッケージ、カスタムアプリケーションなどの一般的なソフトウェア製品など)、git-flowを使用できます。主な理由は、次のバージョンを開発しながら、本番環境で以前のバージョンを継続的にサポートする必要があるためです。

プロダクションシンプルソフトウェアの単一バージョン-Github-flowを使用

コードのバージョンが常に1つしかない場合(つまり、Webサイト、Webサービスなど)、github-flowを使用できます。主な理由は、開発者が複雑なことをする必要がないためです。開発者が機能を完了するか、バグ修正を完了すると、すぐに製品版にプロモートされます。

単一バージョンの本番環境ですが、非常に複雑なソフトウェアです-Gitlab-flowを使用してください

FacebookやGmailのような大規模なソフトウェアの場合、CI / CD>ツールが稼働する前に、ブランチとマスターブランチの間にデプロイメントブランチを導入 してから、本番環境に移行する必要があります。アイデアは、何百万もの人々によって使用されているので、製品版により多くの保護を導入することです。


7
"Gitdmz-flow" / "Git DMZ Flow"をリストに追加するだけです: gist.github.com/djspiewak/9f2f91085607a4859a66
Robert Fey

1
参照先の企業は、トランクベースのシステムを使用しています。paulhammant.com/2014/01/08/…–
PatrickWalker

1
Git DMZフローはGitflowに似ており、DMZブランチは開発ブランチのようなものです。したがって、私はそれについて特別なことは何も感じません。
Gayan Pathirage 2017

2
私の理解では、Git-Flowはマルチプロダクションバージョンではうまく機能しません。修正プログラムの戦略では、本番バージョンが1つだけであり、対応するリリースブランチで修正プログラムを実行していることを前提としています(後でそれをマージしてブランチを開発します)。複数の本番ブランチに存在する1つのバグをどのように修正できるかには対応していないようです。
Adrian Shum

5
@GayanPathirage実際にはそうではありません。1.マスターでの「クラシック」GitFlowタグ。Hotfixブランチは、(マスターからの)最新の製品バージョンに対して修正を行うためのものです。2.「リリースブランチ」とは、Gitflowの他の何かを意味します。これは、実際にはリリース前のプレビューブランチです(開発ブランチから分岐し、実際にリリースされたときにマスターにマージすることを目的としています)。3.あなたが言及しているのは、GitFlowの「サポートブランチ」と呼ばれるものです(これが、GitFlowが嫌いな理由の1つです:型破りな用語です)。ただし、それはまだ実験的なフローです(そのため、ほとんどのGitflowのイントロには表示されません)
Adrian Shum

38

私はgit-flowモデルを1年以上使用してきましたが、問題ありません。

しかし、それは本当にあなたのアプリケーションがどのように開発され、デプロイされるかによります。

開発/展開フローが遅いアプリケーションがある場合にうまく機能します。

しかし、たとえば、GitHubのように、開発/デプロイフローが速いアプリケーションがあります。毎日デプロイし、時には1日に数回デプロイします。この場合、git-flowは私の意見ではすべてを遅くする傾向があるため、GitHubを使用していますフロー。

もう1つ検討する必要があるのは、git-flowは標準のgitではないためです。つまり、そうかもしれませんが、実際には、それを知らない開発者が見つかる可能性があります。その後、学習曲線があります。物事を台無しにするチャンス。また、上記のように、誰かがgit-flowをより簡単に使用できるように一連のスクリプトを開発したため、すべてのコマンドを覚えておく必要はありません。コマンドを手助けしてくれますが、実際のフローを覚えておくことはあなたの仕事です、開発者がホットフィックスなのか機能なのかわからなかったときや、フローを覚えたり、物事を詰め込んだりできなかったりすると、最悪の場合でも何度か遭遇しました。

MacおよびWindows SourceTreeの git-flowをサポートするGUIが少なくとも1つあります。

最近では、GitHubフローのシンプルさと管理のしやすさから、GitHubフローに傾いています。また、「早期に頻繁にデプロイする」ために...

お役に立てれば


+1。仰るとおりです。
VonC 2013

2
GitHubフローはGit-Flow内にあります。継続的インテグレーションと継続的デプロイメントが必要な場合は、developブランチを使用してできるだけ多く実行することができます。すべての機能は、開発ブランチから分岐されます。複雑な展開モデルがない限り、マスターブランチやリリースブランチは必要ありません。(たとえば、1.1バージョンは一部のクライアントで稼働しており、1.2は別のクライアントで稼働しており、現在、新しいクライアント用に1.3を開発しています)3つのクライアントすべてが、それぞれのバージョンのバグ修正と変更を要求します。
Gayan Pathirage 16年

ディエゴこんにちは、あなたの答えをありがとう。複数バージョンのメンテナンスについてはどうですか?Git Flowで簡単にできますか?サポートブランチが必要なので難しいと聞きました!モデルはそのために適していると思いますか?
Luis Gouveia

1
こんにちはルイス、私はあなたがモデルを機能させることができると思いますが、もう一度私はあなたが標準のgitワークフローで同じことを達成できるように感じます。
Diego Antunes

1
@LuisGouveia実際、あなたの質問と上記の私の返答以来、私はgit-flowが完全に機能するプロジェクトに出くわし、そのプロジェクトの所有権を持っています。アイデアはgit flow release...、アプリケーションをデプロイするためにgithubアクションと組み合わせて使用することです。私の最初の応答では、1日に複数回リリースしたため、git-flowを使用するときに問題が発生すると述べました。このプロジェクトでgit-flowがうまく機能すると思うのは、事前定義されたリリースサイクルがあるためです。これは、git-flowを使用する主なセールスポイントの1つです。
Diego Antunes
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.