Une grande majorité de développeurs utilisent un logiciel de gestion de version pour leurs projets. Surtout sur les gros projets afin de s’y retrouver parmi la multitude de fichiers sources créés, modifiés, détruits par l’ensemble de l’équipe de développement.

Parmi ses logiciels le plus répandut est Git. Pour faire simple Gitlab est en réalité une interface web s’appuyant sur les commandes de bases de Git, comme le fait le très populaire GitHub.

Certes je n’ai pas de gros projets de développements, je ne me considère pas comme un développeur, mais plutôt comme quelqu’un qui script. Je dois reconnaître qu’il est  très confortable de gérer  les différentes versions de mes scripts via une interface graphique.

Dès le  début j’avais pensé utiliser Github pour mes petits projets de script afin de pouvoir garder un historique de mes modifications et de mes « dotfiles ». Mais Github est une société privée qui ne permet pas de configurer la visibilité par défaut d’un projet à moins d’avoir un compte payant, en effet tout est public sur Github. Ce n’est pas le fait de payer qui me dérangeait dans l’offre de Github, mais qu’encore une fois il faillait confier ses données à un tier. J’ai  pris la décision de me configurer un serveur Gitlab le petit frère de Github.

Cette nouvelle version ajoute principalement des options dans la visibilité des projets développés. Avant la version 6.4 nous ne pouvions définir que deux modes de visibilité :

  1. Privé
  2. Public

Il était très gênant pour moi lorsque je voulais partager des scripts de configuration sensible de les mettre en mode public, car n’importe qui pouvait cloner mon dépôt. A chaque fois j’étais obligé de modifier mes scripts en effaçant les variables sensibles.

Avec 6.4 c’est fini le nouveau mode « internal Project », permet uniquement aux personnes possédant un compte sur notre Gitlab de pourvoir cloner le dépôt. Depuis cette mise à jour cela me simplifie beaucoup les choses, car je peux travailler avec mes collègues de confiance et nous pouvons partager, modifier, comparer, nos scripts de configuration.

Je n’ai rencontré qu’une petite difficulté lors de la mise à jour de 6.3 vers la 6.4, pendant le changement de branche :

sudo -u git -H git checkout 6-4-stable error: Your local changes to the following files would be overwritten by checkout: somefile.txt Please, commit your changes or stash them before you can switch branches. Aborting

J’ai rectifié avec un :

git stash

Si vous voulez en savoir plus voici quelques liens utiles pour :

Bizarrement l’équipe de développement à choisi d’héberger le projet sur github et non sur leur propre plate-forme, peut-être pour éviter de s’attirer les foudres de son grand frère Github.