You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# create a new branch from the current state of master
git branch some-new-branch-name
# remove the last commit from the master branch
git reset HEAD~ --hard
git checkout some-new-branch-name
with just two commands that falls into the category of "now we are playing code golf" could be
# switch to a new branch from the current state of master
git switch -c some-new-branch-name
# update your master branch - CAREFUL: You need the "/refs/heads/"!
git update-ref /refs/heads/master HEAD~
Pros:
Shorter by avoiding splitting the creation of the new branch and switching to it
update-ref is more niche and another command to learn
Since update-ref needs the full "/refs/heads/…" qualifier, but will happily "succeed" if you accidentally only type "master" by creating the file .git/master instead of updating .git/refs/heads/master it would probably lead to some strange behaviour of your git in the future that is hard to trace. I would consider this a footgun.
A way of achieving
ohshitgit/en/swears/tips/04-accidental-commit-master.md
Lines 9 to 13 in 6631834
Pros:
git reset HEAD~ --hardon their master because they might have yet untracked files #144 to avoid thereset --hardpotentially deleting uncommitted changes. While--keepwould at least error out instead of deleting changes, this solution will always work though, no matter if you have (un)staged changes and it will keep them exactly (un)staged as they were.Why this shouldn't be done:
.git/masterinstead of updating.git/refs/heads/masterit would probably lead to some strange behaviour of your git in the future that is hard to trace. I would consider this a footgun.