Notes on how to use Git, such as, initialising or cloning a repository, adding files to the staging area and committing staged files.
A pretty comprehensive tutorial is available at https://www.atlassian.com/git/tutorials/.
The official Git documentation is available at https://git-scm.com/doc.
Initialising a new Git repository
Navigate to the folder where your repository will be, and then type:
Confirm proper setup of repository by typing:
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 settings
git config command to specify repository specific settings.
For example, to define the author name for all commits in the current repository, use:
git config user.name <name>
Setting global settings
To configure properties that will be used in future commits in all git repositories present on a machine use the
--global option. For example, to configure the author name and email globally use:
git config --global user.name <name> git config --global user.email <email>
Viewing all global settings
To view all the Git global settings use:
git config --global --list
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.
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>".
Git uses a file named
.gitignore to read a list of filenames and directories to ignore so that they are never included in a repository. For example, compiled binary files, say, *.obj, *.pyc, and *.exe are in general not included in repositories.
The reason behind such a decision is that these files can be generated from source and most of them are intermediate or temporary files. In other words, they are not source code or material that has been created by a person so usually they do not need to be version controlled.
Files and directories that are commonly excluded from repositories should be specified in the global
.gitignore file. The global
.gitignore file is usually located in the user’s home directory on Linux systems. To find the exact location use the following command:
git config --global core.excludesfile
The above command can be used to specify a different location if required, as follows:
git config --global core.excludesfile <.gitignore_filepath>
Ignoring repository specific files
Each project is unique and so sometimes you will need to exclude files and directories which are project specific. In such a scenario, create a
.gitignore file in the root directory of the repository and include the directories, filenames or extension wildcard of the files you want to ignore, one per line. For example:
/temporary_dir/ logs/ *.temp
For all the patterns supported in
.gitignore files refer to the official Git .gitignore documentation.
Viewing the repository commit log
To view a log of the commits made to the repository, use:
For a more brief outline use:
git log --oneline
To view the history commit log for a particular file use:
git log <filepath>
To view a very detailed commit log, including lines removed and added, use the
-p option as follows:
git log -p
To view the names of the changed files only, use:
git log --name-only
To view the names of the changed files along with their status, use:
git log --name-status
The most common statuses are:
|Status Letter||File Status|
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
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>
Revert a commit
If you want to remove the changes introduced by a particular commit use:
git revert <commit>
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.
reset command 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, perhaps to commit changes in a more granular fashion.
Destroy all changes both committed since commit and currently in staging area and working directory
CAUTION: Use this command very carefully, only if you are sure of what you are doing.
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 and then type:
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
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.