I am here to talk to you about a feedback on the installation and use of Git and GitFlow for the management of development projects. The development workstations being under Windows (with servers under Debian and Ubuntu). The client chosen to manage GitFlow is SourceTree which integrates it natively. Git came to replace SVN as a source manager for different projects. He brought undeniable comfort in the management of our developments.

Installing a local referrer Git repository

The idea is to install a main repository (we’re not really talking about a server with Git) locally, in order to host our sources, and not to call on an external repository, such as via GitHub for example. So we installed Git on one of the servers. The installation is quite simple, you will find a step by step here for example . This deposit will be used to make the bridge between the git installed on the development workstations, which will push the code modifications, and the production which will be linked to the git (the releases being done by asking to repatriate the master, we will come back to this later far).

Uploading a first project to Git

We are now going to upload a first project to the referring repository. This project exists, but it is not yet versioned through Git. To do this, follow these steps:

• creating an empty repository
• loading sources into this repository

For the first point, it’s quite simple, you have to go to the machine hosting the Git referent repository and type the following command:

git init --bare myProject

which will create an empty repository named “myProject”.

To load the sources in this project, this time you have to go to the folder that contains the sources and type the following lines (you will have to install the Git package on this machine if it is not already done):

git init git 
add . git remote add origin 
ssh://git@myGitServer:22/git/repository/myProject git commit -m 'commit 
initial' git push -u origin master 

The first statement initializes Git. The second to add all content to the release manager. The third to connect to the referring repository (here called myGitServer, to be replaced by the name or the IP). The fourth to commit and the last to push to the referring repository. Once the push is done, the referring repository now contains the project sources.

Using GitFlow with SourceTree

Once the repository has been created, you will be able to load it into SourceTree via the “Clone / New” button. You then arrive on a first window. It asks you for the URL of your repository and the local folder (the one on your computer that you will then load as a project in your IDE). The repository URL will be the one created in the previous chapter.

You can then click on “Clone” to finalize the connection. Then, you will have to load the GitFlow, and this will be done with the dedicated button in the ribbon. The first click on this button, you will configure the different branches. Permanently in your project you will have two branches:

• develop (development branch)
• master (industry of production)

These branches will then be added to those that you create during your developments (we will come back to this). Normally you don’t have to make any direct changes to the develop and master branches. To modify the code and then integrate it into production, you have the various elements of GitFlox available:

• Features
• hot fix
• Release

Features

A feature corresponds to a new functionality in the project, the development of which will require several commits (therefore not an immediate modification but a development in the short or medium term, we will also come back to the notion of commit later). To create a feature, you must use the “GitFlow” button, “Start new feature”. A dialog box opens :

Just give a name to this feature (try to be as explicit as possible in relation to the development you have to do). When you click Ok, you will see it appear in the list of branches, under the feature folder.

It is possible to create several features in parallel, to open some and to delete them for example to make a test. We go from one feature to another by double clicking in the list of branches on the feature that interests us. Note that if you then modify a file, it will be modified in the selected feature (so positioning in the right feature is very important before coding). To code, you always use your usual IDE.

It is thus possible to have several features which work on the same files, while passing from one feature to another you will find the state of the file such as it was modified in the feature (very practical therefore). Note that for concurrent access to the same file modified in two features, you will need to be able to switch from one feature to another to commit or stasher the file(s) in question (we will come back to this a little later).

As development progresses, you can commit your changes. Note that the commit only affects the current feature. You can commit the same file multiple times to a feature as it is developed. The commit in this frame is a picture of the file in the feature. If you come from SVN, forget the notion of commit as you know it. Committing does not have the effect of pushing your code to the remote repository, it remains exclusively local.

To follow the changes and commit, you will have to go through the “File Status” tab of SourceTree:

 

In this tab, you will see your files created (blue question mark), modified (three yellow dots) or deleted (red) in the “unstaged files” section (zone 1). This part gathers for the feature or the current hotfix all the files which have been modified and for which no action has been done yet. If you wish to commit or stasher (corresponds to putting them aside for the moment, these are files in a state not yet ready to be committed, but whose modifications wish to be kept, this will have to be done for example to pass from one feature to another with concurrent uncommitted changes) you will need to tick them (this will move them to area 2) and click the commit or stash button. It will then be necessary in the lower area to enter a commit comment and click on the button.

If you do not want to keep the changes made, you can right click on the file and choose “Discard” which will have the effect of returning it to the previous state. Zone 3 also indicates the modifications made to the file.

When you have finished your feature, being positioned on it (it must therefore be in bold), you can via the “GitFlow” button choose “Finish feature”. Finalizing the feature will have two effects:

• this will push the changes to the develop (local) branch
• this will remove the feature

If you get an error when closing the feature, chances are it’s an uncommitted file, or a conflict.
Once the feature is finalized, you will have the modifications in your local develop branch. You can then “push” these changes to the remote develop branch. At that time, the modifications are not in production, they can pass with a release.

hot fix

A HotFix is ​​a bug fix in production, or a quick feature addition that only requires a commit. The Hotfix is ​​created via the “GitFlow” button, “Start new hotfix”. In the same way as for a feature, you will then be able to develop, commit the modifications and close the hotfix (via the “GitFlow” button, “Finish Hotfix”).

The impacts of finalizing the hotfix are different from closing a feature. Because the changes are pushed directly to the master branch. So, pushing the changes will push them to the remote master branch (as well as the develop).

Release

A release will make it possible to integrate into the master branch the features that have been completed and integrated into the develop branch. Just open the release (via the gitflow) by giving it a name (like 1.1.0) and close the release. Then just push the changes to the remote master.

Release

To put your project into production, Git must be installed on the production server and the sources must be linked to the repository. The production in this case is linked to the remote master branch.

Once these initial prerequisites are good, you can suddenly make your developments using features or hotfixes. You integrate everything into the local master branch, and push it to the remote (via push). Once everything is on the remote, production can load the remote master branch with this simple command (to be run from the root of the project):

git pull origin master

Updating your environment

To update your environment with the modifications that are on the remote branches, you can do a “fetch”. It will check if there are things to recover, but it is done automatically regularly. And a “pull” to actually retrieve the changes.

Update of a feature

If a feature takes a long time to develop, it may be interesting to regularly update it by integrating the modifications of the development. This will avoid too large a gap between the two and possible conflicts resulting from this gap. To do this, while being positioned on the feature to update (it is therefore in bold), click once on develop, right click and choose “Merge develop into current branch”.

Summary of actions by type

Summary of the passage of a hotfix

Start new hotfix…development…moving files from “unstaged files” to “Staged files”…commit…finish hotfix…push to SourceTree.
git pull origin master in prod

Summary of passing a feature

Start new feature…development…moving files from “unstaged files” to “Staged files”…commit…finish feature…push to SourceTree.
It will then be necessary to make a release including this feature (with others possibly) to pass it in production.

Summary of the passage of a release

The release will move the development into the master. So, you have to do a new release, close the release and do a push, then a git pull origin in prod.