I had to make a little presentation about the Git version control manager system to my coworkers. Using that, I decided to create a simple post to give readers a general idea of how this amazing version manager works and give my coworkers a place to look at when they need to remember some Git command. So, let’s start.
Git is a distributed version control system that makes the creation of a repository and the maintenance of it much easier than SVN does. To have it working in your (Linux) system, you will have to:
Creating a repository
Now, let’s create a repository. I’ll do it in a
git folder in my
We are inside an empty folder, my project’s base folder, named
myproject. We want
to add it to our version control:
That’s it, this folder is now a git repository. Yeah, simple as that. You can type this command in a populate folder as well, but this just initialize the repository, we still have to add some content in it.
Your first commit
The repository is still empty. So, let’s create some content to add:
Ok, now we have a file to control. If you type now
git status, you will see it under the
Untracked files session. That’s because this file is not under version control. So, let’s
add it to the git control:
Now, if you type
git status, you’ll see:
Notice that, now, the file is in the
Changes to be commited session. That means that
now git knows about the file. Nevertheless, the file is still pending for commit:
commit command commits whatever changes are listed under the
Changes to be commited
-m option specifies the message of the commit that, in this case,
is “Adding my first file”. If you type now
git log, you will see:
Now, if you enter
git status again, it will say
nothing to commit. If you are
used to SVN, notice that we didn’t create any server, we didn’t enter any URL of
a remote repository. That’s because git is independent of that. This folder is
the repository. You can zip it, take to another computer, unzip, install git and
use it with no problem at all.
Now, lets change our file to simulate some evolution in our project:
git status will show us that
application.rb is modified, but it
will be under
Changes not staged for commit section. That means that
commit won’t consider it yet. We could enter, again,
git add application.rb
to add the file to our next commit, but there is a simpler way:
-a option makes that, before the commit is done, our changed files get
added to the commit. It’s important to know that this option doesn’t consider
new files, you will have to add them with a
git add command. If you created
a lot of files and don’t want to add them one by one, just enter
git add -A.
This will add them all at once.
Git has a very good branching control. If you enter:
You’ll see all the branches your repository has. By default, there will be
just one branch named
master. This is the main branch, like the
in SVN. I’m not going to teach about branches in Git here. Instead, I want
you to read this article before you continue.
Now let’s talk about having a central repository (or remote repository). I won’t teach here how to install and configure a Git Server, maybe in another post. Therefore, I’ll assume you already have it somewhere (you’ve heard about Github, haven’t you?) and you have the URL of an empty repository.
There is this command in git:
git remote. Type it in the repository we’ve
created and you’ll see:
Exactly, you will see nothing. That’s because our repo doesn’t have any remote
servers attached to it.
git remote holds a bunch of commands that help you
configuring a remote server repository.
Assuming the URL of our remote repository is email@example.com:myproject.git we add it this way:
add command adds (don’t you say) a new remote repository to our local one.
origin text is just the name we give to this remote repository, so you
can reference it when sending and obtaining commits, that we’ll see in a minute.
You can give any name you want, this name doesn’t need to match anything, you can
robert if you will, but you’d better not do that. As a convention,
origin should be the name of the main remote repository and all projects that
have remote repositories should have one called
After we added the remote repository, we can
push our local one to it. When
you run the
push command, all changes made in your local repository since
the last time you run this command will be sent to the remote one.
origin parameter identifies the remote repository we want to push to.
master one identifies what branch we want to use. If your repository is
an empty one, the branch
master will be created and it’ll receive all of what
is in your local
By default, every time you make a push, you have to type
origin master after
-u flag makes git keep track of this upstream, so that in the next
time you do a
push, you will just have to type
Alright. Let’s suppose somebody made a change in your repo and you want to update your local repository. You just need to run:
This will update your local files. In this command, you also can specify from
what repository and branch you want to pull changes with
git pull origin master.
However, if you used the
-u flag like I did before, that will not be necessary
origin will be the default remote.
Now, if you need to get this repository in another machine, you will use the
git clone command. All you have to do is go to the other machine, access
the folder you want the repository to be in and run this:
NOTE: This may not work depending on how your git users are set, but my focus here is to explain git and not how to setup a git server and users.
This will automatically create a folder with your repo name
myproject in the
current folder. Inside of it, you’ll have a regular local git repository.
You can make changes, commits, pushes and pulls. These last two you can run
without specifying the remote repo, since
origin will already be created
and set as the default upstream. This is done by the
Well, I think that’s more than enough for one post. I hope you enjoyed it.