> For me, git becomes unintelligible when there's a crazy train-track map of branching and merging. Consider finding peace by inverting your perspective: if yo

> For me, git becomes unintelligible when there's a crazy train-track map of branching and merging. Consider finding peace by inverting your perspective: if your organization’s development process (for whatever reason, many of them legitimate) involves a crazy train-track of features being developed in parallel, isn’t it great that you're all at least using something that can keep track of it? For a small team that should be unnecessary. Frequent rebasing when you’re on a side branch of development is smart, but doesn’t conflict with my point. Also, really, who looks back into the depths of history? There’s a reason a lot of backup schemes rotate a set of tapes over 30 or even 14 days. For that reason I am not a fan of rewriting history for “clarity”: I consider it wasted effort. For the same reason I don’t care about branches for explorations that turned out to go nowhere — just mark the head abandoned and stop worrying about it.