←back to thread

Oh Shit, Git?

(ohshitgit.com)
464 points Anon84 | 3 comments | | HN request time: 0.633s | source
Show context
pitaj ◴[] No.42729155[source]
Some changes I would make:

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

2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead:

    # create a new branch from the current state of master
    git branch some-new-branch-name
    # switch to the previous commit
    git switch -d HEAD~
    # overwrite master branch to that commit instead
    git switch -C master
    # switch to the work branch you created
    git switch some-new-branch-name
    # your commit lives in this branch now :)
3. I'd apply the same to the `cherry-pick` version of "accidentally committed to the wrong branch":

    git switch name-of-the-correct-branch
    # grab the last commit to master
    git cherry-pick master
    # delete it from master
    git switch -d master~
    git switch -C master
4. And also to the "git-approved" way for "Fuck this noise, I give up.":

    # get the lastest state of origin
    git fetch origin
    # reset tracked files
    git restore -WS .
    # delete untracked files and directories
    git clean -d --force
    # reset master to remote version
    git switch -d origin/master
    git switch -C master
    # repeat for each borked branch
replies(11): >>42729838 #>>42729902 #>>42730974 #>>42731510 #>>42731713 #>>42731798 #>>42731885 #>>42732130 #>>42734933 #>>42737820 #>>42740404 #
ajross ◴[] No.42732130[source]
> 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.

replies(4): >>42732303 #>>42732829 #>>42733803 #>>42752070 #
1. snafferty ◴[] No.42732829[source]
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.
replies(2): >>42733440 #>>42733592 #
2. ◴[] No.42733440[source]
3. ajross ◴[] No.42733592[source]
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.