Skip to main content

Understanding your project architecture and how it evolves over time using Gource

Have you ever wanted to see your project's Git history come to life? Gource is a fantastic tool that transforms your commit history into a mesmerizing animated visualization, showing how your codebase grows and evolves over time. It's like watching a time-lapse of your project's development, with files appearing, changing, and moving as contributors work on different parts of the code.

But Gource is more than just eye candy. I like to use this tool to spot architectural patterns, identify hotspots where code changes frequently, understand how the team collaborates, and even detect potential coupling issues before they become problems. It's a powerful lens for understanding not just what a team has built, but how they've built it.

In this post, I'll walk you through everything you need to know to create your first Gource visualization and use it to gain valuable insights into your codebase's architecture.

What is Gource?

Gource is an open-source visualization tool that reads your Git repository's history and creates an animated tree structure. Each file appears as a node, directories are shown as branches, and developers appear as characters moving around the visualization, "touching" files as they commit changes. It's both beautiful and informative, making it perfect for presentations, project retrospectives, or just appreciating your team's hard work.

The easiest way to get started with Gource (on Windows) is by downloading the installer from the official Gource website or use Chocolatey:

choco install gource

Once installed, navigate to any Git repository on your computer and run:

gource

That's it! Gource will immediately start playing an animated visualization of your repository's history. You'll see files branching out from the center, with contributor avatars moving around and interacting with different files.

Tweaking Gource

While Gource is running, you can use these keyboard shortcuts:

  • Spacebar: Pause/unpause
  • +/-: Speed up or slow down
  • F: Toggle fullscreen
  • ESC: Exit

The default visualization is great, but Gource really shines when you customize it.

Here are some useful options:

Adjusting the speed

Real-time repository history can be slow. Speed things up with the -s flag (seconds per day):

gource -s 0.5

This shows one day of commits in half a second, making your visualization much more dynamic.

Setting a resolution

For presentations or screen recordings, specify the resolution:

gource --1920x1080

Hiding elements

Want a cleaner look? Hide usernames, file names, or the date:

gource --hide usernames,filenames,date

Focusing on recent history

To visualize only the last year of commits:

gource --start-date "2024-01-01"

Creating a Video

One of the coolest features is exporting your visualization as a video you can share. You'll need FFmpeg installed for this.

Run this command to create an MP4 video:

gource -1280x720 -o gource.ppm C:\\path\\to\\code\\repository
C:\\ffmpeg\\bin\\ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i gource.ppm -vcodec libx264 -preset medium -pix_fmt yuv420p -crf 18 -threads 0 -bf 0 gource.mp4

This creates a smooth 60fps video file called gource.mp4 in your current directory.

An example from the documentation website:

Gaining architectural insights

I like to use Gource to reveal insights about a codebase's architecture and development patterns. Here's what I use it for:

Identifying hotspots

Watch which files or directories get the most activity. If you see certain areas constantly being modified by multiple developers, these are your architectural hotspots. This could indicate:

  • Core components that many features depend on (potential coupling issues)
  • Areas of technical debt that need frequent fixes
  • Complex modules that might benefit from refactoring

Understanding code ownership

Observe which developers work in which parts of the codebase. Ideally, you want to see:

  • Knowledge spread across the team rather than concentrated in single individuals
  • Natural domain boundaries where certain developers focus on specific areas
  • Healthy collaboration with multiple people contributing to the same areas

If one person is the only one ever touching a critical component, you might have a knowledge silo that could become a bottleneck.

Detecting architectural drift

Watch how your directory structure evolves. Do new files constantly appear in random places? Do you see frequent reorganizations? This might indicate:

  • Unclear architectural guidelines
  • The need for better project structure documentation
  • Growing pains as the project scales

A well-organized codebase typically shows files appearing in logical clusters within established directories.

Spotting coupling issues

Pay attention to commits that touch many files across different directories simultaneously. If you frequently see changes rippling through your entire codebase, you might have tight coupling between components. Consider whether those areas could benefit from better separation of concerns.

Conclusion

Gource is a powerful tool that turns dry Git logs into engaging visual stories. Give it a try to see if you can spot any of the above patterns and please let me know how you used it to improve your architecture.

More information

acaudwell/Gource: software version control visualization

Videos · acaudwell/Gource Wiki

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...