A quick introduction to Git, to get you started

A version control system helps you to track the history of changes as people and teams collaborate on projects together. As the project evolves, teams can run tests, fix bugs, and contribute new code with the confidence that any version can be recovered at any time.

Git is a free and open source distributed version control system. It also offers features that makes it easy for multiple people to work on same code base.

Compared to earlier version control systems such as SVN or CVS that are centralized, Git is distributed meaning every developer has the full history of their code repository. This makes git operations such as commit, blame, diff, merge very fast.

With that basic introduction, let’s jump right into some basic git commands and the git workflow to get you started.

To create a new repository, create a new directory on your local environment, open it and perform a git init

This will initialize a new git repository, but if there is already a repository on Github and you want to create a local copy of the repository then you can close it by running the command
git clone http://path/to/repository
when using a remote server, your command will be
git clone username@host:http://path/to/repository

Workflow

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.

Staging and Committing your code

Committing is the process in which the code is added to the local repository. Before committing the code, it must be added to the staging area. The staging area helps to keep track of all the files which that have been modified, added, deleted or renamed and need to be committed.

Any file which is not added to the staging area will not be committed. This gives the developer control over which files need to be committed and keep other changes local.

You can propose changes (add it to the staging area) using
git add <filename>
git add *
This is the first step in the git workflow and now to actually commit these changes we use
git commit -m "An informative commit message about this change"
Now the files are committed to the HEAD, but not in your remote repository yet and is not yet available for other users to pull your changes.

Pushing changes

Your changes are in the HEAD of your local working copy. To send those changes to your remote repository so that other users can pull your changes, you execute
git push origin master
to push to a difference branch, change master to whatever branch you want to push your changes to.
If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it using the following command
git remote add origin <server>
Now you are able to push your changes to the selected remote server

Branching

Branches are used to develop features isolated from each other. The master branch is the “default” branch when you create a repository. It is common for development teams to have a dev and stage branches for development and testing and then merge them back to the master branch upon completion.

To create a new branch named “dev” and switch to it using

git checkout -b dev

Push this branch to remote

git push origin dev

Switch back to master

git checkout master

When you want to commit something in your branch, be sure to be in your branch. You can see all the branches created by using

git branch -a

and the current branch using git branch

To update your branch when the original branch from official repository has been updated you can do a

git fetch master

and then

git merge origin/master takes new commits by other developers from the branch master branch and adds them to the current branch. you can also do a rebase instead of merge.

git rebase origi/master takes new commits from the branch master, and inserts them below your changes. More precisely, it modifies the history of the current branch such that it is based on the tip of master, with any changes you made on top of that.

and finally to delete a branch you would use

git branch -d dev

Update & merge

To update your local repository to the newest commit, and update changes pushed by other developers, execute
git pull
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 conflicts might exist. You are responsible to merge those conflicts manually by editing the files shown by git. After merging the changes, you need to mark them as merged with
git add <filename>

View and compare changes over time

See Changes in a commit

git show <commit_id>

before merging changes, you can also preview them by using
git diff <source_branch> <target_branch>

Tagging

It is a good practice to tag your code release with a relevant tag to better manage different versions of the code base with human understandable tags. You can create a new tag named 1.0.0 by executing

git tag 1.0.0 1ab23cd4

where the 1ab23cd4 are the first 8 characters of the commit id you want to reference with your tag. You can get the commit id by looking at the Git history tree

Git History view in IDE

Logs

In its simplest form, you can study repository history using git log
You can add a lot of parameters to make the log look like what you want. To see only the commits of a certain user, use:
git log --author=<username>
To see a very compressed log where each commit is one line:
git log --pretty=oneline

To see only which files have changed:
git log --name-status
These are just a few of the possible parameters you can use. For more, see

Replace local changes

More often than not, you might do something wrong in your local working copy and you want to replace your changes with the last working verision in HEAD. You can replace local changes using 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

Hope this basic introduction is enough to get you started using git and if you need some help there is always --help option that you can use with any command.