If you're building a feature, you don’t want to commit every single line of code. Instead, you commit complete chunks of work. That’s why the ability to go back with Esc-Esc and revert code changes when Claude goes off the rails is a very welcome improvement.
If you're using AI like this, it seems to me that it would be perfectly reasonable to make a separate branch, allow for micro-commits, and squash once a "complete chunk of work" is done.
That said, having a single option that rewinds LLM context and code state is better than having to do both separately.
Ugh, no. Git is a distributed vcs. Changes in git stay local unless and until you push them to a server, and then furthermore, point someone else at your changes for review. (Formal PR or otherwise.)
Your tools should work for you, and git is no exception. Commit early and commit often. Before you (or an LLM) go on a jaunt through the code, changing whatever, commit the wip to git as you go along. That way, if something goes awry, it's an easy git reset HEAD^ to go backwards just a little bit and undo your changes.
Later on, when it's time to share your work, git rebase -i main (or wherever your branching off point was). This will bring up your editor with a list of commits. Reorder them to make more sense, and then also merge commits together by changing the first word on the line to be "fixup". exit your editor and git will rewrite history for outside consumption. Then you can push and ask someone else to review your commits, which hopefully is now a series of readable smaller commits and not one giant commit that does everything,
because those suck to review.
