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.

  • 1
    A user interface could probably group commits for display and navigation. But it doesn't seem universally useful enough to hard-wire in the (very general and workflow-agnostic) core.
    – user7043
    Commented May 20, 2014 at 8:55
  • If the commits are logically distinct, they should not be grouped. If they are logically parts of one change, they should be one commit (that's what all the rebase stuff is for). And if they are related, they will most likely be close together and easy to find anyway.
    – Jan Hudec
    Commented May 20, 2014 at 9:11
  • This is done as you describe with the use off branches, read up on feature-branches.
    – iveqy
    Commented May 20, 2014 at 10:01
  • ask the people who designed git, I'm sure they know why they made their design decisions.
    – jwenting
    Commented May 20, 2014 at 10:09
  • I agree with the poster conceptually. The fact that something works in a certain way right now, does not mean that it should. Personally, I use "squash merge" frequently to summarize several commits into one, and put that into the master branch. The level of detail I want to see in master is higher than in development for instance. The problem with that is that there is basically no relationship between the newly-created squash commit and the commits that originated it. I can certainly imagine being able to group several commits into one, which itself a commit with a clear before and after Commented Jun 16, 2016 at 15:49

3 Answers 3


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 enter image description here


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.