Git Notes

First published: 13 Nov 2016
Last updated: 05 Jul 2018

A pretty comprehensive tutorial is available at
The official Git documentation is available at

Initialising a new Git repository

Navigate to the folder where your repository will be, and then type git init.
Confirm proper setup of repository by typing git status.

Cloning an existing repository

To clone an existing repository from a local machine or a remote machine accessible via HTTP or SSH use git clone <repo>. To clone it into a specific directory use git clone <repo> <directory>.

Configuring repository or global settings

Use the git config command to specify repository specific settings, such as git config <name>, to define the author name for all commits in the current repository, or else set global settings, for example, git config --global <name> and git config --global <email> to set the user name and email for all commits by the current user.

Adding files to the staging area

First time you add or creates files in a new repository you can add them all to the staging area in Git by using git add ..
The staging area in Git allows you to choose which changes you want to include in a commit. So even if you have changed multiple files you can add some files using git add <filename> commands or git add <directory> commands to add whole directory contents, and then commit only those changes using the git commit command.
This way each commit is as specific as possible so that one can easily identify the commit that introduced an issue or bug.

Commiting staged changes to repository

Once new and updated files have been staged using the git add command, you can commit the snapshot to the project history using the git commit command.
Doing so will launch a text editor where you should in 50 or less characters write a commit summary, and then follow that with points expanding on the specific details of the changes.
For example:

Summary of changes in commit
- Detail of a specific change in this commit.
- Details of other changes included in this commit.
- Details of last change included in this commit.

If you are commiting a small change and only need to include a one line summary you can use the -m option as follows git commit -m "<message>".

Ignoring files

Certain file types need not be included in a repository, for example, compiled binary files, say, *.obj, *.pyc, and *.exe.
To do so create a .gitignore file in the root directory of the repository and include either the specific filename or extension wildcard of the files you want to ignore, one per line.

Viewing the repository commit log

To view a log of the commits made to the repository, use git log. For a more brief outline use git log --oneline.

To view the history commit log for a particular file use git log <filename>.

To view a very detailed commit log, including lines removed and added, use the -p option as follows git log -p.

To limit the log entries to the last n entries, use the -n option as follows git log -n <number>, for instance, to list the last 4 commits use git log -n 4.

View old commits

By using git log one can learn the commit ID of past commits. This ID can be used to checkout old versions of the whole project or of a specific file.
The command git checkout <commit>, where <commit> is the unique commit ID, will restore the project to the state it was on that particular commit. This process does not result in any losses, all subsequent commits and current staged or unstaged changes are still available.
To go back to the current status before the checkout process, use git checkout master.

Checking out a file
On the other hand, checking out a specific file does change the current project status. To checkout a specific file use git checkout <commit> <filename>.
The checked out file is staged for commit, so if you commit at this point you will lose any changes performed between the commit from which the file was checked out and now.
If you do not want to lose changes and want to go back to the current status of the file use git checkout HEAD <filename>.

Revert a commit

If you want to remove the changes introduced by a particular commit use the git revert <commit> command. This will keep the whole repository commit history intact, by undoing all the changes introduced in the commit specified, staging them and appending a new commit. With the revert command the project history is not changed and specific commits can be reverted without the need to remove and re-commit all interim commits.

Reset a commit

Be careful when using the reset command since this results in changes to the project history.

It is usually used to undo changes in the staging area or working directory. Furthermore, reset should never be used on shared repositories.

Remove file from staging area leaving working directory unchanged
git reset <file>

Remove all files from staging area to match most recent commit
git reset

Reset staging area and all uncommitted changes
git reset --hard

Go back to a specific commit and update all files in working directory with changes introduced since that commit
git reset <commit>
This allows you to re-commit the changes in a more granular fashion, for example.

CAUTION: Destroy all changes both committed since commit and currently in staging area and working directory
git reset --hard <commit>

Adding forgotten files to the last commit

If you forget to add some files to the staging area before committing, there is an easy way how to add those files to the last commit.

First, add the files you previously forgot to the staging area using the usual git add command. Then, use git commit --amend –C HEAD. This last command will amend the commit specified by the -C option, which in this case is the last commit, i.e. HEAD.

Note: The last commit will have its SHA1 ID changed following the amend command.

How to organize software development projects on Git

Source control and versioning is crucial to manage any software development project, even more so when the project is substantial and many people are involved. To ensure project work flows smoothly, it is best to agree on a branching strategy before starting a new project. A pretty sensible branching model that is adopted quite extensively in the industry is the GitFlow branching model by Vincent Driessen, explained in detail in this blog post, A successful Git branching model.