git pull
, Git automatically knows which server to fetch from and branch to merge intogit stash save 'description of changes'
. Youcan revisit those stashes later git stash list
and decide whether togit stash drop
them after some time has past. Please note thatuntracked and ignored files are not stashed by default. See'--include-untracked' and '--all' for stash options to handle thosetwo cases.git reset --hard
, however please be quite aware thatthis is almost certainly a completely unrecoverable operation. Anychanges which are removed here cannot be restored later. This willnot delete untracked or ignored files. Those can be deleted with git clean -nd
git clean -ndX
respectively, or git clean -ndx
for bothat once. Well, actually those command do not delete the files. Theyshow what files will be deleted. Replace the 'n' in '-nd…' with 'f'to actually delete the files. Bestpractice is to ensure you are notdeleting what you should not by looking at the moribund filenamesfirst.git status
will tell you exactly what you need to do. For example:git checkout
in file mode is a command that cannot berecovered from—the changes which are discarded most probably cannot berecovered. Perhaps you should run git stash save -p 'description'
instead, and select the changes you no longer want to be stashedinstead of zapping them.git commit
) or bystashing them (git stash save 'message'
) or getting rid of them.git status
will help you understand whether your working directoryis clean or not.gitk --all --date-order
to help visualize everything what other gitreferences might need to be updated.git pull
:typically for master it might be origin/master. There is a variant ofthis option which lets you make your local branch identical to someother branch or ref.git reset --hard @{u}
git branch -a; git tag
, git log --all
or, my preference, you canlook graphically at gitk --all --date-order
git reset --hard HEAD^
If you are removing multiple commits from the top, youcan run git reset HEAD~2
to remove the last two commits. You canincrease the number to remove even more commits.git branch newbranchname
BEFORE doing the git reset
.git add
as normal.git checkout GOODSHA -- path/to/filename
.git commit --amend
to update the last commit. Yes, you can use '-a' if you wantto avoid the git add
suggested in the previous paragraph. You canalso use --author to change the author information.gitk --date-order
or usinggit log --graph --decorate --oneline
You are looking for the 40character SHA-1 hash ID (or the 7 character abbreviation). Yes, ifyou know the '^' or '~' shortcuts you may use those.git rebase -p
will be unable to properly recreate them. Please inspect theresulting merge topology gitk --date-order HEAD ORIG_HEAD
to ensurethat git did want you wanted. If it did not, there is not really anyautomated recourse. You can reset back to the commit before the SHAyou want to get rid of, and then cherry-pick the normal commits andmanually re-merge the 'bad' merges. Or you can just suffer with theinappropriate topology (perhaps creating fake merges git merge --ours otherbranch
so that subsequent development work on those brancheswill be properly merged in with the correct merge-base).git filter-branch
command to perform thisaction. This command is quite involved and complex, so I will simplypoint you at the manual pageand remind you that best practiceis to always use --tag-name-filter cat -- --all
unless you arereally sure you know what you are doing.gitk --date-order
or using git log --graph --decorate --oneline
You are looking for the 40 character SHA-1 hashID (or the 7 character abbreviation). Yes, if you know the '^' or '~'shortcuts you may use those.git add
as normal, and then run git commit --amend
(including changing theauthor information with --author). When you are satisfied, you shouldrun git rebase --continue
gitk --date-order
or using git log --graph --decorate --oneline
You are looking for the 40 character SHA-1 hashID (or the 7 character abbreviation). Yes, if you know the '^' or '~'shortcuts you may use those.git branch
output is the branchyou are currently on. I will use '$master' in this example, butsubstitute your branch name for '$master' in the following commands.git rebase -p
will be unable toproperly recreate them. Please inspect the resulting merge topologygitk --date-order HEAD ORIG_HEAD
to ensure that git did want youwanted. If it did not, there is not really any automated recourse.You can reset back to the commit before the SHA you want to get ridof, and then cherry-pick the normal commits and manually re-merge the'bad' merges. Or you can just suffer with the inappropriate topology(perhaps creating fake merges git merge --ours otherbranch
so thatsubsequent development work on those branches will be properly mergedin with the correct merge-base).git branch -d nonce
git revert
commit to create a new commit which undoes what thecommit target of the revert did.gitk --date-order
orusing git log --graph --decorate --oneline
You are looking for the40 character SHA-1 hash ID (or the 7 character abbreviation). Yes, ifyou know the '^' or '~' shortcuts you may use those.gitk --date-order
or usinggit log --graph --decorate --oneline
You are looking for the 40character SHA-1 hash ID (or the 7 character abbreviation). Yes, ifyou know the '^' or '~' shortcuts you may use those.gitk --date-order
or using git log --graph --decorate --oneline
You are looking for the 40 character SHA-1 hashID (or the 7 character abbreviation). Yes, if you know the '^' or '~'shortcuts you may use those.git revert SHA
. Unfortunately, this is just thetip of the iceberg. The problem is, what happens if you want to mergethat branch later, perhaps months later long after you have exiledthis problem from your memory, either to this branch or to some otherbranch this branch merged into. Well, the problem is git has ittracked in history that a merge occurred, so it is not going toattempt to remerge what it has already merged. The fact that it waslater reverted is irrelevant. You could revert the revert, but thatsupposes that you remember that you need to do so.git push -f
to thrust your updated history upon everyone else. As you read inthe reference, this may be denied by default by your upstreamrepository (see git config receive.denyNonFastForwards
, but can bedisabled (temporarily I suggest) if you have access to the server.You then will need to send mail to everyone who might have pulledthe history telling them that history was rewritten and they need togit pull --rebase
and do a bit of history rewriting of their own ifthey branched or tagged from the now outdated history.git log -Sfoo --all
where 'foo' is replaced with something unique in thecommits you made. You can also search with gitk --all --date-order
to see if anything looks likely.git stash list
, to see if you might have stashedinstead of committing. You can also run gitk --all --date-order $(git stash list | awk -F: '{print $1};')
to visualize what thestashes might be associated with.git log -g
or git reflog
to view it, but it may be best visualizedwith gitk --all --date-order $(git reflog --pretty=%H)
gitk --all --date-order $(git fsck | grep 'dangling commit' | awk '{print $3;}')
git add
ed but not attached to a commit for some(usually innocuous)reason. git fsck | grep 'dangling blob' | while read x x s; do git show $s | less; done
will show you the files, oneat a time.git reset --hard SHA
your currentbranch to the history and current state of that SHA (probably notrecommended for stashes), you can git branch newbranch SHA
to linkthe old history to a new branch name (also not recommended forstashes), you can git stash apply SHA
(for the non-index commit in agit-stash), you can git stash merge SHA
or git cherry-pick SHA
(for either part of a stash or non-stashes), etc.git log -g
or, my preference, you can look graphically at gitk --all --date-order $(git log -g --pretty=%H)
git cherry-pick
orgit rebase -p --onto
those other commits over.git merge --abort
git rebase --abort