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?
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.
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.
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:
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 is a command that you run every time, like those crazy ops guys that cannot run two commands without one being
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
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.
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:
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
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.
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.
As I mentioned, git is a decentralized repository. So how do you sync all of those repositories? Using
git push and
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.
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 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
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.
If you want HEAD to point to the branch you just created, you need to checkout on to the
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.
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, 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 :).
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,
First checkout the branch you want to bring the changes in:
git checkout master
Now do the merge of the
feature1 branch into the
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