Gitflow: 機能が--no-ffマージを実行していない

作成日 2011年02月14日  ·  12コメント  ·  ソース: nvie/gitflow

「成功したGitブランチモデル」の記事に記載されているワークフローに感謝します。 私は特に、機能のマージにコミットオブジェクトを使用するのが好きです。

git-flow--no-ffマージを使用するない場合があることに気づきました。 どうしてこれなの? 仕様によるものですか?

--no-ff機能のマージで動作させるためにgit-flowをフォークする必要がありますか、それともこれを構成する方法はありますか?

ありがとう、
スコット

最も参考になるコメント

こんにちはヴィンセント、

その設計の背後にある考え方は確かに理解できますが、マージコミットを作成するかどうかの選択は、ユーザーが機能ブランチを開始することを選択するかどうかによって決まると思います。 開発ブランチで簡単な変更を行う場合もありますが、マージコミットを確認したいので、機能ブランチを_具体的に_作成することにします。 機能ブランチに対して1回だけコミットする場合もありますが、明示的なマージコミットを無視することを保証するほど重要ではないとユーザーが考えるものではない場合があります。

最終的には、ユーザーが選択する必要があると思います。ユーザーは、機能ブランチを使用するか、開発ブランチにすばやくコミットするかによって、異なる選択を表現していると思います。

プライベートフォームでこの変更を行うためにコードベースのどこに行くかについてのポインタは非常にありがたいです!

素晴らしいツールに感謝します!
-スコット

全てのコメント12件

こんにちはスコット、

設計上、git-flowは、コミットが過去に一緒に属していることを記録するために、マージ時に--no-ffオプションを使用します。 ただし、機能ブランチにコミットが1つしかない場合、追加のマージコミットは何も追加せず、ブランチツリーを不必要に複雑にするだけです。 したがって、シングルコミットブランチの場合、コミットがdevelop直接行われたかのように、早送りマージが行われます。

乾杯、
ヴィンセント

こんにちはヴィンセント、

その設計の背後にある考え方は確かに理解できますが、マージコミットを作成するかどうかの選択は、ユーザーが機能ブランチを開始することを選択するかどうかによって決まると思います。 開発ブランチで簡単な変更を行う場合もありますが、マージコミットを確認したいので、機能ブランチを_具体的に_作成することにします。 機能ブランチに対して1回だけコミットする場合もありますが、明示的なマージコミットを無視することを保証するほど重要ではないとユーザーが考えるものではない場合があります。

最終的には、ユーザーが選択する必要があると思います。ユーザーは、機能ブランチを使用するか、開発ブランチにすばやくコミットするかによって、異なる選択を表現していると思います。

プライベートフォームでこの変更を行うためにコードベースのどこに行くかについてのポインタは非常にありがたいです!

素晴らしいツールに感謝します!
-スコット

ここで魔法が起こります: https

シングルコミット機能のブランチを--no-ffと明示的にマージするオプションを追加するつもりはありません。それでも、(別のコマンドラインフラグの複雑さが増す以外は)何も追加されないと思うからです。あなたがそれを主張するならば、それを私的な変更にするのを遠慮しなくしてください。

乾杯、
ヴィンセント

ありがとう、ヴィンセント! ポインタに感謝します!

一番、
スコット

5セントを追加すると、

1つのコミット機能を終了する場合でも、マージコミットを行うオプションが必要です。

私がgitflowを使用する方法では、私の機能には、作業中のチケット番号が名前に含まれています。 機能を終了したら、機能名(チケット番号を含む)を指定するマージコミットを確認したいと思います。

これは、すべてのコミットメッセージにチケット番号を書き込むことなく、実際のチケットへのすべてのコミットをバックトレースするのに役立ちます。

@DonGiulioすでにチェックアウトしているかどうかはわかりませんが、AVHエディションがあなたの望むことを実行すると確信しています。

おかげで、私はそれを知りませんでした、私はそれをチェックします。

また、シングルコミットのno-ff動作を行うオプションを追加することも選択しています。 これを再考できたらいいのにと思います。

(AVHエディションに他に何があるかわかりません)。

@nvieなぜか? 「_私はまだ何も追加しないと思います_」
正直なところ、多くの人がそれ何かを追加すると信じてがないと考える人も

ユーザーが機能を作成するのに苦労し、その中で単一のコミットを実行することを選択した場合、これは、ユーザーがそのようにする必要があり(たとえば、視覚的な履歴を保持するため)、開発に直接プッシュしないことを意味します。私は逆に議論し、ユーザーがたどった道を無視することは意味がありません。

あなたは詳しく説明したいと思いますか?そのような小さな変更のために、誰もがそのような堅実な作品から分岐したいと思うとは限らないことに同意する必要があります。

@Mehradzieこのリポジトリへのコミットは5年間ありません。 AVHエディションは、しばらくの間、頼りになるフォークであり、非常に安定しています。 私はここでの応答、ましてやコードの変更に息を止めません。

@jawshooah正直なところ、SourceTreeで同じ問題を追いかけていたので、ここにたどり着いたときはリポジトリ名もチェックしませんでした。
gitflowはSourceTreeがフローを実行するために使用するものですか? 私は今少し混乱しています:D
もしそうなら、代わりに他のリポジトリの作業を使用することを提案したので、私はそれを切り刻んで変更できますか?

@Mehradzie AFAIK SourceTreeは、元のnvieバージョンのわずかに変更されたバージョンを埋め込みます。 AVHバージョンに更新するための未解決の要求があります(ここここを参照)。

このページは役に立ちましたか?
0 / 5 - 0 評価