git機能ブランチを削除する適切なタイミングはいつですか？

82の機能ブランチがぶら下がってしまうことを望まないので、マスターにマージするとすぐに機能ブランチを削除することの潜在的な欠点は何であるか疑問に思います。

ワークフロー：

git co -b feat-xyz
hack hack
git ci
hack some more
git ci
git co master
git merge feat-xyz
smoke test
git br -d feat-xyz

ここに問題はありますか？

マージ後に削除するのが通常の方法です。これがgit branch -d yourbranchname、ブランチが削除される前に、ブランチが完全にマージされていることを確認する理由です。

ブランチを維持するために私が考えることができるいくつかの理由があります。本番環境に到達したときにバグが戻ってきた場合に備えて、ブランチを保持したい場合や、履歴レコードが必要な場合があります。

いずれの場合も、ブランチを削除する前に、ブランチのヘッドにタグを付けるオプションがあります。タグは、いくつかの小さな違いを除いて、コミットへのポインタであるという点でブランチに似ています。1）磁器は通常、チェックアウト時にgitshow-branchやtab-autocompleteなどの探索コマンドでタグを表示しません。2） 1つをチェックアウトすると、切り離された（非参照）HEADになります3）「タグ付けメッセージを残すことができます」を。これにより、タグがコミットのようにオブジェクトストアにオブジェクトとして保存されます。

このようにして履歴を保存します。バグ修正が必要な場合は、修正のためにマスターから新しいブランチを作成することをお勧めします。

マージ後に削除しますが、git merge --no-ffブランチ履歴がグラフに表示されるように早送りを避けるために、常にを実行します。機能ブランチが開発ブランチから離れた場所と、再び参加した場所の履歴が欲しいです。

これは、Vincent Driessenによる成功したGit分岐モデルから取られています。これは、ほとんどのプロジェクトに適用するgitで使用するのに非常に優れたワークフローです。

機能のブランチを少しの間維持したい理由は2つ考えられます。

• アップストリームでさらに作業を行うために、キックバックされる可能性があります。
• 他の開発者は、マスターに他のすべてを必要とせずに、その機能を必要としている可能性があります。

実際には、ほとんどの場合、マージ後に削除しても問題ありません。

典型的なワークフローは

 // Create new branch
 $ git checkout -b myfeature
 // and then do some changes and commit them

 // Switch to master branch
 $ git checkout master

 // Merge myfeature to master. --no-ff will always keep branch information.
 $ git merge --no-ff myfeature

 // Delete myfeature branch
 $ git branch -d myfeature

 // Push the changes
 $ git push origin master

それが典型的なワークフローだと思います（マージ後に削除します）

編集それで、少なくとも短命のブランチについては、マージするのではなく、アイデアはそれらをマスターにリベースすることだと思います。その後、線形の変更履歴が作成され、ブランチ全体がメイントランクの一部になります。この場合、そこにすべての変更があるので、明らかにコピーは必要ありません。