私のチームは、コードレビューにGitHubプルリクエストを使用して実験しています。私の唯一の質問は、あなたが終わった後、あなたはブランチで何をしますか?ブランチを削除したいと思いますが、GitHubは現在のブランチにマージされたブランチを非表示にするため、保持する必要があるように思われました。
このためのベストプラクティスについてのあなたの考えが何であるかについてちょうど興味があります。
私たちが使用する経験則(ここではStack Overflowのどこかにあります)は、「ブランチは作業用、タグは履歴用」です。
ブランチがマージされるときはいつでも(ほとんどの場合マスターに)、プレフィックス「branch」が付いたブランチの名前を使用してマージポイントにタグを付けます(例:branch-topic)。次に、ブランチを削除します。分岐点で作業を復活させる必要がある場合は、それを実行できるタグがあります。
もちろん例外もあります。さまざまな継続作業に使用する長期にわたるブランチがあります。ただし、通常、トピックブランチはマージ後に削除されます。
その点で、それらのマージは常に
merge --no-ff <branch>
これにより、マージポイントと発生したマージの記録が確実に存在します。
2013年4月10日以降、「再設計されたマージボタン」以降、ブランチが削除されることに注意してください。
マージ後のブランチの削除も簡素化されました。
追加の手順で削除を確認する代わりに、ブランチを削除するとすぐに削除され、再度必要になった場合にブランチを復元するための便利なリンクが提供されます。
これにより、プルリクエストをマージした後にブランチを削除するベストプラクティスが確認されます。
master
にマージされたブランチは常に削除します。結局のところ、Gitブランチはコミットへのポインターであり、そのコミットは別のブランチの履歴で利用できるようになったので、ブランチはもう必要ありません。 (マージコミットの親を確認することで、いつでもブランチを再作成できます。)