Comment by pitaj
Comment by pitaj 2 days ago
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
The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: