This MindMap portray the most commonly used git commands. Commands are grouped together according to functions they performed. Brief description of each command are written under the comment sections and can be viewed using xmind software.
- This MindMap is work in progress and I will be updating it to include more commands and scenario.
- To download, visit https://github.com/adinanta/git-cheat-sheet/raw/master/git.xmind
- To open this MindMap, please download xmind at http://www.xmind.net/download
- It would be appreciated if anyone is willing to contribute some updates to this MindMap. If you want to contribute, please fork my repository at https://github.com/adinanta/git-cheat-sheet.git and send me Pull Request.
Git command MindMaps
Below are brief explanations of each commands group by their functions
Create git repository
Initialize folder to be git repository
Check Status of git repository. Perform this task to see if there is any changes to files or folder that have not been added to staging area or that have not been committed
add file called file_name to be tracked into git staging area. This has to be done before commit the changes
git add file_name
add every files or folders that have changed within the git folder to staging area
git add .
add any untracked files including files above the current directory to staging area
git add --all
commit changes that have are already been put in the staging area. git will open VI editor for writing commit messages
commit changes that have are already been put in the staging area where commit messages are set along with the command
git commit -m 'my commit'
view history of commits in detailed format
view history of commits in short format
git log --oneline
view history of commits from all branches including master branch in short format
git log --oneline --all
view history of commits from all branches and organize them with their associated branches. This view enable us to see which commit from which branch
git log --oneline --all --decorate --graph
look at the differences between original files within the last commits and files that have changes within the working directory that have not been commited
look at the differences between original files within the last commits and files that have changes and already added to staging area
git diff --staged
look at the differences between original files within the last commits and files that are stored 2 previous commits
git diff HEAD~2
look at the differences between original files within the last commits and files that are stored in commits identified by its hash id. These commits IDs can be retrieved through ‘git log –oneline’
git diff hash_id
revert file called file_name to previous version stored in commit_hash_id. To see all version of commit_hash_id, use ‘git log –oneline’. After this revert, previous file_name will be put in the staging area ready for the next commit. If further editing is required for this reverted file, move it to the working directory by issuing command ‘git reset HEAD file_name’. Once editing completed, add file_name to the stanging area for further commit by issuing ‘git add . ‘
git checkout commit_hash_id file_name
Discard changes of file_name in the working directory. After executing this command, the version of the file_name will go back the last known state or to the last commit
git checkout -- file_name
move file_name from staging area to working area for further editing. Once edit has been completed, the file can then be re-added to staging area for final commit. When we revert file_name from previous commit using ‘git checkout commit_hash_id file_name’, the file_name will be stored in the staging area.
git reset HEAD file_name
Go the the last known state or to the latest git commit
git checkout master
Go back the last known state or latest commit of a file called file_name We could perform this to recover deleted file called file_name
git checkout master file_name
Turn the entire repository back into the last known commit state. Perform this to go back to the last commit and discard any changes made. When many unwanted changes occurs and these changes have not been commited, we could use this to revert back to the last known good
git reset --hard
restore file_name from commit in the commit_hash_id. To display the available commits, issue command ‘git log –oneline’ once file_name is restored, issue command ‘git checkout – file_name’ so that the restored file is placed into the working directory which will then can be edited.
To save the edited file into a new commit, issue command ‘git add file_name’ and then proceed with “git commit -m ‘new commit’”
git reset commit_hash_id file_name
exclude files or folders
create file called .gitignore
include empty folders
create file called .gitkeep
Add remote git located at remote_address and give it a short name called origin. Short name can be anything, however by convention it is ussually called origin.
git remote add origin remote_address
git remote add origin https://github.com/test/abc.git
means that remote name is called origin and point to https address specified at the end of the command
Add remote git located at remote_address and give it a short name called upstream. When we fork someone else repository for collaboration purpose, we want to make sure that our forked repository are in sync with the repository of the original owner. For example:
- git remote add upstream https://github.com/budi/abc.git
- git checkout master
- git pull upstream master
In the above example, we add remote git called upstream that pointed to original repository that we previously forked. We then checkout to master branch in our local git and then pulling whatever changes that have occured at the original repository that we forked.
git remote add upstream remote_address
add branch called experimental
git branch experimental
create branch called experiment and then checkout or go to this branch after it has been created
git checkout -b experiment
list all available braches including remote branches
git branch -a
move from master or existing branch to experiment branch Note that experiment is the name of a branch created earlier through ‘git branch experiment’ command
git checkout experiment
delete branch called experiment note that delete cannot be done if we are still on that branch. Perform checkout to another branch before deletion
git branch -d experiment
merge branch experiment to the branch that we are currently checkout. For example: we have two branches called master and experiment. we want changes made in experiment branch to be incorporated into the master branch. To do that, we need to perform the following:
- checkout to master branch by issuing command ‘git checkout master’
- From master branch, issue command ‘git merge experiment’
- changes in experiment branch are successfully merged into master branch
git merge experiment
integrate changes at master branch to whatever branch we are currently in when performing this command. Similar to git merge, rebase integrate changes from one branch to the other except that after rebase operation, the original branch will include commit structure from the branch that perform rebase.
Best practice is not to use rebase when branches are used for collaboration with others
git rebase master
synchronize locally listed remote branch with the existing remote branch. There are cases when branches on the remote git have been deleted and references to those branches still exist locally. References to the remote branches can be listed by issuing command ‘git branch -a’
git fetch --prune