GIT in a few steps

August 28, 2018

270

Git is a version control system created by Linus Torvalds that is rapidly becoming one of the most widespread in circulation, thanks to the increasing adoption of platforms such as github and bitbucket. In fact, many development teams are preferring it to other proven systems, such as SVN and CVS, both opensource.

Git vs CVS, SVN, etc

One of the main problems faced by a user approaching GIT is to compare it to other repositories such as SVN or CSV. Unlike these other versioning systems, however, the philosophy of GIT is slightly different, and before starting to use it is recommended to learn well the concepts behind this system.

SVN and CVS are centralized version control systems (CVCS), while GIT is a distributed version control system (Distributed Version Control Systems or DVCS).

Where is the server?

A centralized version control system predisposes the presence of a single server that manages all file versions. Each user checks the files using his own terminal.

In a distributed version control system, on the other hand, each client also acts as a server for itself and has a local copy of the repository.

In this article we will focus mainly on the “client” use of GIT, which is certainly the most used at the moment, thanks to some online platforms already mentioned. Nothing prevents you from installing the software on your own machine, for example by following this excellent tutorial.

How are the data stored?

SVN and CVS save the information as a list of changes made to the files and store the information they keep as a set of files and the changes made on each one.

GIT, on the other hand, considers its data as a series of snapshots of a mini filesystem. Every time the user commits or saves the status of his project, he basically makes an image of all the files at that time, saving a reference to the snapshot. If some files have not been modified, GIT does not clone them but creates a link to the same files as the previous version.

Work offline

Another very interesting aspect of GIT compared to centralized repositories is the possibility of working even in the absence of connectivity with the central server. The user can work on his local copy of the repository and make the changes public when the server returns available.

GUI for Git

When GIT is installed on your system, you can perform all command line operations, but of course, there are many free GUI clients available that you can use based on your operating system.

Windows

MAC

Linux

Structure of a GIT project

A GIT project is structured in three parts:

Working dir or working directory that contains files belonging to the current version of the project on which the user is working.
Index or Stage that contains files in transit, ie those candidates to be commissioned.
Head that contains the last files committed.

Initialization of a project

You can initialize a new GIT project in two ways:

Define our pre-existing project as a GIT Repository.
Clone an existing Git repository from another server.

Define our pre-existing project as a GIT Repository.

In this case you need to access the project directory and launch the command init. Git will create a new directory .gitin which it will create repository configuration files.

Adding and removing files from the repository

With previous operations, we have only indicated to the system that the directory contains a GIT project. To add files to the repository ( locale) you need to launch the command add followed by a regular expression that represents the list of files to be included.
Finally, you need to run the commit added files.

Here is an example in which we initialize the project, we add all the files with extension .c, file config.properties and file readme and we commitdefine the short description of what we are editing.

>> git init 		
>> git add * .c
>> git add config.properties
>> git add readme
>> git commit -m 'My first commit GIT'

Similarly to remove a file we will Hello.txtwrite for example:

>> git remove Hello.txt

Clone an existing Git repository from another server.

In this case it is sufficient to launch the command clone followed by the URL of the remote repository.

This operation is not to be confused with the command checkout of an SVN repository, since, in this case, all the information on the server will be downloaded on our system, including the historical information on the files and not just the current version.

In the following example, we clone the project whose address is git://github.com/myProject/myProject.git. If not explicitly indicated, the project will be downloaded to the current directory.

>> git clone git: //github.com/myProject/myProject.git
>> git clone git: //github.com/myProject/myProject.git / myDirectory / myProject
git clone myUser @ git: //github.com/myProject/myProject.git

Commit history, the log command

Using the command, log you can view the list of the last commits made. Each commit is marked by a SHA-1unique code, the date it was made and all the author’s references. The command, launched without arguments, shows the results in reverse chronological order, the most recent one is shown at the beginning.

Of course, numerous optional arguments are available, log which can be used with the command to filter the output.

>> git log

File status, the status command

Using the command status, you can analyze the status of the files. GIT will tell us which files are modified with respect to the previous snapshot and which ones have already been added to the STAGE area.

>> git status

Branch management

One of the strengths of GIT is the management of the Branch. Often in a development team, the need arises to have to start the development of some new features that will then be returned to production where a stable version of the software is already running. During the development phase of these new features, the need to fix ( fix ) a critical problem may emerge. This is the ideal scenario in which the branches must be exploited.

When a new development starts, it makes sense to create a new branch. The master branch can be reset at any time. Once the fix is finished, you can merge the two branches and continue working on the functionality that we had suspended to work on the critical problem.

Creating a branch, the checkout command

To create a branch, simply run the command checkout followed by the argument –band the name of the branch you want to create. When a new branch is created, GIT will automatically set it to the current branch or working copy.

>> git checkout -b 
>> git checkout -b my_branch

Of course, the Branch, as well as the files, can also be sent to the remote repository. To do this, simply run the following command:

>> git push origin &lt;branch name&gt;
>> git push origin my_branch

As already anticipated, there may be a need to return to work on a different branch from the current one. To be able to switch off the working dir, simply use the command checkout followed, in this case, simply by the branch name.

>> git checkout &lt;branch name&gt;
>> git checkout master

Deleting a branch, the branch command

It is also possible to delete a branch that we have previously created using the command branch followed by the argument -d(delete) and the name of the branch to be deleted.

>> git branch -d &lt;name of the branch&gt;
>> git branch -d my_branch

Merging of 2 branches, the merge command

Once the new features have been developed, it is necessary to merge the two branches. This operation is available using the command merge. GIT will import the new branch into the active branch. Of course, you need to pay close attention to this operation because there may be a series of conflicts between one or more files, which GIT cannot solve independently, and it is necessary to perform a manual merge.

>> git merge &lt;name of the branch&gt;
>> git merge master

Versioning of files on the remote repository

All the files we have committed, then present in the HEAD area, can be sent to the remote repository using the push command. It is also possible to define the branch in which our snapshot must be imported. The default branch is master but, of course, you can send the changes to a specific branch defined on the server.

>> git push origin &lt;branch name&gt;
>> git push origin master

Synchronization with the remote repository.

To perform an update from the remote server, simply launch the pull command that will download all the information on our local repository.

>> git pull

Flow summary

Now that we have a little clearer idea, we summarize the basic commands needed to work with GIT.

Init – allows to initialize an existing project.
Log – allows you to view a detail related to the commits made.
Status – allows you to view the status of files within the local repository.
Add – allows you to move one or more files in the index (or stage).
Commit – allows you to move one or more files in the HEAD.
Push – allows you to send one or more files to the remote repository (in one of the branches, usually the master).
Pull – allows you to download locally, changes on the remote server sent by other users of the repository.
Checkout – allows you to create a branch or switch to one of the available prenches
Merge – allows you to merge two branches.

Insights

Of course, other commands or arguments are also available, but in this article we have analyzed and described only the main ones that allow us, in any case, to be able to fully utilize the potential of GIT.

For those interested in deepening the complete list of GIT commands, we refer to an excellent a href=”https://help.github.com/articles/syncing-a-fork” target=”_blank” rel=”noopener”>guide on github, or to the gitref site, which presents a simple and effective navigable visual summary.

There are also some very effective cheatsheets: