Introduction

Git probably is the most widely used version control system on the net especially on open source software development. It is a distributed version control system as opposed to centralised version control systems out there. Here I will go through Git basic command reference, from setting up a repository to do the basic tasks.

In very easy words in the distributed version control system each client has full mirror of the repository. So if any of the servers die (if there is one) ,any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

There are many different ways you can deploy git in your daily work. In this post I will cover the basics of how git works and the main commands. In another post i will cover the specific way we are using the git to manage our code development and branching and releases.

Download and Installation

All major linux distribution have git in their official repositories so you can install it with simple command line. All below commands are tested on Centos 7 operating system but they should be valid for most Linux distributions with some updates.

sudo yum install git-all

One time set up

You need to do these just once on any new computer.

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
git config --global core.editor vim

the –global switch will tell the git to update ~/.gitconfig file. This is the file that will apply to all the repositories that created under current user globally. You can also manually update these files if you know what you are doing.

Start a new code repository

Start tracking the codes and document changes with git is very easy. It won’t have any effects on your current working files and setup.follow the steps below.

Initialising

cd /opt/mycoderepo/
git init

this will add a directory called .git which contains all the files needed to get you going. At this stage git hasn’t started tracking your codes but it is ready to do so with going through the next steps.

Staging

git add .
git commit -m 'initial commit'

This will add all files and sub-directories in current location to the tracking system. You could be more specific and selective about the files you want to track. Like git add *.c.

At this stage git has got a full snapshot of everything in your project folder.

Go and start making changes to the codes.

When a new file is added to the directory it needs to be staged (added) to be included in the version. You also need to do the same if existing file has changed and you want that to be included in the next commit.

Checking current status

To see the status of the files in your repository and your working branch:

git status -s

-s is used for short status for more simplified report on the current status of the project.

Committing changes

Now that you have done some changes in the files and staged them, to make a snapshot of current files and move on you need to commit the changes. To do so, run:

git commit -m "I did my first changes"

Every time you perform a commit, you’re recording a snapshot of your project that you can revert to or compare to later.

if you always commit all your current changes into the next commit. There is a shortcut that will skip the staging step. So if you have done some changes to various files and you don’t want to mix and match them in more than one commit with staging them in different times just do this:

git commit -a -m "I did my first changes and skipped staging"

Undos …

removing files

If you have got a file in the commit and you want to delete it, you need to use git command to do it. Don’t just go and delete it in your folder. do below:

git rm myfile.c

This will remove the file from the tracked files and also will delete it from working directory.

But if you want just remove a file or series of files from your staging area and keep them in the directory. use this:

git rm --cached *.lo

Change commit message

Case: You just did a commit and regret the commit message you just submitted. You wan to edit the message.

git commit --amend

Un-stage a staged file

Case: You have changed a few files and added them all to the staging area. But now want to stage and commit some of them and not all.

git reset HEAD -- changedfile.c

Undoing modifications on a file

Case: You have done some changes on various files since last commit and you want to change one of the files back to the original version at last commit.

git checkout -- changemebacktowhatiwas.md

This is for the changes waiting for a commit in staging area. All the changes will be lost and not reversible. So be careful when using this command.

Tagging

Generally tags are used to mark the release points. So if you want to publish a new version of the codes as V2.0.1 then you can tag code at that point.

There are two types of tags, lightweight and annotated. I will skip the lightweight and use annotated one because that is the more useful one.

List current tags

Case: to see all current tags created.

git tag

Case: To show tags with certain pattern.

git tag -l "v2.0*"

Create a tag

Case: You have done the changes and commits. Now you want to tag the code.

git tag -a v2.0.2 -m “Version 2.0.2”

Tagging later

Case: In some stage you realise that you have forgotten to tag at a previous point. You have done some commits and possibly few other tags since. Now you want to add a tag to the point that commit with checksum ending with 9b6008 exists.

git tag -a v1.2 9b6008

Aliases

Aliases are used to simplify and personalise the way you use git. Rather than writing long commands you can define shortcuts to them with aliases.

git config --global alias.co checkout

If you think a naming convention in git doesn’t make sense then chances are each time you will try few commands to get it write. So aliases can help you make your own way of calling things. Unstaging makes more sense than resetting the head doesn’t it.

git config --global alias.unstage 'reset HEAD --'

Or the reason can be combination of two. Simpler and shorter and more logical to remember. If you just want to see the last commit details, why write too much nonsense?

git config --global alias.last 'log -1 HEAD'

Next time you just type in:

git co
git unstage changedfile.c
git last

Ignoring certain files

Case: You have one or series of files you don’t want to include in the commits. They can be system automated generated files, temporary files or internal log files. Or a file you write down your notes.

There is a file called .ignore in root directory of the repository, that does exactly what you want. You just need to add the right lines to it.

git cat .ignore

# ignore any files ending in “.o” or “.a”

*.[oa]

# no .a files

*.a

# but do track lib.a, even though you’re ignoring .a files above

!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO
# ignore all files in the build/ directory
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
# ignore all .pdf files in the doc/ directory
doc/**/*.pdf

Viewing exact changes in files to be committed

Case: You want to see the changes done but not staged yet

git diff

Case: You want to see the changes done and staged

git diff --staged

Reference

The Pro Git book, written by Scott Chacon and Ben Straub.

Git basic command reference