Did you ever want a quick way to understand change history in a branch? VSTS now shows git graph in commit history for files in repositories. Now you can easily create a mental model of all your branches and commits for your git repositories using git graph.

VSTS commit history also supports advanced filters that allow you to view various history of the repository, branches, or files with various levels of granularity to support complex scenarios.

How can git graph help?

Commits with graph

In the figure above, just a cursory glance at the graph, tells that the author branch and then proceeded to update the readme, fix some bugs, work on a feature on the dev branch that was later merged to the master branch using PR 45. Since we show the topological order in the graph view, it clearly groups all changes descendant commits before their parents.

Graph is particularly helpful in busy repositories where changes are made by multiple authors for multiple files across branches at the same time. It makes it easier to identify rogue commits and their associated information therefore allowing to

Git graph experience

• The blue dots represent any commit in the repo or a file
• The grey dots represent a merge commit.
• A line connects a commit to its ancestor commit. In case a commit does not show its parent within the next 50 commits, you will see an arrow that once clicked will connect the commit to its parent commit.

Parent commit for 7c24c9a1 is not within the next 50 commits or in the view port.

Clicking on the graph node for 7c24c9a1 connects the commit to its parent commit.

Advanced filters

Now, VSTS supports advanced commit filters such as :

• Simple history
• First parent
• Full history
• Full History with simplified merges

By default the commit history view in VSTS is filtered to show Simple history. In simple history git simplifies the history e.g. In a case where a merge commit (commit M) rolls back a change of a previous commit (commit P), simple history won’t show commit P since the changes associated with it has no impact on the final state of the file. These are cases where one can find it very difficult to find where and how the changes introduced to a file went missing.

This is where with simplified merges” can help. Git keeps all the changes associated with the file and when you filter your results by  “full history”, the hidden commits such as “commit P” would start showing up.

In order to explain this a little better I will use the same example as mentioned in Ross Brodbeck’s blog.

In this case, the user followed the following steps:

As a result, since the changes associated with the commit “We have added an animal” are already overwritten by the commit “We have added a fruit”, simplified git history does not show the commit “We have added an animal”.

Once you change the filter to “Full history” you can see all the changes that impacted the file test.txt including our missing commit “We have added an animal” as shown in the image below.

You can see all read changes that impacted the file test.txt including our missing commit.

Similarly, other options such as can be very useful to see commits that occurred directly on the branch itself and not to another branch that got merged into the current branch.