How do you use version control systems while you are in a long design spike phase?

Question

In some recent projects, I found myself having some longer spike phases in which I build many cheap prototypes and explore different design decisions, long before I would consider my code of acceptable quality. Usually, when I check in my code into git or any other VCS, I refactor and clean it at the same time, so that I can produce a meaningful ancestry with nice code. I was considering this workflow a kind of very lean development because it allows me to make many cheap experiments before having to deal with refactoring or committing labor.

However, in my latest spike phases, this led to huge working copies on my machine, and the burden to finally get all this stuff cleaned up and committed was getting large and larger. During my spike phases, I also cannot benefit from the advantages of VCS such as restoring a previous state of my work, having a backup in the cloud in case my laptop gets lost, autc. Since I do not have collaborators in these projects, there is no external pressure to integrate more often or earlier.

I wonder how I can find a trade-off between lean spiking phases on the one hand and a healthy VSC workflow on the other hand. Are there some best practices or recommendations for this problem? I already considered committing my spikey changes to an auxiliary branch that is never merged into main, but a) by this I would lose an overview of all my changes in the spike (which I at the moment can retrieve with simple git diff resp. in the commit preview of my git client of choice) and b) I would have to spend double time on committing my changes into meaningful chunks. Thank you in advance!

Answer 1

TL;DR Branches are the way to go here.

---

Since I do not have collaborators in these projects, there is no external pressure to integrate more often or earlier.

Beware the logical inversion. Yes, having collaborators is a great incentive to commit frequently. No, not having any collaborators doesn't mean that you then shouldn't commit frequently.

There is more than one possible incentive to committing frequently.

• this led to huge working copies on my machine
• the burden to finally get all this stuff cleaned up and committed was getting large and larger
• I also cannot benefit from the advantages of VCS such as restoring a previous state of my work, ...
• [not] having a backup in the cloud in case my laptop gets lost, ...

These are 4 really good incentives to commit (and push) frequently, even if you have no collaborators.

I already considered committing my spikey changes to an auxiliary branch that is never merged into main

Yep, this is the way to go. It allows you to save your code on the server, without interfering with the original codebase.

a) by this I would lose an overview of all my changes in the spike (which I at the moment can retrieve with simple git diff resp. in the commit preview of my git client of choice)

You can compare between branches using git diff.

Secondly, while this is off-label usage, I tend to open a pull request to review my changes between my feature branch and master. The nice thing is that it auto-updates when you commit, so it's rather easy to just open a PR and use it as an easy diff viewer.

b) I would have to spend double time on committing my changes into meaningful chunks.

Again, beware the logical inversion. Yes, it is good to structure your frequent commits into individually cohesive commits. No, the inability to make individually cohesive commits is not a reason to therefore refuse to commit frequently.

Especially during POCs (i.e. spikes), code changes are a bit hap-hazard and not quite as structured as normal development. That's perfectly fine.

Spikes are one of these things where there is justification to intentionally circumvent normal development practices in favor of simplifying the experimental phase.

This significantly lowers the administrative overhead during development, which is usually a time where you need your mental resources to focus purely on getting something to work (even if not efficiently or elegantly), but it comes at the cost of having to actively clean this up if you end up wanting to merge this into your main codebase (i.e. master branch).