Linux‎ > ‎

Git Primer

Installation & setup

Install git

sudo apt-get install git

Configure Git

Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places:

  • /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option--system to git config, it reads and writes from this file specifically.
  • ~/.gitconfig file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option.
  • config file in the git directory (that is, .git/config) of whatever repository you’re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in .git/config trump those in /etc/gitconfig.

On Windows systems, Git looks for the .gitconfig file in the $HOME directory (%USERPROFILE% in Windows’ environment), which is C:\Documents and Settings\$USER or C:\Users\$USER for most people, depending on version ($USER is %USERNAME% in Windows’ environment). It also still looks for /etc/gitconfig, although it’s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer.

Your Identity

The first thing you should do when you install Git is to set your user name and e-mail address. This is important because every Git commit uses this information, and it’s immutably baked into the commits you pass around:

$ git config --global "John Doe" 
$ git config --global

Again, you need to do this only once if you pass the --global option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or e-mail address for specific projects, you can run the command without the --global option when you’re in that project.

Your Editor

Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system’s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following:

$ git config --global core.editor emacs

Your Diff Tool

Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff:

$ git config --global merge.tool vimdiff

Checking Your Settings

If you want to check your settings, you can use the git config --list command to list all the settings Git can find at that point:

$ git config --list LastName

Note: You may see keys more than once, because Git reads the same key from different files (/etc/gitconfig and ~/.gitconfig, for example). In this case, Git uses the last value for each unique key it sees.  You can also check what Git thinks a specific key’s value is by typing git config {key}:

$ git config FirstName LastName

Using Git

Initialise a Git repository

To create an empty repository use

cd <directory>
git init


git init <directory>

or ... you can create a copy of an existing repository with the clone command

cd <directory>
git clone <URL>


git clone <URL> <directory>

Staging files

Before Git can commit any files that must be first added to the staging.  This must be done whether they are new files or modified files.  Use the "add" command to add a file to staging.

git add <filename>

Once new files have been added to the repository you can pick up changes to all file with the command

git add -A

Un-Staging files

If you find that you have accidently added a file to staging in error you can either reset the entire staging area or remove files with the reset command

git reset HEAD <filename>

Ignoring files

With Git you can tell it ignore certain files.  You can do this by name or extension.  Standard wildcards are allowed "*" "." and "[abc]" syntax are often used.
Usually the ignore file is called ".gitignore" and is located in the root of the repository.

Setting up a .gitignore file before you get going is generally a good idea so you don’t accidentally commit files that you really don’t want in your git repository.

The rules for the patterns you can put in the .gitignore file are as follows:

  • Blank lines or lines starting with # are ignored.
  • Standard glob patterns work.
  • You can end patterns with a forward slash (/) to specify a directory.
  • You can negate a pattern by starting it with an exclamation point (!).

Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters separated by a hyphen([0-9]) matches any character in the range (in this case 0 through 9) .

Example .gitignore file:

# a comment - this is ignored
# no .a files
# but do track lib.a, even though you're ignoring .a files above
# only ignore the root TODO file, not subdir/TODO
# ignore all files in the build/ directory
# ignore doc/notes.txt, but not doc/server/arch.txt
# ignore all .txt files in the doc/ directory


If you have a  modified file in your workspace that you wish to revert, use the "checkout" command to revert the file back to the state of the previous commit.

git checkout -- <filename>


Once you change have been staged you can use the "commit" command to commit changes in the staging area.

git commit -m "commit message"

You can also use the -a option to skip manually adding files to the staging.  This will automatically update all files that have been previously added to staging and then do the commit

git commit -a -m "commit message"

This is exactly the same as if you had issued the following

git add -A
git commit -m "commit message"

Changing Your Last Commit

One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the --amend option:

$ git commit --amend

If your staging area is empty of changes, you will be prompted with the previous commit message and have an oppertunity to change it.  If the staging area has modifications, then these will also be added to the previous commit
After these three commands, you end up with a single commit — the second commit replaces the results of the first.

Removing files

It is not sufficient to remove a file from the workspace.  It must be removed from the staging area.  This is done with the "rm" command.  It will remove the file from both the staging, and the workspace (if it is still present in the workspace)

note: you can pass directroys and "glob" patterns to the command

git rm <filename>

If you have already modified the file and updated staging, then you will will also need to use the -f option to force removal (ie: force git to ignore of the uncommitted change)

git rm -f <filename>

If you ONLY what the file removed from staging, but NOT the workspace, then use the "--cached" option

git rm --cached <filename>

Moving files

Git provides the "mv" command to move files in the staging area and the workspace

git mv <old_filename> <new_filename>

If you have already modified the file and updated staging, then you will will also need to use the -f option to force removal (ie: force git to ignore of the uncommitted change)

git rm -f <filename>

If you ONLY what the file removed from staging, but NOT the workspace, then use the "--cached" option

git rm --cached <filename>

Viewing the commit log/history

To view the commit log use:

git log

Remote repositories

To viewing repositories (local and remote) 

git remote

To get more information on a remote use:

git remote show <repository name>

To add another repository

git remote add <shortname> <url>

To rename a repository

git remote rename <old name> <new name>

To remove a repository

git remote rm <repository>


There are basicly two types of tags.  Lightweight and Annotated

To view all tags use:

git tag

You can search for a tag using the following:  Note: you can use Gob patters

git tag -l <gob pattern>

To get more information on a tag use the show command

git show <tag name>

To create a lightweight tag

git tag <new tag name> <checksum>

If checksum is omitted the latest commit is tagged

To create an annotated tag you need to add the "-a" option

git tag -a <new tag name> -m <message> <checksum>

Sharing tags

By default, when you push to a server tags are not sent, you have to explicitly push the tags:

git push origin <tag name>

Alternatively you can push all tags with the --tags option

git push origin --tags

Branching & Merging

To create a branch, checkout the location that you would like to branch from (usually master) and run:

git branch <branch name>

To switch to the new branch, you just need to check it out.

git checkout <branch name>

You can combine the branch and checkout in to one command using the "-b" option:

git checkout -b <branch name>

To merge a branch.  First commit the branch, then checkout where you want to merge it to (usually master). Then use the "merge" command

git commit -a -m <message>
git checkout master
git merge -b <branch name>

Fetching, Pulling and Pushing


To get data from your remote projects, you can run:

git fetch [remote-name]

The command goes out to that remote project and pulls down all the data from that remote project that you don’t have yet.

If you cloned a repository, it adds that remote repository under the name origin. So, git fetch origin fetches any new work on the server you cloned from.

NOTE: The fetch command pulls the data to your local repository.  It doesn't automatically merge it with any of your work or modify what you’re currently working on. You have to merge it manually into your work when you’re ready.


If you have a branch set up to track a remote branch, you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from.

git pull


When you have your project at a point that you want to share, you have to push it upstream. The command for this is:

git push <remote-name> <branch-name>

To push the master branch to the origin server use:

git push origin master

This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream first, and then you push upstream, your push will rightly be rejected. You'll have to pull down their work first and incorporate it into yours before you'll be allowed to push.

Setting up a remote Repository

To create a remote repository that can shared, you are really creating a repositrory without a workspace.  This can be done with the following commands.
Note:  using the --bare creates the .git directory as the project directory.  --shared sets the permissions ready for sharing

git init --bare --shared <repositroy.git>


git clone --bare --shared <repository> <repositiry.git>


Garbage collection

This performs manual packing/compressing of git objects.

git gc

Integrity checking

For data integrity, both packfile and its index have SHA-1 checksum inside, and also the file name of packfile contains a SHA-1 checksum. To check integrity, run the git fsck command.

git fsck