Co-Authored Commits & GitHub Graphs: Demystifying Software Project Measurement

Pair programming and mob programming are powerful techniques for fostering collaboration, knowledge sharing, and code quality within development teams. But what happens when these collaborative efforts meet the individual-centric world of GitHub's contribution graph? A recent discussion on the GitHub Community forum highlighted a common point of confusion: why "Co-authored-by" commits don't appear on the contribution graphs of co-authors.

The GitHub Contribution Graph Conundrum

The discussion, initiated by oriolpiera, raised a pertinent question: "We usually do pair-programming and we realize that all the 'Co-authored-by' commits are not counted in the graph. They are only counted for the one who do the commit. It's a bug or it's a non-feature? If it is the expected behavior, co-authored commits lose sense." This sentiment resonates with many teams striving for accurate software project measurement that reflects true team effort.

Understanding GitHub's Approach to Commit Attribution

The replies from ankurrera and Shay350 quickly clarified that this behavior is not a bug, but rather an intentional design choice by GitHub. The core reason lies in how Git and GitHub differentiate between a commit's primary author and its metadata.

• Primary Author Only: GitHub's contribution graph is designed to answer a specific question: Who created commits on a given day? From Git's perspective, a commit has one primary author.
• Metadata, Not Authorship: The Co-authored-by: trailer in a commit message is treated as collaboration metadata, not a first-class Git object representing authorship. It's a way to give credit and improve traceability, but it doesn't alter the commit's primary author.
• Avoiding Inflation: Counting co-authored commits for multiple individuals on the graph would "inflate contribution counts," making it appear as though more distinct commits were made than actually occurred.

Therefore, a commit only contributes to your graph if:

• You are recorded as the commit's primary author.
• The commit email matches (or is linked to) your GitHub account.
• The commit is pushed to a repository where contributions are counted (e.g., not all forks or private repos, depending on settings).

The Enduring Value of Co-Authored Commits

Does this mean co-authored commits "lose sense" or are useless? Absolutely not. Their purpose is different from contribution graph metrics. They remain incredibly valuable for:

• Clear Attribution: They clearly attribute collaboration in commit history.
• Transparency: They show shared work in pull requests and logs.
• Traceability: They improve traceability for pair and mob programming, making it easier to understand who contributed to specific changes in commit details, pull requests, and blame views.
• Professional Recognition: They are widely recognized in professional and open-source workflows as a standard way to acknowledge contributions.

They are meant for credit and transparency, not as a mechanism for software project measurement on the contribution graph.

Strategies for Reflecting Collaborative Contributions

If your team prioritizes having all contributors reflected in individual contribution graphs, especially for software project overview or tracking against development okr examples, several workarounds are commonly used:

• Alternate Commits: During pair programming, individuals can take turns being the primary author for different commits.
• Squash and Rotate Authorship: For a series of commits made collaboratively, the final squashed commit can be authored by a different team member each time.
• Separate Commits: Each driver/navigator can create their own distinct commits for their contributions.
• Accept Graph Limitations: Embrace the understanding that the contribution graph is an activity signal, not a comprehensive collaboration or productivity metric. It offers an approximation of individual activity, but not the full picture of team effort.

GitHub has maintained this consistent behavior for years. Understanding this distinction is key to interpreting contribution data accurately and setting realistic expectations for how team collaboration is visualized.