Git is a free and open source distributed version control system (VCS) designed to handle everything from small to very large projects with speed and efficiency.

Git is used for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files, providing the ability to roll back and maintain separate different versions at the same time. Git allows and encourages you to have multiple local branches that can be entirely independent of each other. The creation, merging, and deletion of those lines of development takes seconds. It is fast, nearly all operations are performed locally, giving it a huge speed advantage on centralized systems that constantly have to communicate with a server somewhere.

Git was built to work on the Linux kernel, meaning that it has had to effectively handle large repositories from day one. Git is written in C, reducing the overhead of runtimes associated with higher-level languages. Speed and performance has been a primary design goal of the Git from the start.

It’s distributed. This means that instead of doing a “checkout” of the current tip of the source code, you do a “clone” of the entire repository from a central location and work independently on some portion of code.

A very popular service that hosts Git repositories is GitHub , we can also mention BitBucket , GitLab and many others which are used by teams to host their code.


Install Git is easy on all platforms:


With Homebrew run

brew install git

Or download it Git for Mac


Download and install Git for Windows


Use the package manager of your distribution to install it. Like apt-get or yum.

$ sudo apt-get install git

You can find more info in Getting Started - Installing Git

Once Git is installed on your system, you are able to access it using the command line by running git.

New Repository

You can initialize a Git repository by running the command git init on the directory of your project.

That creates a .git folder in the directory where you ran it. It’s a hidden folder, so it might not be shown everywhere. If you are working on linux you can run ls -a to display a list of files/folders including the hidden ones.

Anything related to Git in your repository will be saved into this .git folder, all except the rules in the .gitignore file. A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected.

Clone a repository

You can create a copy of a local repository by running the command

$ git clone /path/to/repository

Or from a remote server by running the command

$ git clone username@host:/path/to/repository


Your local repository consists of three “trees” maintained by git. the first one is your Working Directory which holds the actual files. the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you’ve made.


You can see the status of the repository by running the command

$ git status

That will show a list of files for “Changes to be committed”, “Changes not staged for commit” and “Untracked files”


You can add changes to the Indexy running the command

$ git add <filename>

git add * or git add .

Note: that will add all the files that are untracked or with changes to the staging area


You can reset/remove files that are in the staging area by running the command

$ git reset HEAD <filename>

That will discard the changes of the file based on HEAD


This is the first step in the basic git workflow. To actually commit changes run the command

$ git commit -m "Message"

Now the file is committed to the HEAD, and permanently stores the edit you made into a record store (log), but not in your remote repository yet.


You can see repository history by running the command

$ git log

To see only the commits of a certain author (abellsmythe) run

$ git log --author=abellsmythe

To see only which files have changed

$ git log --name-status

To see a very compressed log where each commit is one line run

$ 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

For more info run git log --help


Branches are used to develop isolated from each other. The master branch is the “default” branch when you create a repository. A good practice is to use other branches for development and merge them back to the master branch when the feature is done.

You can create a new branch named feature_x based on the working branch and switch to it by running the command

$ git checkout -b feature_x

To switch back to master by running the command

$ git checkout master

You can delete the branch by running the command

$ git branch -d feature_x


Your changes are now in the HEAD of your local working copy (local). To send those changes to your remote repository run

$ git push origin <remote_branch>

That will send to remote server the history of your working branch, change <remote_branch> to whatever branch you want to push your changes to

You can also push one specific branch from your local to the remote server by running the command

$ git push origin <local_branch>:<remote_branch>

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it

$ git remote add origin <username@host:/path/to/repository>

Now you are able to push your changes to the selected remote server. remember that the origin is just an alias you can have multiples remote servers. You can see your remote by running the command

$ git remote -v


To update your local repository to the newest commit run the command

$ git pull

in your working directory to fetch and merge remote changes.

You can “pull” from one specific branch in the remote server by running

$ git pull origin <remote_branch>

Both commands will trigger an “auto-merge”


To merge another branch into your active branch run

$ git merge <branch>

Git tries to “auto-merge” changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown in the status. 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 <source_branch> <target_branch>

After that you must commit the changes

Replace Local Changes

In case you did something wrong, you can replace local changes by running the command

$ git checkout -- <filename>

This replaces the changes in your working tree with the last content in HEAD. Changes already added to the index, as well as new files, will be kept.

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this

$ git fetch origin
$ git reset --hard origin/master