You rename a module, move helpers around, update imports across the project, and fix the tests that broke. Eighty files later, you sit down to write the commit message and the best you can do is refactor: cleanup.

That isn't laziness. Large changes are hard to describe because no single sentence covers them. A reviewer, a changelog reader, and you next month all need the same thing: which areas changed, and roughly how.

Asking an AI to summarize the whole diff in one go has its own problem. Push eighty files into one request and the model has to squeeze every area into a handful of bullets, so whole folders quietly disappear from the summary.

1. Split by Area, Then Summarize Each Part

Run on a directory, gitaiflow groups the changed files by top-level folder and summarizes each group as its own, smaller request. Loose files at the root form their own group.

A folder with more than 15 changed files is split one level deeper. Files that sit directly in that folder stay with the parent; only files in its subfolders move into their own group. So a busy src/ folder is handled like this:

src/App.tsx            →  group "src"
src/utils.ts           →  group "src"
src/components/...     →  group "src/components"
src/data/...           →  group "src/data"
tests/...              →  group "tests"
README, package.json   →  group "_root"

Folders that are flat, with files directly inside and no subfolders, are never split.

2. Ask for the Right Amount of Detail

A fixed "write 3 to 8 bullets" works for a small change and fails for a big one. The number of bullets gitaiflow asks for scales with how many files are in the group being summarized:

• up to 5 files: 3 to 5 bullets
• up to 15 files: 4 to 8 bullets
• up to 30 files: 6 to 12 bullets
• more than 30 files: 8 to 15 bullets

3. One Title That Still Fits

Per-area summaries are useful, but git commit needs a single title line. With more than one group, gitaiflow makes one extra request to produce it, with three rules:

1. The model proposes three candidate titles that each fit in 72 characters, and the longest one that fits is used.
2. If none fit, one repair request asks it to shorten its best candidate with shorter words while keeping every theme.
3. Only if that also fails is the shortest candidate cut at a word boundary, without an ellipsis and without ending on a word like "and" or "with".

If that extra request fails entirely, the title of the first group is used instead, so the summary itself never breaks because of it.

4. A Side Benefit: Re-Runs Are Cheap

Because each group is summarized separately, a group whose files haven't changed since its last summary is skipped and its earlier summary is reused. If you fix one folder after the first run, only that folder is sent to the AI again.

If you'd rather have one request for the whole diff, --no-chunk turns grouping off. I'd only use it for small changes, where grouping would add nothing.

Want the Full Picture?

This post covers how big changes are handled. The full option list is in the gitaiflow documentation ↗.

What I'd Tell You If You Do Big Refactors

1. Describe a large change in parts, then add one line on top. A single sentence can't cover eighty files, but a title plus per-area notes can.
2. Scale what you ask for to what you're summarizing. A fixed output size is too much for a small change and too little for a large one.
3. Don't redo finished work. If part of a task is unchanged, reuse its result and only process what moved.