Wow. That's quite a mouthful.

Don't let yourself be reduced to statistics by following blindly the words of fools. Don't get paralysis by analysis. Get in there and get stuff done.

Git is a tool to version your work. Everything else is extra. Feeling bad for not having branches that "do one _useful(?)_ thing" and commits including their own tests, what the?

Articles like these are toxic, imho. Use tools to empower you, not enslave you.

I mostly agree though I think there is value in discipline. Without some self imposed rules it's easy for some of us (me anyway) to get sloppy so it can help to force yourself into some guidelines.

Sure, but discipline doesn't start with click bait blog posts and controversial list of what the author think should be standard.

2. and 2a. say that commits MUST be independent, and MUST come with tests. Then 3. comes and it turns out nothing is a must.

2b. is something to debate on. I prefer to use git branches as a work stage tracker. Commit last known good state, off to the races on the next batch. So, it’s okay to push something with broken tests on a branch as long as tests work when merging to main. Then again, this argument sorta kinda holds if one works with squash commits. Nobody should care what’s on the branch and how many commits in what state are there. My branch is my scratch pad. The state matters during the merge of a pull request.

1. is also interesting. A branch must do one useful thing. Can it do more than one?

All in all, those rules are too taxing for my liking.

I had the same reaction. Particularly on every commit being independent. Seems like a lot of work that will mostly be wasted.

I guess if your work approach is exceptionally chaotic, it makes sense. But I don’t think I would ever have the time to be as chaotic as the author seems indicate they are.

I like to rewrite history so every feature has a test commit followed by a implementation commit. Then I can easily run the test to see it fail, move the head up a commit, and run it again to see it pass.

Don't confuse commit to a branch and pushing, I often commit (amend) locally but I never push till that part is done.

I struggle the most with Git when I'm working on something exploratory. If I've done it before, it's easy to make commits independent and include their own tests. If I'm figuring it out as I go, I'm more likely to have commit messages like "wip", "build X; refactor Y."

I'm experimenting with this workflow: lean into the Git messiness, git reset --hard all my "bad" commits, and then re-write history to make the "clean" commits that follow principles like these.

This is why interactive rebase exists. With a good porcelain like Magit it’s quite easy to take an ugly exploratory chain of “try this,” “try that,” “WIP,” “WIP,” etc commits and mash it into one or more sensible commits that are suitable for bisecting and have good commit messages.

as a solo developer, you are free to commit however you want

I use commits as rollback points. If something works and I want to try something risky, I commit first. I don't care about the commit message. I basically never look at any commit older than one month

I do the same. I also commit at logical completion points that build cleanly.

I hardly ever look at commits older than the last commit.

I don't often create branches for features; I find having permanent Production / Test / Dev branches is sufficient for most work. But I will create other branches as needed.

Git worktree is awesome for having multiple branches checked out all at the same time. At this point, I almost never switch branches and instead check them out into their own directory.

If I can’t remember the reason for a piece of code, and it wasn’t obscure enough to comment, I need to use “git blame” and then look at the message from the commit.

same here. i even commit automatically before every compilation.

that's why i created https://github.com/steveschnepp/git-breadcrumb

A little rough but works well enough for my current workloads.

That's not what it means to not care about commit messages.

It means the commit only needs to make sense to my self until next week.

If I see a commit from 2 weeks ago and I don't know what the message means, who cares? I hardly look at those commits.

I find git-absorb very useful and it can mostly replace manual commit --fixup.

https://github.com/tummychow/git-absorb

I'm moving away from github because of recent uncertainty about them stealing from private repos.

In the past I used it for backups and versioning plus managing PRs even for solo stuff. Now I've started using my VPS as the upstream server, and realized that even on a team project I can replace a lot of the core github functionality easily. The big advantage being there is an automatic extra backup (My computer is backed up anyway but the post probable failure mode is me screwing up git somehow so it's good to have a remote upstream)

Solo dev, do take a look at Fossil SCM. It's git-ish, but human scale (rather than Linux kernel scale).

> but human scale (rather than Linux kernel scale).

What does that even mean?

One should also note how to undo some of these things. What if you accidentally 'git commit --amend' and meant to create a new comit instead? In these cases, 'git reflog' and 'git diff <a> <b> | git apply' can come in handy

Good and all until you need to debug a weird behavior in the CI platform.

You don’t need ci as a solo developer. A few bash scripts and a docker container will suffice.

as a solo developer,

git commit -a -m “wip”

every few hours

> there's that one coworker who knows a bit more about Git than everyone else, who helps get us back on track whenever our local repos end up in a strange state

every single article about git comments on this "feature" of git...isnt it time we all removed the aura of geniousness to git and bloody moved on to something better?, (like svn for instance)

I cannot imagine how learning a new version control system would make me more effective. Git stays out of my way 99.9% of the time, and the last 0.1% gets resolved after a few minutes of googling, reading docs, or asking chatgpt.

Not just that, but:

- the individual opportunity costs of learning multiple VCSs likely outweigh the cost of learning 1, even if it's suboptimally difficult

- the community-wide leverage lost by having significant fractions of prospective oss devs who aren't comfortable contributing via one VCS or another probably outweighs the marginal leverage lost by alienating the fraction of prospective oss developers that find git unlearnable or oppressive or whatnot

(I am ~fine with breaking the monoculture for a once-a-generation move to a clearly superior model, but there's a risk of fracturing the ecosystem across several VCSs for decades to come.)

Perforce is used in game dev since it handles binary files super well, and is used by many people who aren't engineers. It's not perfect, but it's super easy to use and the GUI tooling is amazing.

I've used Perforce before moving to Git (and used rc and svn before that), everyone has had the same issues with one team member knowing it better and being to go to person for resolving issue. With Perforce the GUI is okay, or at least it was 10 years ago when I was using it, but we always went to the cli interface for many things not supported in the GUI. A GUI can't cover every option and be usable. Visual metaphors are more accessible initially but eventually they become overwhelmed and you need to move to linguistic metaphors like the cli and code.

I cringe everytime I'm forced to use perforce for work. Every action is more convoluted, slow and painful compared to git. Perforce might be great for binary files and non-technical users. But there is absolutely no reason to choose it over git when working with source code.

I started with CVS, and it made complete sense to me. Git isn't bad, but it's what I use these days.

For some reason, I never grokked svn. Something about the use of directories as versions always threw me for a loop. Maybe if I spent the time to really learn it I'd like it, but that isn't likely to happen these days.

Subversion didn't use directories as versions, it used them for branches. For versions, subversion is like using git with a monorepo. Every commit is a new version across the whole repository.

It was a simple and clever design but it's hard to argue for it when compared distributed nature of git and its ubiquity.