What is Git
Basic guide to Git
Introduction
Git is going to be your best friend. Seriously. If you are tired of a situation like this:
then worry no more.
In this guide, I am going to go fast forward through the typical workflow and terminology of git. You can always find good tutorials online.
Why Git?
Typically we want to store all versions of the files, such that if we make a mistake, we can go back and correct it. Of all the tools that allow this, we use git because:
- it is easy to use;
- it is good for collaboration;
- and because companies want you to know it.
Terminology
Git is a Version Control System. It controls the version (i.e. the modification story) of your files. You will typically have a repository (repo), containing files and their history (though you will only see the files).
When you change the files, git gives you the chance to see what has changed. If you like the changes, then you can stage the changes.
You can modify as many files at once you want, and when you finish the modification and you staged all the files you need, you can commit the changes: git will take a snapshot of the current version of the files and remember them. History is written.
Generally, the people working on a project share their pieces of code through a central repo (more on that later). To share their work, they would push their changes to the server. To update their repo with the remote one, the developer pulls.
The repo has several branches, which are different versions of the same repo. Every repo has a master branch, and it can have many other branches named anything (though there are conventions on that, see the branching model we are going to use). Generally, a developer does not make his modification on master, but on a branch named differently
Practical example
So, we're sitting in front of the computer and we want to start a new project. We want to be cool, so we use git to store all versions of the files, such that if we make a mistake, we can go back and correct it. Let's see what to do, using basic linux commands (the stuff after # is a comment on the current line):
#!shell
$ mkdir project # we create the folder "project"
$ cd project # we switch into it
$ git init # we create our repo: we tell git that in this folder, we want to keep track
At this point, anything we do in the folder will be detected by git. If for instance we create a file (example.txt) we can run the command $ git status, and git will tell us there is an untracked file. We can start tracking it by running the command
$ git add example.txt
Using the terminology above, we have staged the changes. If we decide that the file is mature enough to be "written in the history" of our project, then we can commit the changes, using the command:
$ git commit -m "first commit"
This will create a "snapshot" of your folder containing all the current files and their status (in this example, just the file example.txt with whatever is written inside). Note the flag -m followed by the words "first commit": that is a message describing what are the changes made in that commit. It is mandatory to have any commit with a comment.
Now let's say we want to modify the file, after the modification our $ git status will tell us that the file is, well, modified. If we like the modifications, we can do as above: stage it and commit it. The procedure is the same:
$ git add example.txt
$ git commit -m "modified the file in some way"
And that's it for the "simple and gentle introduction to git". If it sucked, improve it!