This post list commonly used git commands.
remote
Git remote command lets you create, view and delete connections to other repositories.
git remote show <remote>
Show the details of <remote> repository
git remote -v
List the remote connections you have to other repositories.
git remote add <name> <url>
Create a new connection to a remote repository.
git remote rm <name>
Remove a remote repository.
git remote rename <oldname> <newname>
Change the name of a remote repository
git fetch <remote>
Fetch all of the branches from the repository.
git fetch <remote> <branch>
Fetch a specific <branch> from <remote> repository.
git push <remote> <branch>
git push <remote> --all
Push the specified branch to <remote>, along with all of the necessary commits and internal objects. Or, push all branches with --all option.
git push <remote> --force
Forciably push local branch to remote branch. Local branch commits will overrule the remote commits if they have conflicts.
refs and refspecs
A ref is an indirect way of referring to a commit. You can think of it as a user-friendly alias for a commit hash.
A refspec maps a branch in the local repository to a branch in a remote repository.
A refspec is specified as [+]<src>:<dst>.The optional + sign is for forcing the remote repository to perform a non-fast-forward update.
git push origin master:refs/heads/qa-master
This command pushes the master branch to the origin remote repo like an ordinary git push, but it uses qa-master as the name for the branch in the origin repo.
By default, git fetch fetches all of the branches in the remote repository. The reason for this is the following section of the .git/config file:
[remote "origin"]
url = https://[email protected]:mary/example-repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
To fetch only the master branch, change the fetch line to match the following:
[remote "origin"]
url = https://[email protected]:mary/example-repo.git
fetch = +refs/heads/master:refs/remotes/origin/master
You can also use refspecs for deleting remote branches.
git push origin :some-feature-branch
checkout
When you check out a previous commit, HEAD no longer points to a branch – it points directly to a commit. This will put the repo in a detached HEAD state.
In a detached state, any new commits you make will be orphaned when you change branches back to an established branch.
The -- sign is a way to tell Git to treat what follows checkout as a file and not as a branch. Suppose that you had both a file and a branch called stuff. Then the following command would seem ambiguous:
git checkout stuff
because it is not clear whether you are asking to checkout a file or a branch. By using -- you explicitly tell Git to checkout a file by that name/path. A file level checkout will change the file’s contents to those of the specific commit.
revert
Git revert prevents git repository from losing history. git revert undoes a single commit -— it does not “revert” back to the previous state of a project by removing all subsequent commits.
git revert is able to target an individual commit at an arbitrary point in the history, whereas git reset can only work backwards from the current commit. For example, if you wanted to undo an old commit with git reset, you would have to remove all of the commits that occurred after the target commit, remove it, then re-commit all of the subsequent commits.
reset
You should never reset to change history that have been shared with other developers.
git reset --soft (delete head)
--mixed (delete index and head) . This is the default behavior.
--hard (delete head, index and work directory)
git reset --hard HEAD
wipe out all local changes to match last commit
diff
git diff
This command will output the changes of all files in the repository. By default, it compares files in the work directory with last commit.
git diff path/to/file
git diff HEAD path/to/file
This command will output the changes of a single files in the repository. By default, it compares files in the work directory with last commit .
git diff --cached path/to/file
This command will compare file in the work directory with the staged version (–cached and –staged are the same).
We can also pass a commit hash to git diff to compare with file version from that commit.
git diff branch1 branch2
git diff branch1..branch2
Compare the differences of two branches. You can of course add a specific file path behind it to see changes to a specific file. The .. operator indicates the input to diff is the tip of both branches.
git diff branch1...branch2
The ... operator changes branch1 input to the shared common ancestor of the two diff inputs.
Reference links
http://marklodato.github.io/visual-git-guide/index-en.html
https://www.atlassian.com/git/tutorials