144

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

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

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

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

4

3 に答える 3

142

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、リリースが数週間に 1 回行われる、より伝統的なリリース モデルの製品ではうまく機能しますが、1 日 1 回以上のリリースでは、このプロセスはかなりうまくいきません。

要するに：

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

「A simple git branching model 」で、 GitHub-Flowに基づく単純なワークフローの興味深い図を確認できます。主な要素は次のとおりです。

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

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

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

于 2013-08-12T13:55:32.327 に答える
43

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

ただし、それはアプリケーションの開発方法と展開方法に大きく依存します。

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

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

考慮すべきもう 1 つの点は、git-flow は標準の git ではないため、そうするかもしれないということです。物事を台無しにするチャンス。また、上記のように、誰かが git-flow をより簡単に使用できるようにする一連のスクリプトを開発したので、すべてのコマンドを覚える必要はありません。コマンドを覚えるのに役立ちますが、実際のフローを覚えるのはあなたの仕事です。 、開発者がそれがホットフィックスなのか機能なのかわからなかったり、最悪の場合、フローを思い出せなかったり、物事を詰め込んだりしたときに、私は何度も遭遇しました。

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

最近は、シンプルで管理しやすい GitHub フローに傾倒しています。また、「頻繁に展開する早期展開」のため...

お役に立てれば

于 2013-09-25T21:51:38.003 に答える