A Useful Git Tutorial – Part I


You know what I really hate about git?  Calling working directories as repositories and real repositories as bare repositories.   This is somehow confusing for people like me coming from older and outdated control version systems like CVS or SVN.

But if you keep in mind what I said above and give git a chance you’d realize is the most powerful control version system ever created.

There are tons of git tutorials out there but I’m pretty sure none of them cover how 90% of the people use git: clone an existing project, make their own changes and try to keep them updated with the original project. Eventually submit patches.


There are two kind of repositories in git:

  • Normal Repository:  This is your working directory.  This is where you mess with files, edit them, make your patches, and you can even run ./configure and make and try it out and issue a git clean after.
  • Bare Repository:  This kind of repository doesn’t have working directories.  This is what you’d call a shared repository where several developers can collaborate.

There’s a special kind of bare repository called remote repository, we’ll cover those soon.

First Things First

Before you start using git you need to at least configure your user name and email address since they will be included in every commit you make.

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

Also you should take the opportunity to configure your default editor. I’m all about vi, so I can’t stand editors like nano, joe, emacs, etc.

git config --global core.editor emacs

Quick and Dirty Start

If you want to create an empty repository where you can start working on source code files you use:

git init myproject

And that will create a directory called myproject that is a git repository.   But usually you will not create an empty repository, but you would clone a project instead and then start working on your changes:

git clone https://github.com/myproject/myproject.git

This will clone the whole repository in a working directory for you to change files in the same directory myproject.  By the way that github.com repository is a bare repository as you might guessed.


Now you’re gonna start to make your changes but you shouldn’t edit the files in the master branch. Instead you should create a branch where you can work on your changes without messing with the master branch.  To list all the branches in your repository:

git branch

To create a new branch:

git branch mybranch

And finally to start working on your branch (to switch to your new branch):

git checkout mybranch

Committing your Changes

You created your local repository and started making changes.   If you didn’t create any new file but just edited existing files and you’re ready to commit your changes, you first have to add the content to the index for the next commit:

git add -u

That will update the index with the new content from all the files that were edited.  If you created a new file, you have to add it:

git add src/newfile.cpp

Or, if you created a bunch of source files, you can add the whole directory:

git add .

This is a good time to tell you about the dry-run option in most git commands.  It will show you what would be done, without doing anything, so you can verify it will do what you want:

git add -n .

And now you’re ready to commit.

git commit -m "Initial commit"

Again, you can use -n to see what would be done.

Your commit will have a  SHA1 hash that you can use to reference it later.  Check your commits like this:

git log

In a next post we’ll see how to keep your source updated with the original repository; as you might have guessed while you are making changes other people can be also making changes to the code.  Also we’ll take a look how to compare your code with the master or any other branch, and push your changes to the upstream repository.

Too basic for you? Check out the Part II of this tutorial.

Leave a Reply