git checkout develop && git branch -D release/v1.0.2
(リリースブランチを正しく破棄するかどうかさえわかりません)の代わりにgit flow release delete v1.0.2
ようなことを実行でき、重要な手順を見逃していないことを期待できれば素晴らしいと思います。
それは良い追加コマンドになります。
PS:それは確かにブランチを削除する正しい方法です。 (git-flowは隠された魔法を実行しないことを忘れないでください。これは、元のブログ投稿のルールの実装にすぎません!)
私は以下を提案します。 すでにdevelop / masterにマージされているが、ブランチポインタが残っている場合:
git flow release delete 1.0.2
まだ開発/マスターとマージされていない分岐を削除するには(誤って削除しないようにするため):
git flow release delete -f 1.0.2
ああ、確かに。 私はこの機能のその機能に非常に満足しています。
試したところ、削除されたブランチに対して行ったコミットがとにかく開発にマージされたように見えたので、それが正しい手順であるかどうかはわかりませんでした。 。 明確にするために、 -f
フラグが与えられた場合、これはブランチ全体とそのすべてのコミットを完全に削除するか、または完全に削除する必要がありますか?
厳密に言えば、コミットを指す_branch_オブジェクト(コミットを指す、コミットを指すなど)を削除します。 それらのコミットの1つを指している他のブランチがある限り(多分origin/feature/foo
)、コミットは固執します。 それ以外の場合は、最終的にガベージコレクションされます。 それはただのGitの振る舞いです。
うーん、まあ。 私は何かを台無しにしたに違いない。 説明してくれてありがとう!
この機能を+1します。 git-flowを使用して、リリース候補をスプリントの成果物として使用し、マスターを本番コードベースとして維持しながら、テスト環境にプッシュしようとしています。 言い換えれば、私たちの環境では、ほとんどのリリース候補はマスターに行くために「終了」することはありません-しかし、すべてが_可能_である必要があります...したがって、製品リリースが特定されたら、他のリリースを終了したいと思いますブランチ...
+1
+1
+1
+1
+1
+1と私は、現在は開発ブランチでのみ、これをフォークに実装することにしました。 また、リモートブランチを削除する機能も追加されました。
このための+1、この機能は現在サポートされていますか?
+1
このスレッドを使用してそれを行う方法を理解しましたが、組み込みメソッドを好むでしょう
2年になります...それが完了する可能性はありますか? それは良い機能だと思います。
+1
+1
+1
こんにちは、 Peter van der Doesフォークですでに利用可能であり、他にもいくつかの改善が加えられています。
+1
+1
+1
+1
+1
+1
+1
+1
+1
+4(私と私のチーム@仕事)! ^ _ ^
+1
+2
@nrvs lolz:D
:+1:
+1
:+1:
+1
:+1:
+1
+1
+1
+1
+1
+1
+1
これはavhエディションで実装されています。
+100500
+100501
+1
+1
+1
+1
+1
+1
うわー、これがまだ問題だとは信じられません。 このコマンドを待ってからほぼ8年になります。
+1
+1
うわー、9年後、これはまだ事です
本当にこの機能が必要です
これはhttps://github.com/petervanderdoes/gitflow-avhに実装されてい
免責事項:私はGitflow AVHEditionのプロジェクトリーダーです
+1
「+1」だけのコメントはやめてください。2020年であり、Githubはすでにこの目的のために絵文字を導入しています👍
@geoom
+1
最も参考になるコメント
「+1」だけのコメントはやめてください。2020年であり、Githubはすでにこの目的のために絵文字を導入しています👍