私たちのプロジェクトでは、GIT を SCM として使用しています。いつものように、新しい機能、複雑なバグ修正、次のバージョンなどのために別のブランチを作成します。(たとえば) 新機能が完全に実装されると、それらは「次のバージョン」ブランチである master にマージされます (その後のテスト/展開中にトランクとライブにマージされます)。したがって、新しい機能ブランチが master にマージされた後は、「死んで」います。現時点では、「死んだ」ブランチを削除して、ブランチリストを小さく明確に保ちます。しかし、最後の削除で気付いたように、ブランチの履歴を失うという犠牲を払ってこれを行います。
私の質問は次のとおりです。「死んだ」ブランチに対処する最良の方法は何ですか?
マスターにマージされたブランチ、つまりリストされたブランチだと思います
git branch --merged
で安全に削除でき、削除する必要があります
git branch -d <merged_branch>
git push --delete origin <merged_branch>
Git のポイントの 1 つは、ブランチの作成 (およびマージ) が非常に簡単であることです。「早期かつ頻繁に分岐」する必要があります。しかし、削除された古いブランチをすべて放置しておくのは面倒です。重要な履歴情報は、コミットとそれらの相互関係にあります。
マージ コミットの自動生成メッセージには、ブランチの名前が含まれていることに注意してください。したがって、通常、元のブランチ名を決定することに問題はありません (興味深い情報が含まれている場合)。
マージされていないブランチは別の問題です。
git branch --no-merged
で削除することはできませんが-d、 で削除する必要がある-Dため、誤って削除することは困難です。個人的には、最終的にはそれらも削除しますが、もっと長く待ちます.
マスターにマージする前にコミットを破棄できるように、ブランチのコピーを作成したい場合があります。これは、マスター ブランチのコミットがはるかに少なくなり、履歴がより単純になることを意味します。
次に、押しつぶされたブランチを削除し、元のブランチを保持して、ローカル マシンにより詳細な履歴を保存できるようにします。この時点で、ブランチにタグを付けて、マスターにマージする必要がないことを示すことをお勧めします (マージしても効果はありません)。
git tag -a s1 -m "this branch was squash into <squash commit> on master"
Mercurial では、ブランチを master にマージできないように、ブランチをデッドとしてマークすることができます。