First published: 13 Nov 2016
Last updated: 05 Jul 2018
Navigate to the folder where your repository will be, and then type
Confirm proper setup of repository by typing
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>.
git config command to specify repository specific settings, such as
git config user.name <name>, to define the author name for all commits in the current repository, or else set global settings, for example,
git config --global user.name <name> and
git config --global user.email <email> to set the user name and email for all commits by the current user.
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.
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.
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>".
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.
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.
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.
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>.
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.
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
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>
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.
Note: The last commit will have its SHA1 ID changed following the
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.