Another Way to Git: Bundle Commits into Logical Groups

Another way to use the git distributed version control system has been under discussion lately. Proposed in January by Annie Sexton, a UX engineer at the DevOps Cloud Platform Render, this approach could make lives easier for both the developer and the reviewer of pull requests, she argues.

Instead of committing often, documenting a work in painstaking progress, this approach bundles commits of the same feature branch into logical categories, only after work on the feature is largely finished, she explained in a blog post describing this new technique.

“The end result is a very, very tidy and well-organized git history,” Sexton elaborated in a recent edition of the ChangeLog podcast.

The show’s co-host, Jerod Santo, also saw potential value in the approach.

Santo explained that it differed from the canonical method — as often espoused by Richard Hipp, who’s the author of Fossil distributed version control system — in which “every commit that you commit is immediately shared over the network with everybody else. There’s no hiding anything.”

In contrast, Sexton’s approach is more like getting cleaned up before you go to a restaurant, Santo observed.

Relief for the Reviewers

When building a new feature, most development teams will first create a new branch off of the main codebase, and create commits when each chunk of work is completed. When the feature is complete, they issue a pull request (PR), which is reviewed and entered into the main branch when accepted.

Great. But there are some limitations to this approach, Sexton points out. One is that, almost invariably, certain commits contained unfinished work. Another problem with this approach is that it creates a lot of work for the team that reviews the PR. Rare is the commit that only has one change. Often many are captured in the committed, and they can be across the codebase in a way that is difficult for the reviewer to track.

The approach Sexton advocates is different. She separates the engineering work from the commit documentation. Work on the feature as usual, but don’t worry about commenting on the commits as that info will be erased later anyway. Just mark them as a “work-in-progress” (or “WIP”). The developer is free to leave work unfinished, knowing that they can get back to it later.

When the developer has finished all your changes, they do a git reset, a command that, without flags, erases the commit history.

Typically developers are discouraged from using this command, as it erases the commit history of the work. They should not be so worried, she advises.

“I think I was coached back in the day that things are irreversible if you use git reset, and it’s super-dangerous. And it’s not. It’s really not. There’s actually very few things in git that you can’t undo,” she said on the podcast. The changes still can be revealed through git reflog.

“The following approach was inspired by my coworker, Dan Wendorf, whose git flow tends to revolve around one core principle: do the work first, clean up the commits later.” https://t.co/xmex1y7PXH @_anniebabannie_ @render #Git #Workflow

— Joab Jackson (@Joab_Jackson) March 8, 2022

The final step, Sexton advises, is to go back over the code and do a new set of commits, categorically, looking for logical groupings that would go well together. The idea is to make the pull request “much easier to review by splitting up our changes into human-readable, easy-to-follow commits,” Sexton wrote.

“When I’m in development mode, I’m in development mode, and I’m just problem-solving, and I don’t have to switch mentally to thinking about git as well.”

After the reset, “it looks like you’ve just made all of your changes all in one go, without ever making a single commit. And then, you can go through and pick out which files seem to go together the best, and just group your changes into logical commits,” she said.  “So it’s as if I knew exactly what I was gonna build, every single line, and I committed them one after the other, as if I was like a robot.”

A good tool, such as VS Code, can help in this grouping of commits, she noted.

For the developer, one advantage here is that it breaks committing and development into two separate tasks entirely. “What I love about this is that they’re completely separate tasks,” she further explained in the podcast.  “When I’m in development mode, I’m in development mode, and I’m just problem-solving, and I don’t have to switch mentally to thinking about git as well, because all of that gets taken care of later.”

Different Strokes

While most developers use git in one particular way, there is nothing stopping us from using it in other ways. Git itself is in fact very unopinionated about how it is used, Santo noted.

” I do think that Git is old enough that many, many people, many veterans of git have tested it a lot of different ways, tried it different ways, and have some really valuable workflows that people can rely on. But it’s still flexible enough that people can do it other ways if they want to,” Sexton agreed.

Still, many developers remain skeptical. We asked one of our git gurus, Michelle Gienow, who has penned a number of git tutorials for TNS. “It does not appeal to me personally as a way to work, I don’t think, but then I shouldn’t knock it until I try it. I can certainly see the appeal in the logic,” she responded, via a Twitter message.

The Changelog 480: Git your reset on – Listen on Changelog.com