3 ms·
>> makes sure to walk the trainees through the confusing states you can get into, >> then we explain what happened, why, and how to correctly get out of them
by blacksmythe 7y ago
>> makes sure to walk the trainees through the confusing states you can get into,
>> then we explain what happened, why, and how to correctly get out of them
Is this something you could share?
- BiteCode_dev 7y ago- detached HEAD: "git checkout existing_branch" or "git checkout -b new_branch" - you don't where somewhere and you moved and you can't go back: "git reflog" - local repo and remote with a different history (e.g: you rebased on a published branch): the whole team to sync with remote except you, then hold. Export your remaining changes as a patch. Reclone. Apply patch. - remote has a different history than the rest of the team (e.g: you forced push a different history): Delete remote, recreate, repush from one of the team mate, then apply previous solution. - your messed up your merge and wish to never have done that: "git reset --merge" - the last commit is not published and you messed it up: "git commit --amend" - the last commit is published and you messed it up: "git revert HEAD" But rather than solve problems, better not get them in the first place. Always "git status" before anything, always get a clean working copy before checkout/pull, create a fat gitignore, etc.
- jerf 7y agoNot meaningfully. It isn't written as a blog post document; it's a series of commands and presentation notes, designed to be delivered live by me. You can basically obtain what I have in the document by combining A: what I wrote above B: a good git tutorial, see internet and C: some screwing around with using git checkout, reset, and merge with commit hashes directly on a little repo you use locally.