Write code on a machine you can remote into from each computer? Less commits, possibly less reverts, less chance of forgetting to git pull after switching machines…idk.

I set that up, once. It went poorly for me. Git behaves much better, for me, when used thoughtfully and manually.

What I now do instead, is work on certain projects on an SSH accessible host. This gives the same benefits of having my last state easily accesses, without causing noise in my development tools such as git.

I would consider ~~three~~ four approaches.

1. Commit and push manually and deliberately

I commit changes early and often anyway. I also push regularly, seeing the remote as a safe and remote (as in backup) baseline and reference state.

The question would be: Do I switch when I'm still exploring things in the workspace, without committing when switching or moving away from it, and I would want those on the other PC? Then this would not be enough.

2. Auto-push all local git references into a separate space on the git remote

Git branches are refs, commit pointers, just like other refs are. And they can be put under arbitrary paths. refs/heads/ holds branches. I can replicate and regularly update all my branches under refs/pcreplica/laptop/*. And then on the other PC, list or fetch those, individually, or all of them, regularly automatically, or manually.

git push origin refs/heads/*:refs/pcreplica/laptop/*
git ls-remote
git fetch origin refs/pcreplica/laptop/*:refs/laptop/*

3. Auto-push the/a local branch like you suggested

my concern here would be; is only one branch enough? is only the current branch enough?

4. Remoting into the other system

Are the systems both online? Can I remote into / connect into it when need be?

Git doesn't need to have a single pull source. It's probably worth just configuring the visibility on each machine so you can do peer pulls.

I don't hate the idea of autocommitting in that scenario, though.

I have a very similar script. I basically have one branch that's only manual commits and a "sister branch" that includes all manual commits plus some automatic ones. I determine what is auto-committed based on a simple test script. The test might be as simple as, "Did it build without errors? Commit."

I do this on NixOS. I have a NAS at home where I store most of the files I work on. My computers are internally immutable and almost all the files that change reside solely on the NAS as NFS shares. All of my computers are configured to auto-mount one of its folders at boot. NixOS sees that as an internal drive.
Then, simply navigate to the project folder where I have a flake and a .envrc file containing the command use flake .which will make direnv use Nix to provision the dependencies automatically. Whenever I save, those changes are reflected on all computers.

I like to also version control everything using git and this method allows that transparently.

The only part that I am missing is getting the permissions to align between all computers accessing that same folder. Sometimes I have to create a temp folder that uses rsync to keep up with any changes. If anyone has any pointers, I’m all ears. It rarely gets in my way but does rear its head sometimes. Otherwise, this setup is perfect when I’m at home.

I just manually push and it's fine. Or as the other commenter says, use a single remote machine.

Post commit hook to push + always squash on merging feature branches

Syncthing or unison might be what you want

I used to have a similar situation, I used Vscode remote development to effectively work from any machine. Another thing I tried was using Nextcloud to watch the working directory, which automatically synchronized files when they change.

Honestly I would just commit your in progress work then on the other machine check it out and reset to the previous commit.

Then you have your in progress work on the new machine with no random commits.

You could set up an alias that does commit with message "switching machines" and pushes.

Similar have one that pulls and resets.

I have a script that runs every 5 mins that does a robocopy for each local repo to OneDrive, excluding all the git system files. I don’t really like the idea of pushing half-finished / broken code.

Rarely need to actually copy stuff back out of onedrive, but it’s good enough on the few occasions I forget to push before changing machines.

You could also use syncthing so when you are conected to your lan you work folder will always be synced from one pc to another, that way you won't have a bunch useless commits on git and you can still commit and push the changes from any computer