Git is a distributed version-control system with server. A version-control system manages and keeps track of the modifications of the source files of a code (in this case, Lagamine). In a distributed system, the source files (*.F files) and the history of modifications are available on the computer of each developer, as well as on the server, which is the meeting point of all developers (figure 1).

Fig. 1 In actual facts, the « original » code is the one on the server. Each developer owns a local copy, called a clone, that they can update when they connect to the server. By connecting to the server, developers can send their modifications and/or get the modifications done by other developers.

Git gives the possibility to work with separate branches to allow developers to work on particular developments of the code without interfering with other developers, as illustrated in figure 2. The “master branch” can be considered as the official version of the code. Modifications should only be sent to this branch after they have been verified.

Fig. 2
For Lagamine, the choice was made to create one branch for each developer. This way, every developer can work on the code in their own branch without having any impact on the other developers' work. However, it is important to regularly send your modifications on the server and to keep your branch up to date with the master branch to avoid conflicts (conflicts appear when 2 developers modify the same file at the same time).

Each branch is initially a copy of the master branch. Each developer creates their branch on the server (GitLab) which they then clone on their computer.
A branch has two versions:

• A distant version on the server, that everyone can see;
• A local version on the developer’s computer, that they can modify as they wish.

A « commit » is a validation of the modification. This validation is done locally, after the modification has been done and verified. Each commit is associated to an identification number, the date, the author, and a short message that summarizes the modifications (figure 3). Commits must be done regularly to keep track of the modifications as precisely as possible.
The message is written by the person making the commit. It should be brief and contain the essential information on the changes made to the code.

Fig. 3

The “push” command is used to send commits to the server. Once the push is done, other developers can see the commits that were made on the pushed branch. A push is done between the local version and the distant version of the same branch (figure 4).

The “pull” command is the opposite of the push: you get the commits from the server on your PC. A priori, this is not very useful since commits are normally made locally. However, this can be useful for developers who work on 2 separate machines – they will have 2 local versions of their branch (one on each computer) and will exchange modifications via the server.

Fig. 4

Remark: There is also a “fetch” command, similar to the “pull”. This command allows your computer to receive information about existing commits on the server without integrating them to the active branch.