← Back to context

Comment by ajross

2 days ago

> 1. Always use `git switch` instead of `git checkout`

Even harder: always use "git reset --hard".

Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done.

If you need to manage local state, do it manually with tags (or stash, but IMHO I never remember what I stashed and will always make a dummy commit and tag it).

Don't ever try to manually manage a branch locally unless you (1) absolutely have to and (2) absolutely know what you're doing. And even then, don't, just use a hosted upstream like github or whatever.

That's my approach and I've never seen anyone else doing it. Many years ago I lost my local changes, I don't even remember why. HDD failure or something like that. Ever since, at the end of the work day, I just commit "m" or "WIP" or something more meaningful, but I get it out before closing my laptop. Then, once I'm done with the the draft PR, I fetch the latest changes, reset hard and write a nice story with commits. This way I don't ever lose my changes, I can write a nice git history and I can iterate over the changes fast.

This sounds like the correct Git workflow if you think the correct VCS to use is SVN.

  • And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location").

    All branches are public.

    • I have quite a few projects that do not have a "remote" and will probably never have a remote repo. Should I not be using branches at all?

    • > All branches are public.

      What actual problem does this solve? For me, WIP branches only ever get pushed up if at least one of two things are true about them:

      1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless.

      2) I need to get them off of my local machine for disaster-recovery purposes.

      > If you need to manage local state, do it manually with tags (or stash, but IMHO I never remember what I stashed and will always make a dummy commit and tag it).

      I don't see the benefit one gets from putting work that's not fit for publication in a dummy commit on a public branch. That's just asking for garbage that noone should concern themselves with to accidentally get pushed up at the end of a long-ass day.

      1 reply →

This is a workflow I’ve never seen on any team or project I’ve worked on. Another commenter already mentioned the remote branch for everything preference, but usage of tags is especially interesting to me. I think that’s how most people use branches, and tags tend to be more permanent. What do you do when you come back to the commit with the tag, cherry pick it over and delete the tag? It sounds like an overly complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.

  • Local branches aren't names for anything other humans beings care about. All "branches" discussed in a team are remote. But because branches have "history" and "state", keeping your local names around is just inviting them to get out of sync with identically or similarly-named branches out there in the rest of the world.

    > It sounds like an overly complicated process compared to having a branch and rebasing onto the current branch when you finally go to make the change for real.

    Not sure I understand the problem here? The rebase is the hard part. It doesn't help you to have a name for the code you're coming "from". If it collides it collides and you have to resolve it.

    What I said about tags was just as short term memory "This commit right here worked on this date", stored in a way that (unless I delete or force-update the tag) I can't forget or pollute. Branches don't have that property. And again local branches don't have any advantages.

At first I was put aback by this, but it actually kinda makes sense. I mean, if people are giving off unwarranted advises about "the right way" here, yeah, you should start with a remote branch, and push all your work ASAP. Especially when you are closing the lid of your laptop to change location.

...Not that I am gonna follow that advice, of course. Same as I'm not gonna use git switch for a task git checkout does perfectly well.