 <p>Two things to consider:</p> <ol> <li><p>Maybe you should have a habit of rebasing these branches onto the tip of master (or wherever) before landing them. This way, they are strictly redundant as KingCrush suggests above, and can be destroyed to be recreated later if you find a problem.</p></li> <li><p>Use rename to mark branches you're not sure if you'll need again with a specific prefix, so that you can scan past them quickly in a list of branches when you know you're not looking for an obsolete feature branch.</p></li> </ol> <p>You could use some mixture of these techniques, e.g. always rebase, then rename branch foo to landed-foo, and then after a set interval (say, one release, or 30 days) delete the landed-foo branch.</p> <p>Notice that if you don't rebase (and run any tests on the rebased version) you have no way to be sure that a bug found after it lands was actually in the code as developed, and not caused by the impact of merging it after development, so in this case you might want to keep the branch for a while. This will happen more often with invasive / very large changes, not like your question scenario.</p>