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

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.

Kubernetes–Limit your environmental impact

Reducing the carbon footprint and CO2 emission of our (cloud) workloads, is a responsibility of all of us. If you are running a Kubernetes cluster, have a look at Kube-Green . kube-green is a simple Kubernetes operator that automatically shuts down (some of) your pods when you don't need them. A single pod produces about 11 Kg CO2eq per year( here the calculation). Reason enough to give it a try! Installing kube-green in your cluster The easiest way to install the operator in your cluster is through kubectl. We first need to install a cert-manager: kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml Remark: Wait a minute before you continue as it can take some time before the cert-manager is up & running inside your cluster. Now we can install the kube-green operator: kubectl apply -f https://github.com/kube-green/kube-green/releases/latest/download/kube-green.yaml Now in the namespace where we want t...

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         ...