No more git commit -am
git log -pShow the log with "patch text". Shows the changes in the commits like git show <sha>.
git diff --cachedShow changes on the Staging Index.
git diff <sha>/{branch-A} <sha>/{branch-B}Show changes between branch-A and branch-B. Also works with 's.
git diff <sha>/{branch-A} <sha>/{branch-B} -- {file}Show changes of a specific file between branch-A and branch-B. Also works with 's.
git fetch --pruneBefore fetching, remove any remote-tracking references that no longer exist on the remote. Local branches still need deleting.
git show <sha>Shows the changes in a commit (other objects can be 'shown'). Useful for reviewing the changes made in a revert commit.
git branch -d <branch-name>git add -pInteractively step through changes in the Working Directory to add to the Staging Index.
git commit --amendCompletely replace the last commit with a new one and it will commit everything that's currently staged.
git checkout -pInteractively step through changes in the Working Directory to discard.
git checkout {branch} -- {path/to/file}Checkout {path/to/file} from {branch}.
Useful for when you want to separate changes in a branch.
git checkout -p {branch} -- {path/to/file}A combination of the last two; interactively step through changes to apply to the Working Directory based on {path/to/file} from {branch}.
git resetCalling git reset with no additional arguments moves any changes on the Staging Index back to the Working Directory.
git reset -p behaves the same as git add -p allowing you to choose hunks to reset back to the Working Directory.
Nothing happens to the commit history.
git reset is the opposite of git add.
git reset --soft <sha> moves the HEAD to the specified commit. Preserving current changes.
git reset <sha>Move all changes from any commit after the id you've given it back to the Working Directory.
Adding --hard will delete the contents of the Working Directory and Staging Index.
Lost work is only recoverable from the ref log.
git revert <sha>Create a new commit which reverts the changes made in the commit.
git rebase <branch> feature branch feature branch
| |
v v
f1-f2-f3-f4 after `rebase` f1-f2-f3-f4
/ -------------> /
--m1-m2-m3-m4-m5 --m1-m2-m3-m4-m5
^ ^
| |
master master
Rewrites history. Only do this on local unpublished branches. "Rebasing" is changing the base of your branch from one commit to another, making it look as if you had created a branch from a different commit.
At the start of the rebase the current branch (and HEAD) will be moved (reset) to the commit being rebased on to. Each commit of the branch being rewritten will then be applied.
It is possbile for each commit on the branch being rebased (e.g feature) to have conflicts with the base branch (master)
if the commits make conflicting changes with what has been changed on the branch branch (master) since (m2 through m5).
In the above example, the feature will be reset to master (m5) and f1 through f4, in turn, will be applied.
git cherry-pick <sha>Apply the change of the specific commit on the top of this branch. Requires the Working Tree to be clean.
git reflogAs you’re working, Git silently records what your HEAD is every time you change it. Each time you commit or change branches, the reflog is updated.
git log -g will give the normal log output but for reflog.
A good way to recover work is to create a branch at the commit you want to recover.
git branch recover-branch <sha-to-recover>git cleanRemove untracked files from the working tree.
-n for dry run.
-f to force. Required for default git settings.
-d to clear directories.
git push origin {A}:{B}Push the state of of branch A to branch B. Useful for updating a deploy branch.
e.g: git push origin main:dev
git reset --soft <commit>Reset the HEAD to the (e.g HEAD~1).
This leaves all your changed files "Changes to be committed", as git status would put it.
For multiple commits to the wrong branch, see Mitali Cyrus's answer (not the accepted answer) to this StackOverflow Question.