зеркало из
https://github.com/iharh/notes.git
synced 2025-11-03 23:26:09 +02:00
112 строки
4.1 KiB
Plaintext
112 строки
4.1 KiB
Plaintext
UNSTAGING:
|
|
|
|
git rm --cached database.yml
|
|
remove from staging, leaving it at work-dir (to be added to .gitignore later)
|
|
|
|
|
|
https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations
|
|
http://blog.ctp.com/2013/11/21/git-recovering-from-mistakes/
|
|
|
|
Command Scope Common use cases
|
|
--------------- --------------- ----------------------------
|
|
git reset Commit-level Discard commits in a private branch or throw away uncommited changes
|
|
git reset File-level Unstage a file
|
|
git checkout Commit-level Switch between branches or inspect old snapshots
|
|
git checkout File-level Discard changes in the working directory
|
|
git revert Commit-level Undo commits in a public branch
|
|
git revert File-level (N/A)
|
|
|
|
|
|
File-level Operations:
|
|
|
|
The git reset and git checkout commands also accept an optional file path as a parameter.
|
|
This dramatically alters their behavior.
|
|
Instead of operating on entire snapshots, this forces them to limit their operations to a single file.
|
|
|
|
|
|
CHECKING OUT
|
|
|
|
Checkout a branch or paths to the working tree
|
|
Updates files in the working tree to match the version in the index or the specified tree.
|
|
If no paths are given, git checkout will also update HEAD to set the specified branch as the current branch.
|
|
|
|
git checkout
|
|
<sha>
|
|
specific commit, endin up in a detached head state (need to create a new branch for it or force to the existing one)
|
|
<tree-ish> -- <path>
|
|
<tree-ish> refers to a commit hash, tag or branch,
|
|
<path> is the path of the file relative to the top directory of the project
|
|
|
|
-b <branch-name>
|
|
checks out a branch [branch-to-start-from]
|
|
-B <branch-name> <sha>
|
|
... at a specific <sha>
|
|
|
|
git checkout --track <remote>/<branch-name>
|
|
create a branch which will track remote branch
|
|
--track is needed if you have more than one remote, otherwise - by default
|
|
|
|
|
|
file-level checkout:
|
|
|
|
Checking out a file is similar to using git reset with a file path, except it updates the working directory instead of the stage.
|
|
Unlike the commit-level version of this command, this does not move the HEAD reference, which means that you won't switch branches.
|
|
|
|
git checkout [HEAD] -- <file>
|
|
check the <file> out to the latest state, known to git
|
|
git checkout -- .
|
|
|
|
|
|
RESETTING
|
|
|
|
git reset
|
|
--soft The staged snapshot and working directory are not altered in any way.
|
|
--mixed The staged snapshot is updated to match the specified commit, but the working directory is not affected. This is the default option.
|
|
--hard The staged snapshot and the working directory are both updated to match the specified commit.
|
|
|
|
git reset <commit>
|
|
reset to commit
|
|
result in a new dirty wrk dir in unsaved state
|
|
undo a commits (they will be dangling and GC-ed the next time)
|
|
|
|
use get checkout -- <file>
|
|
to compeletely remove <file>
|
|
|
|
git reflog can show us details about such tricks
|
|
|
|
|
|
git checkout <commit-id>
|
|
git rebase/merge <branch-name>
|
|
git branch -d <branch-name>
|
|
|
|
|
|
file-level reset:
|
|
|
|
When invoked with a file path, git reset updates the staged snapshot to match the version from the specified commit
|
|
|
|
git reset HEAD file
|
|
rollback the <file> to a HEAD (current committed branch rev) state
|
|
|
|
The --soft, --mixed, and --hard flags do not have any effect on the file-level version of git reset,
|
|
as the staged snapshot is always updated, and the working directory is never updated.
|
|
|
|
rollback the indexation
|
|
git rm --cached database.yml
|
|
remove from staging, leaving it at work-dir (to be added to .gitignore later)
|
|
|
|
|
|
REVERTING:
|
|
Reverting undoes a commit by creating a new commit.
|
|
This is a safe way to undo changes, as it has no chance of re-writing the commit history.
|
|
|
|
git revert <commit-id>
|
|
reverts changes, made by the <commit-id>
|
|
Note: do nota actually remove history log, like reset-cmd
|
|
|
|
Note: revert does not have a file-level counterparts like checkout/reset
|
|
|
|
Contrast this with git reset, which does alter the existing commit history.
|
|
For this reason, git revert should be used to undo changes on a public branch,
|
|
and git reset should be reserved for undoing changes on a private branch.
|
|
|