GIT

Introduction

If you do software development which goes any further than a simple hello world program, you need a version control system. Without it, many things will go hopelessly wrong. For example, if you make some mistakes, you have no straightforward way to correct them if you don't have version control.

Git is such a version control system. It has become the de facto standard, although there are popular alternatives like Subversion and Mercurial.

Despite being the most used system, Git is not perfect. Git has two noticeable characteristics. First, its conceptual models are very robust and rigorous, so it can handle large scale real world projects with confidence. But secondly, its user interface could have been done a lot better. The only officially supported user interface is the command line, which can be cumbersome and confusing. There are many Git GUIs, but most of them are not even worth trying, and even the good GUIs can only handle the common scenarios.

The blue sky scenario

That being said, working with Git is usually quite enjoyable. Most of the time you only need a handful of commands:

The first thing you have to do when working on an existing project is to check it out:

git clone git@gitlab.com:some/subdir/project.git

If you already have the project checked out, but some time has passed, you typically want to update your project to the latest remote version with:

cd project
git pull

Now you can start working in the project, and once you are happy with certain changes, you typically do something like this on the command line in the project directory:

git status
git add .
git commit -m "my commit message"
git push

A bit more background

Now let's elaborate a bit on the previous section.

The example of the git clone command in the previous secion assumes that ssh is working on your computer, and your public key is known at the git server, in this example gitlab.com. If this is not the case, you have to create an ssh public/private key pair, and register your public key at the server. Once this is in place, you can work with this git repo without ever having to type a password. A later section will describe ssh in more detail. Until then, you can also clone via https:

git clone https://gitlab.com/some/subdir/project.git

This form can also be use to clone external project which are read-only for you, and in this case you often don't need a username of password. If you do, Git will ask for them.

The git clone command does exactly what its name suggests: it copies the repository from the remote server onto your computer. You receive the complete history of the default branch, so even without a network connection you can keep working normally: creating commits, inspecting history, switching to existing local branches, etc. When the connection is restored, you can simply push your work to the remote server. This independence from the network is a core part of Git's robustness.

So, where does Git store all of this? The answer is in the .git folder. In principle, you never have to bother about what's inside the .git folder, that's why Git made it hidden. But when you are experimenting with a small toy project to learn Git, looking inside the .git folder gives you valuable insight into the internal workings of Git. And, to be honest, you need this insight. Git can not be mastered by memorizing its commands, you (unfortunatly) need to know quite a bit of its internal workings to make good disscion when things get more complex. Needles to say, since the .git folder is Git's internal domain, you should not make modifications indide it, unless your goals is to cause corruption. Also nice to know: you can delete all other files in your project, and you can restore them (up to the point that you committed your work) with just typing git restore . You can do this when you made a big mess of your working copy.