Version control and Git in general¶

What version control?¶

Version control means that you store the current state from a project or from a file, to which you can return later even if you modify the project or the file after the storing point. Versio history consists of these kinds of storing points in the order when each storing happened.

A very simple example on version control is an ”undo” action, implemented in almost all text or drawing editors. You have perhaps drawn a picture with Paint and realized that a line you just drawned is not good enough and you want to undo drawing it (e.g. with ctrl + z). The ”undo” action restored the previous version from the version control. This is the main principle in version control.

Version/revision control system is a tool that manages the above kind of version history from the source files of a project.

In addition to managing version history, a version control system enables to store different versions of the same project. These versions can be stored in different computers, and they can be worked on separately.

In the other, there is often a main version (or head version) that each person working in the project clones the themself. When they change their own copy, the changes can be integrated to the head version, from which the other project members can pull the changes to themselves.

When you are starting to work with an existing project that can be found from the version control, you must first clone the whole project to your own working environment - which is the remote desktop in the case of this course. Such a cloned whole is called a local repository - or shortly, a ”repo”.

Quite consistently, the common version of the project that can be found from the version control is called a central repository.

Workflow in version control¶

We will next consider how to work with the local repository, cloned from the central repository.

When you start to edit the files in the local repository, the changes will not be stored in that repository, instead the version control system first stores the changes in so called working copy.

When you are satisfied with the changes you have done, you can save them in your local repository. This means that you create a storing point in the version history, to which you can later return even if you change the working copy or create more storing points after the first one. Such engaging to made modifications is called a commit.

The version history consisting of commits will not be automatically updated in the central repository. Instead, to move the changes also to the central repository, you must publish them by pushing them into the central repository. After that the changes are visible for the other members working in the same project.

An important benefit of version control is that several programmers can work in the same project at the same time. But how can you get the changes, pushed from your teammate’s local repository to the central repository, to your own computer or to your own local repository?

The changes can be pulled from the central repository to your local one.

Q: But is it possible that persons working in the same project make conflicting modifications, since each one works with their own version and may push their changes to the central repository at any time? For example, in my repository I can modify the file that my colleague has removed.

A: Yes, it is. To avoid complicated conflicts you should push you changes to the central repository often enough. On the other hand, you should pull the changes made by the others before starting to made your own modifications. In this way, possible collisions (conflict) during integration (merge) can be solved safely in your own local repository. After that you push a working version into the central repository. The above kind of conflicts can be called merge conflicts.

The version control system Git¶

On this course, we will use a version control system called Git. We will use it both for version control and for submitting exercises. You will learn the basic use of Git, but please notice that the next programming courses assume the basic knowledge of Git, on top of which they will teach you more advanced use of it. Therefore you should not think Git as a force that you use only as minimal as possible, but you should think it as a useful tool used by programming professionals.

The most essential benefits of version control can be achieved in projects with several programmers. This does not mean that using version control in single-person projects is useless. If you use version control systematically in your projects, you can return to later versions when you realize that you have done something stupid. Examples of such stupid things are removing an important file by accident and a failed trial to implement a new feature. If you have copy of the project state before these kinds of actions, you can easily return to the earlier state.

Git as a version control system is very versatile. The way it will be applied on this course is not the only one, but this way suits the requirements of the course quite well. You should not worry if you later see different kind of uses of Git.

At the moment Git is the most popular version control system, and thus, you find a lot of material of it with Google. See, for example:

• Git book (Pro Git)

The material behind the above link is interesting for all of you but especially for those students that will continue to next programming course. Topics required on this course can be found from the two first chapters of the book.

On Plussa, you can find a course on Git:

• TIE-GIT git-kurssi / git course

Topics required on this course can be found from the two first rounds of the Git course. (Also the front page of Plussa provides access to the latest version of Git course.)

Note that Git can be used for the version control of any project, as far as the project contains files. Version control is not solely related to programming projects, although in such projects it is most often used. For example, the material of this course is stored in version control, which has rescued the situation every now and then.

Git workflow¶

The following figure shows the most essential workflow when using Git. The figure does not cover all possible cases, but it introduced most or even all the actions needed on this course.

If you use Git from the command line (Terminal), you need the following commands:

• for normal workflow: git add, git commit, git push
• for undoing things: git checkout, git reset [so these can be totally unnecessary on this course]
• for pulling changes done by other ones: git pull.

These commands can also be seen in the figure below:

We will return to these commands in the material section concerning Git usage in command line.

If you use Git from Qt Creator, you can find the actions of Git from the menu Tools -> Git with the following names:

• for normal workflow: Local Repository -> Commit, Current File -> Stage, Remote Repository -> Push
• for undoing things: Current File -> Undo Unstaged Changes for file, Local Repository -> Reset, Current File -> Undo Uncommitted Changes for file
• for pulling changes done by other ones: Remote Repository -> Pull.

These commands can also be seen in the figure below:

As you can see, both the figures show an additional storage called index, between the working copy and the local repository. This additional storage is described more precisely below.

Terminology concerning version control and Git¶

Version control systems and especially Git are associated with concepts and terms that crucial in understanding how to manage the systems. Previously when discussing the work flow, we just mentioned some terms, but here we will give a short explanations for them. The explanations are strongly based on Git.