Comment by ajross

Comment by ajross a day 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.

smrq a day ago

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

Reply View 4 replies

ajross a day ago

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.

Reply View | 3 replies
- ryandrake a day ago
  
  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?
  
  Reply View | 0 replies
- simoncion a day ago
  
  > 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.
  
  Reply View | 1 reply
  
  ajross a day ago
  
  > 1) They're actually worth preserving, and not some experimental garbage that ended up being totally pointless.
  That seems naive. You don't know what's pointless for years, usually. Can I tell you how many times I've gone back to stale pull requests and topic branches to recover "How did I do this?" code?
  > 2) I need to get them off of my local machine for disaster-recovery purposes.
  That's called a "backup", and yes, data robustness is a big advantage of this workflow. You're acting like this is some kind of rare event. I push my local work to a branch (or three) on github every hour!
  A corrolary is hardware independence, btw. Working off remote branches means I can also stand up a replacement development environment with a simple clone. (And the corrolary to that means that I can trivially document this such that other people can stand up development environments for my stuff, too!)
  
  Reply View | 0 replies

snafferty a day ago

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.

Reply View 2 replies

ajross a day ago

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.

Reply View | 0 replies
[removed] a day ago

[deleted]

Reply View | 0 replies

krick a day ago

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.

Reply View 0 replies