The Commit Activity Browser (henceforth, CAB) is one of the most rapidly evolving features at GitClear. Alloy's development team uses CAB daily -- it has become an indispensable aid to time-efficiently collaborate.
The Commit Activity Browser can be configured to color and group commits together according to user preferences. It also indicates which commits were associated with a ticket, and which commits have had developer feedback left on them
linkUse cases
Here are a few of the ways to use CAB.
link👨🏫 Replace your standup meetings
The cost of a meeting is never just the meeting itself. Ask your developers: the true time cost of a meeting is almost always 2x the time for meeting itself, once accounting for the time before and after the meeting where tasks can't be started/continued.
CAB replaces Stand-up Meetings by allowing a visualized overview of what is being worked on. Developers don't have to stand around remembering what they've worked on in the past few days. The commit activity is all there, laid out in visual form and sized according to its impact, in CAB.
link📆 View progress on the sprint
Burndown is hard to calculate without knowing which developers have started on which tickets. CAB provides immediate, accessible details on which tickets (Jira or Github Issue) are being tackled by the development team.
Perhaps more importantly, CAB shows when the developers are working on tickets that aren't in the issue tracker. If you're trying to figure out where all the time goes, it pays to see how much of your time is being spent triaging the urgent bugs, customer issues, and other non-ticket work.
link🐣 Help a new developer ramp up
There are so many ways that Commit Activity Browser helps new developers get up to speed faster. It's arguably the most essential use case for teams that are actively onboarding new hires.
At the most basic level, it allows the Lead Developer or Manager to see when the new Developer makes their 🎉 first commit 🎉. It might sounds like a trivial detail, but the time until a new developer makes their first commit is a strong indicator of the quality of install documentation for the project, so if the new developer takes three days to push their first code, that's useful signal that the project setup process could be a problem.
It allows new developers to assimilate the code style of their peers. When a new developer makes a habit of reading and commenting on the code of more Senior Developers, they get an early opportunity to contribute to the collaborative process. Reading code also helps build confidence that one is ready to make their own contribution.
As the new developer gets past their initial onboarding, CAB aggregates Code Reactions to help Lead Developers quickly identify see when a new developer is having the same problem repeatedly. Alongside the Cohort Report, CAB goes a long way toward making a Lead Developer's job operate on data instead of intuition.
link♻️ Identify themes in reactions toward a contributor's code
With non-CAB code review systems, code comments are like islands deep in the Pacific. They're disconnected from one another, and it's hard to keep track of their aggregate qualities. Code Reactions in CAB let Lead Developers and Managers detect when there is a consistent theme to the feedback a contributor is receiving.
link🤔 How much work is off-schedule?
What does the largest developer survey have to say about how well a dev team adheres to the schedule?
Stack Overflow 2019 State of Developer Survey: Development Practices
About 80% of the work developers do is improvised. If you're a CTO or VP of Engineering, it's useful to have a broadstrokes understanding of where the time is going.
linkConfiguration options
The Visual Guide to CAB offers a concise summary of the CAB featureset. In this section, we'll focus on the two major configuration options available to CAB users.
linkHow to group commits?
At the lower-left corner of CAB, you can click the "Use commit groups" label or arrow to access the options that control how commits are grouped together:
Options that control how commits are grouped, opened up after clicking the "Use commit groups" label
There are many dimensions that control how your commits will be grouped together.
linkBind commits by
The major consideration. Most teams want to bind commits by issue, because even after a PR gets merged, there are often follow-on commits. Whether these commits are bug fixing or polish, it's useful to see them as part of how the feature launch process goes beyond pull requests.
Bind by "Pull request" groups commits together when a pull request is open that includes those commits. Bind by "Auto" uses a set of heuristics to group commits by the area of functionality they seem to impact.
linkDuration
How big of groups do you want commits to be bundled into? Note that, as of 2023, choosing "three days" commit groups may result in longer build times to view developer work.
linkAfter commit review
This option is for people who regularly review code as an issue or pull request is coming together. In these cases, one might view the group of commits after the third commit, where the developer then goes on to make 5 more commits after. When the default "Hide" option is selected, you won't see work in files you've already reviewed earlier.
If the value is "Keep showing," then every time you click into a commit group, we will show all of the changed files and commits.
linkHow to color commits?
At the lower-right corner of CAB, you can control the colors that are applied to commits:
Options that can be selected to control coloring of commits
Depending on context, sometimes you want to see work by repo, issue, branch, or committer. When choosing "Dynamic," we will evaluate your options in the following order, choosing the first with many segments: repo, issue, branch, committer.
When you choose one of the explicit options, then the color of each commit group will align with the dimension you selected. If you hover over that label in the key, those commits will be highlighted:
Hovering on a color label shows which commits apply
