[解決済み] git-flow vs github-flowの長所と短所を教えてください。[クローズド］

質問

最近、GitLabを使い始めました。

現在、"centralized"ワークフローを使用しています。

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

の長所と短所は何ですか？ git-flow 対 github-flow ?

どのように解決するのですか？

GitMinutes のエピソード 17 で説明したように、次のようにします。 Nicholas Zakas の記事で取り上げました。 企業内における GitHub のワークフロー の記事で紹介しています。

Git-flow は、Vincent Driessen が作成した Git の変更管理プロセスであり、いくつかの Gitの拡張機能 が付属しています。

git-flow の背後にある一般的な考え方は、常に存在するいくつかの別々のブランチを、それぞれ異なる目的のために用意することです。 master , develop , feature , release そして hotfix .

機能やバグの開発プロセスは、あるブランチから別のブランチへと流れ、最終的にリリースされることになります。

回答者の中には git-flow を一般的に使用する。

でスタートしたものもあれば git-flow で始まり、そこから離れていったものもあります。

離れていった第一の理由は git-flow プロセスは、継続的 (またはほぼ継続的) なデプロイメントモデルで扱うのが難しいからです。

一般的な感覚としては git-flow は、リリースが数週間に一度行われるような、より伝統的なリリースモデルの製品ではうまく機能しますが、一日に一度、あるいはそれ以上リリースする場合は、このプロセスはかなり壊れてしまうということです。 .

要するに

できるだけシンプルなモデル（GitHubのフローがそうであるように）から始め、必要であればより複雑なモデルへと移行していく。

の面白い図解を見ることができます。 シンプル ワークフローは GitHub-Flow にあります。

" シンプルな git のブランチングモデル "で、主な要素は以下の通りです。

1. master は常にデプロイ可能でなければなりません。
2. 機能ブランチ (pull-request + merge) を通して行われたすべての変更。
3. コンフリクトを回避/解決するためにリベースします。 master

より完全で堅牢なワークフローを実現するために。 を参照してください。 gitworkflow (一語) .