On 2016-07-19, at 11:02 PM, Charles Manning <cdhmann...@gmail.com> wrote:
> Squashing makes sense if you have a really ratty bunch of checkins with > work-in-progress checkins etc., but unless it's a trivial topic branch I > would still typically make the final set of commits into a few logical steps. > > It costs pretty much nothing to leave old topic branches around (but a few > thousand "nothings" can add up :-)). > > Once you've merged a topic branch you can safely delete the branch with no > harm (apart from losing the branch itself). > > As Gergely says it depends on your workflow. > > For example let's say you are using some fault tracking database (eg. trac). > It often makes sense to do the fix on a topic branch (eg. fix-trac-1234). If > you leave the branch in place after merging it you can then refer to the > branch in the trac notes and see what fixes were used to fix the bug (and > reopen the bug if it needs another kick). This actually is why I'd like to keep the old "messy work-in-progress" history, so I can see what had to be done should it be necessary to go back. I still would like some way to be able to see, at a glance, "This branch is marked as committed, so I don't have to worry that I forgot about it". --- Entertaining minecraft videos http://YouTube.com/keybounce -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
