Skip to main content
  1. Posts/

Enhancing Code Traceability — Automatically Including PR Descriptions in Git Commits

·520 words·2 mins· ·
Xianpeng Shen
Author
Xianpeng Shen
Table of Contents

Background
#

Recently, I had a discussion with colleagues about a seemingly simple yet crucial issue:

How can we ensure that valuable information in PRs isn’t lost over time and with changes in tools?

While we currently use Bitbucket for collaborative development, we might migrate to GitHub, GitLab, or other platforms in the future. These hosting platforms may change, but Git itself, as the core record of code history, is likely to remain for a long time.

This leads to the problem:

PR page descriptions of change context, solutions, and key discussions, if only stored within the PR tool, are likely to “disappear” after platform migration. This information should be part of the commit message.

Solutions We Considered:
#

  1. Manually recording the solution in git commit -m — but this is easily overlooked or incomplete.
  2. Mimicking pip projects using a NEWS file to record each change — while this preserves information, it’s more suitable for generating release notes than recording the motivation or reasons for a change.
  3. Mandating that members write the content in Jira tickets — this creates tool silos and hinders quick understanding of history within the code context.

Ultimately, we decided to: Use Bitbucket’s Commit Message Templates feature to directly write the PR description into the Git commit.

Bitbucket’s Commit Message Templates Feature
#

Bitbucket supports automatically generating commit messages when merging PRs, allowing useful information to be inserted via templates. The documentation is available here: 🔗 Pull request merge strategies - Bitbucket Server

I’ve also seen similar functionality in GitLab, but GitHub seems to lack this feature.

See the GitLab Commit Templates official documentation

You can use the following variables in the template:

Variable NameDescription
titlePR Title
idPR ID
descriptionPR Description
approversCurrent Approved Reviewers
fromRefName / toRefNameSource / Target Branch Name
fromProjectKey / toProjectKeySource / Target Project
fromRepoSlug / toRepoSlugSource / Target Repository
crossRepoPullRequestRepoSource repository information for cross-repository PRs

How We Used It?
#

In Bitbucket’s repository settings, you can configure the PR merge commit template. Find the settings:

Repository settings -> Merge strategies -> Commit message template

After configuration, when you merge a PR, Bitbucket will automatically write the PR title, description, and related ID into the final merge commit message.

This way, regardless of whether the team continues to use Bitbucket in the future, key PR information will forever be preserved in Git history.

Here are the actual results:

📥 Template Configuration Interface:

Bitbucket 模板配置界面

📤 Final Generated Git commit message:

最终合并 commit 的样子

Summary
#

This small change helps us procedurally protect the context of code changes. It prevents PRs from being “temporary information containers” and instead makes them a natural part of Git history.

If you’re also using Bitbucket, give this feature a try.

Let Git commit messages be not just code submissions, but records of decisions and evolution.


Please indicate the author and source when reprinting this article, and do not use it for any commercial purposes. Welcome to follow the WeChat official account “DevOps攻城狮”

Related

These settings in Bitbucket/GitHub recommends enable
·282 words·2 mins
Provides a list of recommended settings for Bitbucket and GitHub repositories, including enabling force push rejection, branch protection, tag management, merge checks, and commit message standards.
🚀 gitstats Upgrade Arrives—JSON Output, Cross-Platform Compatibility, and Code Refactoring!
·338 words·1 min
After two months of continuous improvement, gitstats now supports JSON output, code refactoring, argparse replacing getopt, and full compatibility with Windows and macOS. Welcome to use and Star support!
Conventional Branch Specification Released!
·488 words·1 min
This article introduces the Conventional Branch specification, which provides a structured naming convention for Git branches to enhance readability and collaboration.
Reliably Unforking a GitHub Repository Without Deletion and Reconstruction
·359 words·1 min
This article describes how to separate a forked repository from its parent repository using GitHub Support, avoiding data loss from deletion and reconstruction, and helping developers better manage forked repositories.
Branch Naming Convention
·205 words·1 min
This article introduces the conventional branch naming specification, including the purpose of branch names, key points, and basic rules for naming branches in Git. It also provides examples of branch prefixes and their meanings.
Obtaining Bitbucket Repository Events in Real Time via the generic-webhook-trigger Plugin
·409 words·2 mins
This article describes how to use Jenkins’ generic-webhook-trigger plugin to obtain real-time event information from a Bitbucket repository, such as the Pull Request ID.