<p>28 March, 2021Picture the scene, you’re in the zone working on a new feature in your codebase when you spot a typo and fix it. Then,<br />
to facilitate the feature you’re working on you decide to make a small architectural change elsewhere in the codebase.<br />
Finally, before finishing your session you decide to refactor some code in one of the files you were working on.Those kind of sessions are great, because you’re in flow. And then it comes time to stage your changes and commit your<br />
work and the frustration begins. You’ve got changes in 12 files, and many of those changes aren’t related to<br />
each other. What do you do?The “right” thing to do is to spend time un-tangling your changes, staging them in groups and committing with well<br />
thought-out commit messages. git add –patch can help here, but it’s still tedious work. Alternatively, you could just<br />
git add –all and call it a day.Neither of those choices are good, but git doesn’t give us much choice. In-fact, the natural way of using git seems<br />
to inevitably lead to this situation. Here’s why:Git forces you to write your commit message at the end of your coding session – after you’ve already turned your<br />
thoughts into code anyway.If you context-switch during your coding session, git is not aware of it. In-fact, git isn’t even a part of the<br />
picture until after you’ve finished writing code.Ultimately, being “in the zone” is punished by git, because you are forced to write a description of your work after you<br />
have already completed it. That workflow is backwards, and git should instead allow preemptive commit messages.I recently built a tool called git-plan which tries to make this possible, by adding a new<br />
plan command to git. When you run git plan, you have the opportunity to write your commit message in advance.<br />
Then, when you’ve staged some changes and you’re ready to commit, simply run git plan commit and you can use your<br />
previously-written plan as a template for your commit message.An example usage might look something like:git plan add – > open vim to draft the commit message for your current task…start writing code, then notice a method that needs to be refactored/bug to be fixed.git plan add – > opens vim, so you can draft a commit message for the new task…continue working on your original task, without needing to context switchgit add –all – > stage files for your taskgit plan commit – > asks you to choose a plan, so you choose the current task’s plan…then opens vim with that plan as the template….make changes to the commit message if needed, then save.git plan list – > see the other commits you have planned…start working on the second taskIt’s important to say that this isn’t a magic pill – you can still end up with too many unrelated changes in step<br />
4 that you have to untangle. This tool just makes it possible to use git in a new way, which can lead to better habits<br />
if you put in the effort.That being said, I do think that a magic pill is possible. This is where problem #1 comes into play: when you<br />
context-switch while writing code, your tools do not switch with you…but they should. If your tools “know” what your<br />
planned work is, there is no reason why they cannot, in principle, keep up with you as you switch from building a<br />
feature in file A to fixing a bug in file B.That is the future work for git plan – to build a git workflow where staging your changes manually is not required,<br />
because your tools can keep up with you.If any readers are interested in contributing to the magic pill, I’m happy to take contributions for<br />
git-plan.Rory.↑Note: Changes to the Full-Text RSS free service</p>
