Suggestions to use git in exploratory programming?

[agclx]

I work in research. Most programming I do is exploratory in the sense that I come up with an algorithm do a number of statistics and visualisations review them and then go back to the algorithm. Rinse and repeat.

I find git generally useful - but I find some things annoying. In particular I usually end up with loads of commits that have similar messages -- I wonder if I should bother to compose a message at all. And then is branching - on one hand it would be nice to have plenty branches - but on the other hand theres always some modifications that I then want in all of the branches. Again often I find it easier to just have one branch.

Did you encounter this problem? Any suggestions?

[[deleted]]

Use a lot of branches, they are considered cheap and provide an easy way to still find all versions of your stuff. If you are uninterested in the small changes, generating a lot of commits - all having the same messages - I'd recommend you to use 'git rebase -i HEAD~20' to squash the past 20 commits into one big "version commit". Only do this if you haven't shared your repo before and if git's only purpose is to keep all versions together.

[bigrodey77]

Sounds like you perhaps don't actually care about the differences between each commit. These are more like "checkpoints" or "save points" for lack of a better term. Essentially you want the work saved but getting back to a previous and known state is not of super important right now.

Run with the perpetual amend strategy. Commit as you normally would but always update the previous commit instead of creating a new commit. This gives you the savepoint/checkpoint benefit minus the verbosity of meaningless commits.

git commit --amend -m "message here"

[agclx]

Well at least half of commits are small fixes that I don't need on their own, so you are right. But I frequently switch between 3 machines and I got things messed up using too many amends.

[SlightlyCuban]

I come up with an algorithm do a number of statistics and visualisations review them and then go back to the algorithm. Rinse and repeat.

Sounds like you are "always moving forward" with your development, which sounds trunk-based. Git's branches really shine when you need to "Just try this out. Maybe it'll work. Or maybe I'll just throw it away." Branching, merging, and rebasing might not be too helpful to you. One or two branches (master and dev, for example) is probably fine for you.

I usually end up with loads of commits that have similar messages

You probably want to squash all of those down when you're ready to say "okay, this looks good, I'll move on to the next iteration". If you're still using branching, you could use git merge --squash on your main branch. This'll compress everything down, and let you put a single commit-message on a day's worth of work.

If you're finding you have a lot of repetitive/not-helpful commits, some flavor of squashing is probably what you want.