From Pull Request to Commit Risks

As a follow-up to "Git Commit Messages and AI", I want to shift focus to pull requests. I'll use GitHub as the example, but most of this applies to other platforms and workflows, too.

You can merge pull requests in different ways.

• Merge commits: keep all commit history and form a new merge commit.
• Squash merges: combine all commits into a single one.
• Rebase merges: replay each commit one by one on top of the target branch.

For this post, it does not apply to rebase merging. We've talked about why commit messages are important in "Git Commit Messages and AI". What's important now is how pull requests influence what ends up in your trunk branch.

Where the message comes from

When you merge a pull request, GitHub allows a few options for the commit message:

• Default message
• Pull request title
• Pull request title and commit details
• Pull request title and description

Each choice has consequences. You're deciding what becomes part of your main branch's history. You're deciding what both humans and AIs will read later.

The Template Problem

Pull request templates are a blessing and a curse. Teams often include templates. These have checklists, reminders, and standard text. That may be helpful during code review. Using these templates together in the commit message, not so much. Over time, commits can fill up with duplicates and extra content. This noise hides the true purpose of the change.

For humans, it's harder to follow the project's evolution. AI models face a bigger problem: they take in this clutter during training. This makes it hard for them to recognize important signals. Boilerplate becomes indistinguishable from intent.

Review Bots and PR Description Rewriting

Many teams now use bots and AI tools in pull requests. They create summaries for pull requests.

At first glance, that seems helpful. The idea is simple: If developers won't write good descriptions, let the bots do it. Bots often generate summaries like:

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->

## Summary by CodeRabbit

- **New Features**
  - Introduced a guard function to easily identify Trogon error structs.
- **Bug Fixes**
  - Improved punctuation in previous changelog entries.
- **Tests**
  - Added tests to verify the new guard function for Trogon errors.
- **Documentation**
  - Updated the changelog with a new version section and recent changes.
- **Chores**
  - Updated the application version to 0.2.0.
  <!-- end of auto-generated comment: release notes by coderabbit.ai -->

And poems. They give you poems. I like poems at times. I learn new English words and rhymes. They are cool.

AI summaries may capture the "what" and "how," but they often miss the real "why" behind the change.

The problem is that some tools add text to pull request descriptions. They don't add comments. At least CodeRabbit does that. Merge description of the pull requests. We end up merging that information into the Git history that is better to remove. That is the problem.

Except for sequence diagrams, I often use them. I can understand what these tools think my components are. I prefer not to see text until I ask for more context. It is even better if the tool understands me. My experience level, what I know, and how I like things explained. "Ask Copilot" is a good example of this.

Wrapping Up 👋

Be Intentional. Pull requests aren't a code review gate. They could be context producers for your Git history. Every merge writes into your permanent dataset. You are feeding your Git history into the next generation of AI tools. What dataset are you building?

Before you hit Merge, ask:

• Do the Git commit messages describe the "why" behind the changes?
• Is the description adding value or carrying over a template?
• Do Git messages still matter if someone reads them six months later, be it a person or an AI?

When you merge "what", "how", and templates information, it results in historical debt. Not technical debt. Context debt.

Talk to you later 🐊 alligator.