Git basics

So yeah, lets talk about git, the basic stuff :)

What is Git?

Before we start talking about git, we need to understand how a basic scm works. So that takes us to the next question …

What is an SCM?

SCM stands for source control management, or source code management, which basically tells us that it will help us to manage our source code (we can manage other stuff othen than source code, but I will focus on source code in this post).

Yeah, great. But how does an SCM works?

Before SCM software existed, we had a lot of ways to control our code, like multiple folders, patches from version, and a lot of “creative” stuff… You can see where this is going, total chaos and meteors falling from the sky.

SCMs in general must provide a good way to version our code and manage how we are going to change it. Most of the SCMs use the following model:

Yeah, a graph. I love graphs by the way. But what does everything means?

The circles (or nodes) are commits. Commits are the unit of SCMs. Every time you change something, you can group multiple changes and commit them. When you are commiting stuff, try to keep it atomic, i.e. do your best to keep your commits small and with a very defined objective.

All commits are made on branches, forming something that looks like a chain. Usually SCMs have a principal, or master branch, where the tested and ready-for-production changes are merged.

On the beginning of ages, SCMs were centralized, that means that they had one central repository, and everyone that wanted to change something had the entire copy of the final code on their machine. Thats how CVS and SVN works. They are definitely not our main focus on this post, so lets move on :).

Git, on the other hand, is a decentralized repository, which means that everyone has a copy of the repository, and all the changes that were made. But why is that better than the centralized model?

When you decentralise stuff, your branches are also decentralised, so you can make a lot of branches for yourself, without worry about their names, and consequently your branches are usually smaller and more manageable.

Your work is done faster, because you have the entire repo on your machine, and only sync with the remote repository when you need.

You can also create repositories much more easily, and thus create repositories to manage other simple stuff, like a server configuration that you don’t want to remember all the stuff you changed, or a simple text file that you are editing right now, like this post that i’m writing.

That what git is, and it’s also why he usually works better than any other scm available

Great, but how do I do all this good stuff on Git?

Git Basics

Let’s see how all this basic stuff works on git. I work only on the command line, and I think it is faster than using some kind of graphical interface like sourcetree. I highly recommend that you start on the command line to understand how git works, and if you find a GUI that satisty your needs later, then use it.

You can download git here for Windows or any other platform, or use your yum, apt, brew, whatever to download it.

git clone

When you want to work on a repository, you need a repository :). There are two ways to obtain that.

You can clone a repository from the origin simply using:

$ git clone <repository_url_here>

This will clone the entire repository available on the url you provided to your machine. Try it out with any github project, like Ghost.

git init

The other way to obtain a repository is to simply create a new one. On the next commands, I will use the repository that we created instead of the cloned one.

Go to anywhere in your filesystem, create a folder, enter it and run the following command:

git init

And that is it. It is really it, you just created an entire git repository on your machine. That is another thing that git diferentiates itself, in CVS or SVN you would need a lot more time than you just used.

git status

Git status is a command that you run every time, like those crazy ops guys that cannot run two commands without one being ls.

git status will tell you what is the current state of the repository, like in what branch you currently are, what files are untracked, which files you modified, what is staged and how many commits you are ahead or behind of the origin on the current branch.

This is an example output from git status:

On branch master  
nothing to commit, working directory clean

As we can see, now we know that we are on the master branch, and we haven’t done any changes on our code.

git add

Now that you created your repository, you want to put stuff in it. Lets add some files.

First, create a new file on your repository directory:

touch file1

If you run git status now, you will see that you have one untracked file. This means that your repository has never seen that file, and you must tell it that you want to start tracking the changes that are made on the file. We can do that by using the git add command:

git add file1

If you git status now, you will see that the file is now to be commited, or staged. This means that when you commit, this change will be on the commit.

git commit

Now that your file is staged, you want to commit that.

To do that, we simply run:

git commit -m 'Commit message goes here'

As I said before, try to make atomic commits, avoid at all costs commits that have comments like ‘Fixes everything’ or ‘Add button to submit form and create a new model for horses’.

Choose your commit message carrefully, if you are adding a file, don’t write on the commit message ‘Adding file x’, we can see that on the diffs, try to explain what is the purpose that you are adding that file for.

git push

As I mentioned, git is a decentralized repository. So how do you sync all of those repositories? Using git push and git pull.

When you git push, you send all the commit you just made to the remote repository (you need to add an origin if you didn't cloned the repository, and you can do that using the git remote add command.

git branch

So let’s say that you are going to develop a new feature, and you don’t want to do that on the master branch, because the master branch is dedicated to production code.

You can create a new branch using git branch:

git branch feature1

Git works with commits, branches are simply labels on commits. Since you just created your branch, your feature1 branch points to the same commit as the master branch.

There is a special “label” that is called HEAD. This points to the branch that you are actually working on. In this case, we are still pointing to the master branch.

git checkout

If you want HEAD to point to the branch you just created, you need to checkout on to the feature1 branch.

To do that, run:

git checkout feature1

That simple. If you run git status now you will see that you are now pointing to feature1. Make some commits on this branch and experimenting checking out master again. You will see that the changes you just done are only applied to the branch you commited them. Your master branch is clean.

git pull

Let’s suppose that you are working with a lot of people. And these people changed some hotfixes on the master branch. You need to get that stuff into your local repository, and you can do that running git pull.

When you git pull, you bring all the changes made on the origin to your repository, sometimes they conflict and you need to manually merge them, so try to pull and merge oftenly, it will make you life muuuuch easier :).

git merge

Now that you git pulled the changes from the repository, you want to merge your feature into the master branch, 'cause you want your stuff shipped ASAP.

You can merge things using….. yeah, you guessed right, git merge.

First checkout the branch you want to bring the changes in:

git checkout master

Now do the merge of the feature1 branch into the master branch:

git merge feature1

If you didn’t altered the same stuff on both branchs, things will go well. Sometimes you will have conflicts, which must be solved manually.

Hell yeah, now you can git!

Try git by yourself on your personal projects, the only way you can get used to git is to use it, and I promise it will make your life much easier!

This site helps you to understand how git works visually, very good for beginners!

And this is it for this post, stay tuned for the second part, where I will talk about solving conflicts, rebasing, and other little tips to help you improve your git experience! Feel free to ask any questions on the commentary box!

Thanks for reading! :D

This article was published on my former personal blog (lett.be) in January 2015 and imported to Medium June 2017