Gitflow: 早送りを使用してマージされたシングルコミットの機能ブランチ

今日もこれを見つけました。 https://github.com/nvie/gitflow/issues/100ですでに提起され、解決された問題がありましたが、開発モデルと一致しないことに同意します。 うまくいけば、十分な数の人が大騒ぎするなら、ここで何かを変えることができます。 （私はこの変更を個人的に行うのに十分な知識がありません。）

両方の問題を見始めました。 どちらの方法を好むかはまだわかりませんが、ほとんどの場合、オプションがまったくないよりもオプションの方が優れていますね。

私のフォークgit-flow（AVH Edition）でこの機能のフラグが導入されました
私のフォークは、これをnvieのgitflowの簡単なプルリクエストにするために大きく分岐しました。

フォークに実装されているバグ修正と新機能の詳細については、変更ログを確認してください。

同意しました。 少なくとも、この背後にある理論的根拠を見たいと思います。

同意しました-特に新しいgitflowユーザーの場合、動作は明らかではありません。

このフラグが設定されている理由の1つは、レビュープロセスを伴うワークフローです。 チケットにコミットが1つしかない場合でも、マージリクエストにチケット番号で注釈を付けられるようにしたいと思います。 はい、追加のマージコミットは一般にノイズを追加する可能性がありますが、このようなワークフローでは、コミットメッセージ自体を必ずしも編集する必要なしに、チケットに戻ることが重要です（チケット番号は最初から存在していない可能性があるため）

私はコメントするのが非常に苦手でしたが、私の最初の観察とは別に、他の多くの人が彼らのユースケースに貢献し、ユーティリティをさらに正当化したと思います。

現状では、私が混乱しているのは、パッチと改善をどこに提供するかということです。元のgit-flowプロジェクトは維持されていないようで、後継者として祝福されたフォークはありません。

記録のために、「AVH」フォークには旗の後ろに座っていたこの変更のようなものが含まれていると思います（デフォルトでは無効になっていると思います）が、最後にチェックした他のさまざまな変更も遅れていました。

• 遅い->大きい

少なくとも、ブランチにコミットが1つしかない場合でも、ユーザーが--no-ff強制できるようにするオプションを追加する場合は+1：+1：

今日、マージコミットがなかった理由と、突然早送りが実行された理由を理解するのに苦労していました。何が間違っているのか疑問に思う必要がありました。 。

コミットを1つだけ行うクイックフィックスを開始し、マージコミットと早送りを明示的に望まない場合は、 developブランチに直接コミットするだけです。 私はいつもこれをしました。 機能ブランチを作成すると、1つのコミットであっても、マージ時に（早送りのために）魔法のように消えないように、そのブランチが保持されます。 このブランチが必要ない場合は、開発に直接コミットし、最初から機能ブランチを作成していなかったでしょう。

少なくとも、フラグまたは構成エントリを追加して、ユーザーが希望する動作を選択できるようにしてください。一部の（理解できるが任意の）条件で早送りを予期せず無効にするのではありません：wink：

私のフォークgit-flow（AVH Edition）には、フラグをデフォルトとして設定するオプションがあります。これにより、入力せずにいつでも--no-ffできます。 詳細については、 Wikiを参照してください。

私のフォークは、これをnvieのgitflowの簡単なプルリクエストにするために大きく分岐しました。

フォークに実装されているバグ修正と新機能の詳細については、変更ログを確認してください。

@petervanderdoesありがとう。

実際、公平を期すために、私はgitflowコマンドラインを使用していませんが、 @ nvieのgitflowコマンドラインを内部で使用しているように見えるSourceTreeGUIを使用しています。 SourceTreeに代替のgit-flowバージョン/実行可能ファイルを使用させることができるかどうか、またどのようにしたらよいかわかりません。

問題＃100の締めくくりで、 @ nvieは単に間違っています。彼は、「追加のマージコミットは何も追加せず、ブランチツリーを不必要に複雑にするだけです」とコメントしていますが、実際、マージのコメントは、将来の世代に残された唯一のレコードであり、 （a）機能ブランチが作成されたこと、および（b）機能ブランチの名前が実際に何であったかという事実。 明示的な早送りのないマージがないと、プロジェクト履歴は、コミットがブランチであり、機能であったという情報を完全に失います。

これに対処しておくといいでしょう

単一のコミットの場合から明示的な--ffオプションを削除したくなるでしょう。 次に、組み込みのgitマージ構成merge.ff = falseを使用して、すべてのマージ（フロー終了によるものを含む）に--no-ffを設定し、デフォルトのgit構成で現在の動作を複製できます。

+1

少なくとも、この「機能」が文書化されていればいいのですが。

これに関する進展はありますが、古いものを再ハッシュしていることはわかっていますが、ソースツリーを使用して機能を閉じる方法がなく、マージを早送りしていません。 設定には設定がありますが、それを尊重していないようです

+1

+1

「このリポジトリは死んでいますか？＃6340」を参照してください。

これがなくてもgitを使用できることがわかりました！ 😝

文書化されておらず、使用オプションを提供していません。
これらのタイプの決定は、ユーザー側で行う必要があります。 [リリースを終了]ダイアログに小さなチェックボックスを付けてみませんか。この機能の大ファンなら、デフォルトでチェックを入れてください。私はそうではないので、チェックを外すことができますよね？

すべての新しいリリース、これは私が最初にチェックすることです：Dそしてそれは決してそこにありません：/

設定にこれのチェックボックスもあることがわかりました。 したがって、ブランチのマージごとにチェックする必要はありません。