Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Instead of a one long flat commit history, why isn't there a hierarchy, so at the top level you might have pull requests, then you could go down a level and look at the commits in that PR. I realise that PR's are specific to github, but you get the idea. I just mean grouping a number of commits as a feature or bug-fix, for example.
Surely it would make the commit history a lot easier to navigate.
I'm sure there is an obvious answer this question, but I can't seem to find it.
There is one long flat commit history because the changes are sequential. Each one build on the 'before' state and leaves an 'after' state. It would be hard to have changes not reflect this.
One option for grouping related changes is to use tags - http://git-scm.com/book/en/Git-Basics-Tagging though they are used more for tagging a point in history rather than grouping disparate commits.
To group together commits into larger ones you can also do interactive rebasing.
Branches are one option, You can create a branch and do a bunch of commits that are logically related. You can merge those commits back into master as desired - probably using the --no-ff option.
The relationship between branches can also be seen in visual tools such as gitg/gitx 
I had the same issue thinking about this until I discovered that Git numbers its parent branches. Given this, the usually annoying merge commits that are generated can be considered summary nodes. And all extra details can be banished from view, leaving a single, summarized linear history.
Check this blog post for details and examples.
You group commits in branches: each branch is a set of commits. When you merge commits, you are putting one set of commits inside another branch, effectively building a hierarchy of commits: main branch, features, bugs, experiments, you name it.
Ideally, your main branch is a succession of merge commits. If you only look at first-parents (git commands accepts such an option), you'll have the high-level view of your history (hopefully, you write a meaningful merge commit, not the auto-generated one). But when you look at the 2nd, 3rd, etc. parents of a merge in your history, you are opening the box to see what's inside a merge. Here you have details of what happened.
