This quick guide shows you all the basic Git commands and their usage.
Git is a distributed version control system that is widely used by a number of open source projects.
It was started in the year 2005 by Linux founder, Linus Torvalds.
In this tutorial, we are going to play around Git and learn how to get started with it.
In this tutorial we use Ubuntu, but you can use any the Linux distribution of your choice. Apart from installation, all commands are the same in all Linux distributions.
To install git run this command :
sudo apt-get install git-core
Setup Git globally:
After Git is installed, whether from apt-get or from the source, you need to copy your username and email in the gitconfig file. You can access this file at
Opening it following a fresh Git install would reveal a completely blank page:
sudo vim ~/.gitconfig
You can use the follow commands to add in the required information. Replace ‘user’ with your username and ‘firstname.lastname@example.org’ with your email.
git config --global user.name "User" git config --global user.email email@example.com
And you are done with setting up. Now let’s get started with Git.
Create a new directory, open it and run this command:
This will create a new git repository. Your local repository consists of three “trees” maintained by git.
First one is your Working Directory which holds the actual files. Second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you’ve made.checkout your repository using git clone /path/to/repository.
Checkout your repository (repository you just created or an existing repository on a server) using git clone /path/to/repository.
Add files and commit:
You can propose changes using:
git add <filename>
This will add a new file for the commit. If you want to add every new file, then just do:
git add --all
Your files are added check your status using
As you can see, there are changes but they are not committed. Now you need to commit these changes, use:
git commit -m "Commit message"
You can also do (preferred):
git commit -a
And then write your commit message. Now the file is committed to the HEAD, but not in your remote repository yet.
Push your changes
Your changes are in the HEAD of your local working copy. If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it first with:
git remote add origin <serveraddress>
Now you are able to push your changes to the selected remote server. To send those changes to your remote repository, run:
git push -u origin master
For other developers:
git format patch origin
Branches are used to develop features which are isolated from each other. The master branch is the “default” branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.
Create a new branch named “mybranch” and switch to it using:
git checkout -b <branch name>
You can switch back to master by running:
git checkout master
If you want to delete the branch use:
git branch -d <branch name>
Show the current branch you are in:
git branch <branch name>
A branch is not available to others unless you push the branch to your remote repository, so what are you thinking about just push it:
git push origin <branchname>
Update and Merge
To update your local repository to the newest commit, run:
In your working directory to fetch and merge remote changes.To merge another branch into your active branch (e.g. master), use :
git merge <branch>
In both cases, git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible for merging those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with:
git add <filename>
Before merging changes, you can also preview them by using:
git diff <sourcebranch> <targetbranch>
Revert that particular commit:
git revert <commit id>
Revert all commit
git revert --hard
Revert the last change
git revert ^HEAD
Fix the last commit:
git commit --amend
You can see the repository history using:
To see a log where each commit is one line you can use:
git log --pretty=oneline
Or maybe you want to see an ASCII art tree of all the branches, decorated with the names of tags and branches:
git log --graph --oneline --decorate --all
If you want to see only which files have changed:
git log --name-status
And for any help during the entire process, you can use:
Remove untracked files and directories from the working tree
git reset --hard <commit-nr>
git clean -f -d
Resync ALL git repo with new gitignore file
Remove all files cached
git rm -r --cached .
Add all files as per new .gitignore
git add .
Now, commit for new .gitignore to apply
git commit -m "New .gitignore"
git reset --hard
Resets the index and working tree. Any changes to tracked files
in the working tree since
git clean -f -d
Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.
If the git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f or -n.
This 2 table will provide extra understanding of the
git add command:
Git version 1.x:
Git version 2.x:
git add -A is equivalent to
git add --all
git add -u is equivalent to
git add --update
There are 3 levels of git config: project, global and system.
- project: Project configs are only available for the current project and stored in .git/config in the project's directory.
- global: Global configs are available for all projects for the current user and stored in ~/.gitconfig.
- system: System configs are available for all the users/projects and stored in /etc/gitconfig.
Create a project specific config, you have to execute this under the project's directory.
git config user.name "John Doe"
Create a global config
git config --global user.name "John Doe"
Create a system config
git config --system user.name "John Doe"
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
Full detais: Semantic Versioning
Subscribe to NL Slack
Get the latest posts delivered right to your inbox