Isn't it essential for mental organisation? How do you think about what's different about a set of changes without some sort of DAG?

They are grouped by linking them to issues in the issue tracker. All commits will then get a link to the issue and the issue gets a link back to the commit. This way you can easily track and read the full context of old changes.

Example issue, note that public ones are not associated with commits: https://issuetracker.google.com/issues/122326181

Just do one thing at a time? Today, I am working on X; my commits are for X, and details are in the commit message.

That breaks as soon as you have to interrupt working on Nice To Have Feature X to working on Inportant Bugfix/CVE Y.

How often does that happen to an individual developer though?

Once a month? In an averagely well run company even that may be towards the higher end.

Should your entire development strategy be based on a once a month occurrence?

> Once a month?

Closer to once a week for me.

Make one change at a time.

If you don't want to be stuck while a colleague does changes that conflict with what you're changing then yes, you need branching.

You don't need branching for this.

If 2+ people are working on the same file which might result into a conflict, you can either: - handle the conflict as soon as you merge your branches somewhen in the future or - handle it when trying to commit your change to head

Only difference is whether you handle the conflict now, or in the future.

You need to communicate with your colleagues to coordinate your work.