Import d’un site existant dans aegir depuis un dépôt git

gdo_aegir

Dans cet article, nous allons voir comment importer un site existant dans aegir depuis un dépôt git, mais tout d’abord, voici un petit préambule pour bien comprendre le vocabulaire d’aegir.

Imaginons que vous ayez un site sur monurl.fr qui pointe sur /var/www/monsite (la plateforme) dans votre vhost avec un sous-répertoire /sites/monurl.fr (le site), le tout géré par votre dépôt git sous gitlab.

Pour faire simple aegir appelle un drupal sans base de données, une plateforme et un drupal avec sa base de données, un site :

  • une plateforme au sens aegir, c’est le dépôt git d’un répetoire drupal avec sa branche courante (qu’on ne peut plus changer à postériori)
  • une site au sens aegir c’est : à l’intérieur d’une plateforme, un répertoire dans sites avec le settings.php (généré par aegir, il ne faut pas y toucher), une base de données, un alias, et un vhost

GitKraken, une GUI viable pour Git ?

logoGitKraken

Les premiers pas dans Git peuvent être parfois hésitants et quelques fois rebutants.
Un nouveau vocabulaire, de nouvelles commandes à apprendre, des workflows à appréhender afin de pouvoir participer sur un projet.

Aujourd’hui, il n’est plus indispensable d’avoir passé quelques heures à comprendre Git afin de pouvoir commencer à l’utiliser, et même à l’utiliser au quotidien.

Le 25 Novembre 2015, Axosoft a mis en ligne une interface graphique (gratuite mais non opensource) dédiée à Git. Cette application, disponible sur les principaux systèmes d’exploitation, permet de réaliser les diverses actions proposées par git-cli; merging, pushing, branching, rebasing, partial file staging… Allons voir plus en détails de quoi il en retourne.

Les sous-modules de Git

Git-Icon-1788C

Les sous-modules de Git permettent d’imbriquer des dépôts Git dans une arborescence. Le dépôt principal contient les références aux sous-modules, et aux commits associés. Prenons un exemple :

Dans votre application, vous voulez utiliser une librairie gérée dans un autre dépôt que celui de votre application. Cette librairie devrait se trouver dans l’arborescence de votre projet, dans le dossier « libs ».

Les hooks Git

formation-git

Git est un système de versionnage bien pratique pour plusieurs raisons. Les plus communes sont probablement la souplesse avec laquelle il est possible de cloner et repartager n’importe quel dépôt, sa notion de branches très fonctionnelle grâce aux commandes avancées que la solution propose (commits interactifs, rebase, stash et bien-sûr : merge), ou simplement le fait qu’il s’agisse d’une des technologies la plus populaire, donc la plus supportée. Une raison secondaire, mais potentiellement aussi puissante réside dans son système de hooks (« crochets », en français) autorisant le couplage avec des applications externes.

Créer une archive livrable avec Ant

Dans le processus de livraison d’un projet, la première étape consiste toujours à générer une archive livrable à partir d’une révision ou tag du dit projet.

L’idée ici est de créer un job Jenkins qui s’occupera de la livraison complète après avoir préalablement tester l’applicatif. L’objectif étant en un clic de tester, packager, livrer puis déployer l’applicatif.
Seules les deux premières étapes seront traitées dans ce post, et ce par la création d’une tâche Ant.

Git contre Mercurial : pourquoi Git ?

Depuis la nuit des temps (1970), les geeks ont vécu une guerre longue et sanglante entre le vrai et le faux, le bien et le mal, Emacs et Vim. Plus récemment un autre type d’outils ont jeté de l’huile sur le feu en appelant une fois de plus les geeks à un nouveau combat par blogs interposés au lieu de réellement travailler. Je parle bien entendu de l’épineux débat entre Git et Mercurial.

Cet article prend parti pour Git et se penche sur quelques raisons pour lesquelles Git a fortement progressé dans sa domination au cours de cette lutte épique.

Mises en garde ooooouuuuuhh!

Avant tout, je voudrais être franc et admettre que je suis la dernière personne à affirmer que Git est parfait. Bien au contraire. J’ai passé beaucoup trop d’heures de ma vie à essayer d’expliquer pourquoi Git me donnait des résultats totalement inattendus. Plus particulièrement, je me sens nerveux et commence à être bizarre quand je dois expliquer les différents modes de la commande checkout. Malgré le fait que msysgit soit une version de Git pour Windows incroyablement efficace, après toutes ces années, il occupe encore la place d’un citoyen de second rang.

Quoi qu’il en soit, j’ai commencé mon usage des DVCS avec Mercurial, puis je suis passé à Git et ne suis jamais revenu en arrière.

Pourquoi en est-il ainsi?

Format de Stockage

Pour moi, l’unique partie la plus distinctive de Git est son modèle de stockage. Plusieurs avantages que je trouve à Git découlent de la façon dont il stocke et « pense » le contenu (de son référentiel).

D’un côté, Mercurial a tout misé sur les journaux incrémentaux, optimisant ainsi (raisonnablement) l’usage sur des disques lents. Quand à lui, Git stocke chaque fichier dans un référentiel simple. Tous les commits que vous faites, chaque version de chaque fichier, se retrouveront dans ce référentiel comme une entité distincte. Avant qu’il n’introduise l’archivage et la compression, ce procédé a été extrêmement inefficace. Mais l’idée était bonne, et est restée à ce jour. Il est important de noter que l’identité de chaque objet est un hash du contenu, ce qui signifie que tout est immuable. Pour changer quelque chose aussi simple qu’un message de commit, vous devez créer un nouvel objet commit avant. Cela conduit à…

Un historique plus fiable avec Git

Noooon, vraiment !

J’ai toujours été irrité par les affirmations disant que Git est « destructif ». Au contraire, je voudrais prétendre que Git est en fait la plus sûre de toutes les solutions de DVCS. Comme nous l’avons vu ci-dessus, Git ne vous laisse jamais changer réellement quoi que ce soit, il suffit de créer de nouveaux objets. Qu’en est-il de l’ancienne version alors ? Git, pourkoi-ta-pa-konservé-mes-modifications ?!?

Git assure en fait le suivi de chaque modification effectuée, en les stockant dans le reflog. Parce que chaque commit est unique et immuable, le reflog se contente de faire référence à chacune d’entre eux. Au bout de trente jours, Git supprime les entrées du reflog, de manière à ce qu’ils puissent être traités par le ramasse-miette. Il faut se le dire : Git ne supprimera aucun élément encore référencé. Les Branches sont évidemment la façon la plus utile de garder les références aux validations, mais le reflog est une autre et vous n’avez même pas à y penser!

La commande reflog, elle, vous permet d’inspecter cet historique des modifications, comme vous le feriez pour vos commits normaux et la commande « git log ». A toujours garder sous le coude !

1
2
3
4
5
6
7
8
> git reflog
5adb986 HEAD@{0}: rebase: Use JSONObject instead of strings
6a34803 HEAD@{1}: checkout: moving from finagle to 6a3480325f3beeecbafd351d30877694963a3f01^0
74bd03e HEAD@{2}: commit: Use JSONObject instead of strings
36c9142 HEAD@{3}: checkout: moving from 36c9142e81482f6c3eb8ad110642206a4ea3dfec to finagle
36c9142 HEAD@{4}: commit: Finagle and basic folder/json
1090fb7 HEAD@{5}: commit: Ignore Eclipse files
d6e3e63 HEAD@{6}: checkout: moving from master to d6e3e63889fd98e89e12e53a79bf96b53cbf9396^0

Réécrire l’Histoire

Ce que je n’ai jamais aimé avec Mercurial, c’est qu’il rend la tâche très difficile quand il s’agit de modifier rétroactivement les commits. Vous pouvez vous demander « Pourquoi voudrais-je faire cela ? ». Si une contribution affecte de nombreux fichiers ou implique une re-factorisation significative, il est plus facile d’examiner les modifications dans un contexte compréhensible. Avec Git, il est facile de « remonter dans le temps » et modifier les modifications antérieures si nécessaire. Ainsi, les journaux de modifications dans Git peuvent être des histoires soigneusement élaborées, plutôt que de fidèles (mais obscures) suites de modifications réalisées les unes après les autres.

Il existe une extension pour Mercurial qui fait essentiellement la même chose appelée Mercurial Queues (MQ). Les MQ sont un moyen d’empiler des pre-modifications de manière à pouvoir les réorganiser avant de décider finalement d’en faire un validation réelle. MQ est livré avec un tas de bouquet de commandes séparées (qui ne sont pas dans SVN !).

1
2
3
4
5
6
hg qnew firstpatch
hg qrefresh
hg qdiff
hg qnew secondpatch
hg qrefresh
hg qcommit

Dans Git, il suffit de faire ses commit comme d’habitude sans se soucier de ce qu’on en fera plus tard. Le moment venu, il y a juste chose que vous devez savoir faire : rebase interactif. Cette commande lance un éditeur de texte et vous permet de modifier l’histoire de Git au centre de votre contenu.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
> git rebase –interactive origin/master
pick   94f56db Debug an error raised when importing view
squash 772e7e8 Re-join comments using DELIM
reword a04f10e Error on filter branch – print line
pick   e09b0a2 Added troubleshooting for msysgit + Cygwin
fixup  276c49a Added troubleshooting for missing master_cc branch
pick   a2c08f6 Added exclude configuration
pick   4c09e5e Ignore errors from _really_ long file paths
pick   9f38cf0 Actually, use fnmatch for exclude

# Rebase f698827..9f38cf0 onto f698827
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like « squash », but discard this commit’s log message
#  x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.

Mercurial possède à peu près l’équivalent en l’extension histedit mais cette dernière utilise strip pour mettre à jour le référentiel qui est normalement incrémental, ce qui pour conséquence de générer un fichier de sauvegarde externe. Je me demande comment on peut extraire des informations historiques de cette sauvegarde ? Combien de temps dois-je les conserver ? De quelle nouvelle commande ai-je besoin pour la restaurer ?

Revenons à Git. Ce que je crains, c’est de perdre un commit plus vieux que la période de rétention de 30 jours du reflog. Si seulement il y avait un moyen d’empêcher Git de d’appliquer le ramasse-miettes au bout d’un mois ! Une façon, vous savez, d’apposer une étiquette pour une référence ultérieure « juste au cas où »…

Une branche, par exemple ?

Exact ! Parce que ces « sauvegardes » dans Git sont en fait juste des commits (les branches en moins), nous avons à notre disposition le reflog et, de fait, vous n’avez pas besoin d’apprendre un autre ensemble de commandes pour savoir les utiliser.

« Rendre les choses aussi simples que possible, mais pas plus simple ».

Git et les branches

Pendant un moment, la gestion des branches dans Git était la « killer feature ». Mercurial recommandait (et le recommande encore maintenant) de cloner un dépôt pour chaque branche. Attendez, on parle de DVCS et pas de SVN là ? Ils avaient aussi une commande dédiée « branch », qui appose une marque à chaque commit. Une fois apposée, le marquage était impossible à modifier sauf à fusionner ou clore la branche. Plus tard, suite à une forte demande, l’extension « Bookmark » a été introduite comme un clone direct de branches de Git, même si au départ vous ne pouviez pas pousser les bookmarks sur le serveur distant.

1
2
3
4
5
6
7
8
9
10
> git fetch
From bitbucket.org:atlassian/helloworld
* [new branch]      test       -> origin/test
565ad9c..9e4b1b8  master     -> origin/master

> git log –graph –oneline –decorate –all
* 9e4b1b8 (origin/master, origin/test) Remove unused variable
| * 565ad9c (HEAD, master) Added Hello example
|/
* 46f0ac9 Initial commit

Un avantage qui demeure cependant, c’est que les bookmarks dans Mercurial partagent un espace de noms unique. Pour comprendre ce que cela signifie, nous allons jeter un coup d’oeil à un scénario assez normal où quelqu’un a poussé certaines modifications sur le serveur.

« Je demande à la vraie branche master de bien vouloir se lever ! » Il n’y a évidemment rien de choquant à demander cela. Il se trouve simplement qu’il y a 2 branches qui ont le même nom, master. Mentionner l’espace de nom du serveur (« origin » dans notre cas) rend les choses beaucoup plus claires.

Qu’en est-il de Mercurial?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
> hg pull
pulling from default
importing bookmark test
divergent bookmark master stored as master@default

> hg glog
o changeset: 2:98c63da09bb1
| bookmark: master@default
| bookmark: test
| summary: Third commit
|
| o changeset: 1:d9989a0da93e
| | bookmark: master
| | summary: Second commit
|/
o changeset: 0:2e92d3b3d020
summary: First commit

Quand nous faisons un pull, vous pouvez voir que nous avons une branche (master) qui entre en conflit avec notre propre master et une autre (test) qui ne pose pas de souci. Parce qu’il n’y a pas de notion d’espaces de noms, nous n’avons aucun moyen de savoir quels bookmarks sont locaux et celles qui sont distants, et selon notre qualification de ces derniers, nous pourrions commencer à avoir des conflits.

Staging

Dans Git, le staging, soit on l’adore, soit on le déteste ! Git a cette chose étrange qu’il appelle confusément l’index. Certains l’appellent aussi « zone de transit ». Soit.

Toute chose qu’on souhaite ajouter à un commit dans Git doit d’abord passer par l’index. Comment placer le contenu dans l’index ? Avec « git add ». Cela est logique pour les utilisateurs SVN pour les nouveaux fichiers, mais ça peut devenir assez déroutant de devoir le faire pour les fichiers qui ont déjà un historique de modifications. La chose à garder à l’esprit est que vous « ajoutez » vos modifications, et non les fichiers eux-mêmes. Ce que j’aime à ce sujet, c’est que vous savez exactement ce qui va être envoyé dans l’historique.

Pour expliquer ce que je veux dire, une commande que j’utilise le plus souvent que d’autre est « patch« . « patch » vous permet d’ajouter des morceaux ou des extraits spécifiques dans un fichier, au-delà d’une approche tout ou rien.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
> git add –patch

diff –git a/OddEven.java b/OddEven.java
index 99c0659..911da1b 100644
— a/OddEven.java
+++ b/OddEven.java
@@ -32,6 +32,7 @@ public class OddEven {
* Object) and initializes it by calling the constructor.  The next line of code calls
* the « showDialog() » method, which brings up a prompt to ask you for a number
*/
+        System.out.println(« Debug »);
OddEven number = new OddEven();
number.showDialog();
}
Stage this hunk [y,n,q,a,d,/,j,J,g,e,?]? n
@@ -49,7 +50,7 @@ public class OddEven {
* After that, this method calls a second method, calculate() that will
* display either « Even » or « Odd. »
*/
–            this.input = Integer.parseInt(JOptionPane.showInputDialog(« Please Enter A Number »));
+            this.input = Integer.parseInt(JOptionPane.showInputDialog(« Please enter a number »));
this.calculate();
} catch (final NumberFormatException e) {
/*
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y

Vous pouvez constater que j’avais oublié de supprimer une instruction de débogage, c’est une bonne chose de l’avoir vu avant le commit ! Ce qui est bien c’ est que, si je le veux, je peux le laisser là mais en acceptant le deuxième « morceau ». Tout cela vient du même fichier et sans avoir à ré-éditer quoi que ce soit après que je me sois rendu compte de mon erreur.

Sans surprise, Mercurial a une extension de l’enregistrement qui imite ce comportement. Mais parce que c’est juste une extension (ou du moins une extension basique), il faut copier les modifications non mises en transit vers un emplacement temporaire, mettre à jour les fichiers de travail de stockage, valider et ensuite annuler les modifications. Si vous faites une erreur, vous devrez recommencer. Ce qui est agréable au sujet de l’approche Git, c’est que de manière fondamentale, Git connaît, sait et prend en charge l’index et ne doit pas toucher à vos fichiers. Lorsque vous exécutez un « status » après avoir fait vos modifications, vous pouvez vérifier si tout semble correct avant de continuer.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
> git status

# On branch master
# Changes to be committed:
#   (use « git reset HEAD … » to unstage)
#
#   modified:   OddEven.java
#
# Changes not staged for commit:
#   (use « git add … » to update what will be committed)
#   (use « git checkout — … » to discard changes in working directory)
#
#   modified:   OddEven.java
#

Pour ceux qui ont besoin de tester des changements qui ne sont pas dans l’index, il y a toujours « git stash –keep-index » pour archiver temporairement ce qui ne sera pas commité. Soit dit en passant, cette archive est stockée, sans surprise, comme un autre commit qui peut être mentionné par notre vieil ami reflog.

1
2
> git reflog –all
b7004ea refs/stash@{0}: WIP on master: 46f0ac9 Initial commit

Le jeu du blâme (git blame)

Une des choses intéressantes dans Git, c’est qu’il ne fait pas le suivi des renommages. Il s’agit d’une source de préoccupation pour certaines personnes, mais je pense que « Git a raison ». Ceci dit, qu’est-ce qu’un renommage ? C’est simplement le déplacement d’un contenu d’un emplacement vers un autre. Mais que se passe-t-il si nous déplaçons seulement des parties du fichier ? « git blame » est une commande très utile qui affiche normalement les dernier commits qui ont affecté chaque ligne d’un fichier. Avec la magie de l’option « -C » , il détecte les lignes déplacées d’un fichier à un autre. (Le « -s » dans ce cas consiste à supprimer certaines information de commits inutiles).

1
2
3
4
5
6
7
8
9
10
11
> git blame -s -C OddEven.java

d46f0ac9 OddEven.java     public void run() {
d46f0ac9 OddEven.java         OddEven number = new OddEven();
d46f0ac9 OddEven.java         number.showDialog();
d46f0ac9 OddEven.java     }
d46f0ac9 OddEven.java
565ad9cd Hello.java       public static void main(final String[] args) {
565ad9cd Hello.java           new Hello();
565ad9cd Hello.java       }
d46f0ac9 OddEven.java }

Notez que ce ne sont pas toutes les lignes qui proviennent de cet unique fichier. Cet enfant terrible n’a pas d’équivalent Mercurial.

Conclusion

Git signifie ne jamais avoir à dire, « vous auriez dû … ». Il arrive cependant que Mercurial dise exactement cela. A la seconde ou vous voulez re-baser ou modifier un commit ou utiliser des branches de référentiel unique (aussi appelés bookmarks) — je sais que je fais ça tous les jours — vous marchez à l’extérieur de la zone de confort de Mercurial. Le format du référentiel conçu pour des ajout incrémentaux a été intentionnellement conçu sans cette possibilité à l’esprit. Je suis d’accord avec Scott Chacon (de GitHub) qui dit que Mercurial est un « Git Lite ».

Git n’est pas parfait. Cependant, je dirais qu’il y a des choses plus importantes que d’avoir une ligne de commande en peluche. Bien sûr, ce serait bien si Git faisait un peu mieux les choses, affichait des messages d’erreurs moins cryptiques, était plus performant sous Windows, etc.. Mais à la fin de la journée, on se rend compte que ces choses sont superficielles. Utilisez un alias si vous n’aimez pas une commande particulière. Arrêtez d’utiliser Windows (non sérieusement !). Le format du référentiel décide de ce qui est possible avec nos outils DVCS, maintenant et pour l’avenir.

Cet article est une traduction d’un article de Charles O’Farrell, développeur chez Atlassian, qui se focalise sur les raisons pour lesquelles une équipe pourrait choisir Git plutôt que son DVCS habituel. Charles a pris le temps de coder sous de multiples DVCS et a passé un moment à basculer des utilisateurs de ClearCase à Git.

Gestion des versions avec Git

Présentation

Git est un utilitaire de gestion de versions décentralisé (comme Mercurial). Git sauvegarde l’intégralité de l’historique dans un dépôt en local (dossier .git/ caché à la racine du projet). Toutes les manipulations standard sont faites en local (commit, checkout, reset, …), ce qui permet de travailler hors connexion sur le projet.

Pour permettre le travail collaboratif et donc bénéficier des modifications des collaborateurs, on peut récupérer ou envoyer les fichiers simplement en connaissant l’adresse distante. Les transferts se font à l’aide des protocoles GIT (9418) ou http, https ou ssh.

On peut par exemple récupérer un projet complet sur GitHub.

Installation de Git

On peut télécharger Git (sous licence GNU GPL) à l’adresse suivante : http://git-scm.com/downloads. La version utilisée dans ce tutoriel est 1.8.0.

Pour prendre un exemple d’utilisation, sous Windows, après l’installation, on dispose de plusieurs manières d’utiliser Git :

  • par l’interface utilisateur (Git GUI)
  • par le menu contextuel dans l’explorateur de fichiers (clic droit)
  • ou en lignes de commandes (Git Bash).

Afin de bien appréhender le fonctionnement de Git, il sera abordé ici uniquement le fonctionnement en lignes de commandes.

Configuration de Git

Lancer l’utilitaire en lignes de commandes par le menu Démarrer et y taper :

git config --global user.name "Nom d'utilisateur"
git config --global user.email "utilisateur@ideotechnologies.com"

pour configurer les informations utilisateur afin de reconnaître ses contributions au projet.

Les commandes de cet utilitaire sont les mêmes que sous Unix  (ls, cp, mkdir, …)

Usage de Git

Au préalable, il faut avoir un projet existant, afin d’avoir des fichiers à ajouter au dépôt. Une bonne pratique consiste à faire le premier commit avec uniquement les dossiers racines vides du projet et un fichier README.md, mais on va ici traiter un unique fichier afin de comprendre comment Git fonctionne.
Pour ce faire, on peut par exemple créer un nouveau projet avec Eclipse : projetGit avec pour dossier de sources /src/main/java/ et d’output : /target/classes.
De cette façon, les fichiers .class seront disponibles dans le dossier /target/classes et n’auront pas à être commités.

Création d’un dépôt Git initial et premier commit

Par l’invite de commandes, se rendre dans le dossier racine de Git et lancer git-bash.bat ou lancer le terminal par le raccourci du menu Démarrer. A partir de ce point, il reste ouvert pour l’exécution de commandes Git.
On crée un dépôt Git très simplement une fois arrivé à la racine du projet :

git init

L’utilitaire a créé un dossier caché .git/ et comme l’on n’a encore ajouté aucun fichier à ce dépôt, il est vide. Créer un fichier vide README.md à la racine du projet.
Pour ajouter ce fichier au dépôt, il faut taper :

git add README.md
git commit -m "Creation du depot"

Dans ce cas, Git informe qu’il a ajouté un fichier au dépôt (README.md).
Il faut toujours spécifier un message après -m qui permet d’indiquer brièvement ce que contient la version qui est commitée.
Dans le projet, ajouter une classe Tutoriel qui contient la fonction main() et l’affichage d’un texte.
Extrait de src/main/java/Tutoriel.java :

...
public static void main(String[] args) {
System.out.println("Version initiale");
}
...

Publier les modifications :

git add src/main/java
git commit -m "Version initiale"

Dans ce cas, Git informe qu’il a ajouté le fichier Tutoriel.java au dépôt.

Sauvegarde des modifications

Modifier la classe Tutoriel comme suit :

...
System.out.println("Deuxieme version");
...


Puis afficher les différences avec la dernière version commitée :

git diff


Fichier, par fichier (un seul dans notre cas), les lignes inchangées sont affichées en blanc. Les lignes modifiées sont considérées comme une ligne supprimée (en rouge) suivie d’une ajoutée (en vert).

Puis procéder au commit :

git commit -m "Deuxieme version"


A noter que si vous souhaitez faire ces deux opérations en une seule étape, vous pouvez utiliser l’option -a qui ajoute automatiquement les modifications apportées :

git commit -a -m "Deuxieme version"


Vérifier que git diff ne retourne rien.

Parcours des différentes versions

Pour afficher l’intégralité des commits effectués jusqu’alors, taper :

git log


Pour revenir à une version commitée, taper :

git checkout 25fb5de5cb5d9cc6f8d7c13e5418e1d16b2ca964

(copier le SHA-1 correspondant au commit voulu).
Si vous modifiez le fichier Tutoriel avec :

...
System.out.println("Troisieme version");
...


Pour revenir à la dernière version commitée (et écraser toute modification non commitée) :

git reset --hard HEAD


De retour à Eclipse, confirmer le remplacement du contenu du fichier Tutoriel.java. On obtient donc :

...
System.out.println("Deuxieme version");
...


Git est revenu à la version en tête (HEAD) et la troisième version non commitée est écrasée.

Gérer des branches

Avec Git, on peut créer et modifier des branches, puis les rassembler avec la branche principale (master).
Pour créer une nouvelle branche (sans rien faire d’autre) :

git branch nouvellebranche master

(ou remplacer « master » par le nom de la branche en cours)

et la sélectionner :

git checkout nouvellebranche

Modifier la classe Tutoriel avec :

...
System.out.println("Nouvelle branche");
...

Vérifier le git diff, et le git log puis lancer le commit :

git commit -a -m "Nouvelle branche"

Comparer le contenu des branches nouvellebranche et master :

git diff nouvellebranche master

Etant donné que le commit de cette version a été effectué uniquement dans la branche nouvellebranche, on observe un résultat identique à celui que l’on aurait en étant dans la branche master.
Pour récupérer le contenu de la branche nouvellebranche sur master, on exécute :

git checkout master
git merge nouvellebranche

Revenir dans la branche nouvellebranche et modifier la classe Tutoriel :

...
System.out.println("Nouvelle branche avec une modification");
...

Commiter ces modifications dans la branche (nouvellebranche) puis revenir dans la branche master.
La classe Tutoriel contient :

...
System.out.println("Nouvelle branche");
...

sans la modification !
On peut créer un nombre quelconque de branches. Cette pratique est fortement encouragée si l’on veut effectuer des modifications importantes qui risquent de prendre du temps ou ne sont pas aisées ou d’une manière générale lorsque l’on souhaite proposer une évolution de code dans un mode collaboratif.

Travail collaboratif

On peut récupérer un clone d’un projet distant par la commande :

git clone adresse/du/depot/distant.git

Ainsi, tous les fichiers du projet à l’adresse du dépôt distant sont accessibles dans le dossier courant.
Pour travailler à plusieurs sur un projet avec Git, il n’est pas nécessaire que chaque utilisateur ait une version de Git installée, mais qu’il connaisse son adresse IP (commande ipconfig /all dans Windows, ifconfig | grep inet dans Linux).
Pour récupérer les modifications d’un collaborateur sans affecter ses propres fichiers, effectuer dans un premier temps :

git fetch https://github.com/sprodhomme/tutorielgit.git

Par la suite, pour affecter ses fichiers avec les modifications des autres collaborateurs, effectuer un :

git pull https://github.com/sprodhomme/tutorielgit.git

Dans ce cas, il est demandé de fournir son adresse mail et son mot de passe puis la confirmation du transfert est affichée.

Intégration de Git avec l’IDE

Git s’intègre facilement avec tous les IDE couramment utilisés (Eclipse, NetBeans, IntelliJ, …).

Il est possible d’ajouter le plugin « EGit » dans Eclipse, fourni dans le dépôt officiel de la release d’Eclipse utilsée. Par exemple, pour Eclipse 3.7 (Indigo), le chemin est :
Indigo - http://download.eclipse.org/releases/indigo
Collaboration > Eclipse EGit

Dans ce cas, on retrouve les termes habituels de Subversion (commit, …). Pour ce faire, on ajoute le projet à un dépôt local dont on choisit l’emplacement et il sera migré vers ce dossier. On sélectionne les fichiers à ajouter et l’on fait le premier commit.
Par la suite, pour sauvegarder les modifications, on clique-droit sur le projet et l’on commite les fichiers que l’on souhaite. Il est toujours possible de cocher ou décocher les fichiers présents dans le dépôt local ou encore non ajoutés.

Conclusion

Git permet de travailler en local, ce qui permet de n’avoir presqu’aucun temps d’attente pour synchroniser ses modifications et réaliser les commits. Lorsque l’on est à nouveau connecté, on peut envoyer ses commits et merger les fichiers du projet avec les modifications présentes sur le dépôt distant. De plus, comme Git permet de travailler sans serveur centralisé, il est possible d’échanger facilement ses commits entre collaborateurs sans perturber un dépôt central.

Git permet d’avoir une grande flexibilité avec la gestion des branches, qu’il est fortement conseillé d’utiliser. Par recherche dichotomique, il est plus facile de retrouver la source d’une régression.

Pour conclure, Git est un outil de gestion de version très efficace permettant de sauvegarder l’historique des modifications des fichiers textes de son projet et de les partager à la demande avec les autres collaborateurs. Sa souplesse, sa simplicité d’utilisation, notamment avec les IDE et sa fiabilité en font certainement un moyen très pratique de sauvegarder ses modifications avec un contrôle complet.

Git s’adapte aux contraintes de son projet et non l’inverse.

Pour aller plus loin :

[Git] Nouvelle version

Une nouvelle version de Git vient de sortir et donc passer en version 1.8.0.

Je vous invite à vous rendre sur le site web Git. Vous trouverez également des informations sur les interfaces graphiques : Git GUI.

Scott Chacon a écrit un livre sur Git que je vous encourage à acheter… mais il est possible de le récupérer sur le site en ePub, mobi ou même en PDF dont voici le lien Livre Pro Git.

Bon Git 😉

Atlassian Stash 1.3

Atlassian a publié la version 1.3 de Stash.

Il s’agit d’un gestionnaire de repository git, en gros d’un github privé.

Ses principaux différenciateurs par rapport à github sont :

  • le fait de disposer d’un gestionnaire de repository interne à l’entreprise. Certaines sociétés acceptent mal d’héberger leur code source sur une machine qui ne leur appartient pas. Dans d’autres cas, les développeurs peuvent ne pas avoir un accès à Internet.
  • l’intégration avec l’annuaire d’entreprise
  • l’intégration avec la suite d’outils Atlassian, et notamment JIRA, Crucible et Bamboo.

Atlassian souligne ainsi l’importance qu’il donne à git.

Pour une présentation rapide de Stash, suivez le guide.

bouton_atlassian_netapsys

Atlassian Stash : Gestion de repository Git d’entreprise

Atlassian propose une solution centralisée pour gérer et exposer des repositories Git via Internet en s’affranchissant des problèmes posés par les firewalls. Cette solution est adaptée aux petites équipes agiles aussi bien qu’aux grosses organisations.

Pour beaucoup d’entreprises, il est difficile d’héberger en interne un système de gestion de configuration tout en autorisant l’accès aux repositories. Atlassian Stash vous permet de vous concentrer sur le développement, en lui délégant la gestion du référentiel.

Conçu pour Git. Dédié à l’entreprise.

Git est en train de devenir progressivement le système de gestion de versions le plus populaire du monde, en permettant aux développeurs de choisir de gérer leurs branches et de travailler en étant isolé du reste du monde, puis en facilitant l’intégration du code dans un projet plus conséquent. La plupart des opérations habituelles (comme les commits) étant réalisées sur le poste local au lieu du réseau, Git accélère le développement par rapport à des systèmes de gestion de version centralisées comme Subversion. Git constitue le choix le plus pertinent, que ce soit pour des projets Open Source ou d’entreprise.

De nombreux services en ligne (incluant Bitbucket d’Atlassian) ont émergé pour aider les utilisateurs de Git à partager et gérer leur code. Les projets Open Source et de nombreuses startups ont bénéficié de ces solutions pour collaborer autour de leurs développements. Adopter Git apporte de nombreux avantages, mais vous oblige aussi à administrer un serveur pour héberger les repositories. Cela peut être particulièrement complexe pour les projets conséquents et les équipes d’entreprise.

  • Les équipes de développement ont besoin de développer rapidement et de partager leur code source à partir d’un point central.
  • Le métier a besoin d’une solution efficace pour organiser les repositories et les sécuriser, sur leurs propres serveurs.
  • Les administrateurs ont besoin d’un système sûr, qui peut s’intégrer dans leur environnement.

Découvrez Stash, le gestionnaire de repositories Git pour les équipes d’entreprise.

Un emplacement centralisé pour vos sources – Une gestion simple des repositories

Git vous permet de créer de nouvelles repositories, de partager le code avec vos équipes, et de le consolider en un projet cohérent. Au fur et à mesure de la croissance de votre projet, de plus en plus de contributeurs et d’intervenants se joignent à votre équipe, de plus en plus de repositories et de branches actives apparaissent. Avec cette activité exponentielle, les équipes produits ont besoin d’une centralisation de leur code, et de le garder organisé tout au long de sa vie.

Stash vous fournit une solution centralisée et sure pour créer et gérer des repositories distribuées, sur vos propres serveurs. Les développeurs sont assurés d’y trouver la version officielle la plus à jour du projet. Les managers peuvent avoir confiance dans le fait que l’accès au code des utilisateurs est adapté à leur rôle, avec une administration minimale.  Laissez Stash devenir la source de confiance de vos sources!

Donnez le pouvoir à vos équipes avec les projets & les permissions

La simplicité est belle : Stash est dédié à la productivité des développeurs et à la promotion de leur workflow habituel. Travailler avec Git peut être incroyablement rapide et productif, mais la gestion des repositories Git et des permissions peut vite devenir compliqué. Stash permet à vos équipes et à vous même de rester productifs en fournissant un modèle de structuration des vos repositories, et en vous permettant de gérer les permissions via une interface utilisateur puissante et simple.

Les projets logiciels impliquent souvent plus d’une repository Git. Stash organise les repositories par projet, simplifiant la recherche et les contributions. Pensez aux projets comme une organisation logique et pratique des repositories.

En utilisant la structure de projets, vous pouvez assigner facilement un ensemble simple de permissions à des utilisateurs et à des groupes, afin de contrôler l’accès aux repositories.

Vos règles, votre environnement

Stashs intègre à votre environnement et ne vous oblige pas à utiliser une appliance pré-configurée sur laquelle vous n’auriez aucun contrôle. Construit sur la même architecture solide aue JIRA et Confluence, Stash se sentira à l’aise sur toutes les plateformes.

Installé sur votre propre réseau, les administrateurs ont un contrôle total sur Stash et son environnement. Avec Stash, vous disposez du framework de plugins d’Atlassian, ainsi qu’une API REST ouverte pour des intégrations personnalisées.

Une gestion d’utilisateurs d’entreprise

Que vous soyez une petite entreprise ou une société du CAC40 ou Fortune 500, la gestion des utilisateurs et des permissions dans Stash est suffisamment flexible pour s’adapter à tous vos cas d’utilisation, vous épargnant une répétition des efforts lorsque vous déployez Stash, ou lorsque vous intégrez de nouveaux collaborateurs.

  • Gérez les utilisateurs dans Stash : les petites équipes peuvent gérer tous leurs utilisateurs et groupes directement dans Stash.
  • JIRA pour la gestion des utilisateurs : utilisez JIRA comme serveur centralisé de gestion des utilisateurs, et gérez tous vos utilisateurs et groupes avec votre environnement JIRA habituel.
  • LDAP d’entreprise : connectez facilement Stash à votre annuaire LDAP – Active Directory, OpenLDAP et davantage – pour gérer vos utilisateurs et vos groupes.
  • Crowd : utilisez Atlassian Crowd comme point central pour toute la gestion de vos utilisateurs, que ce soit pour Stash, JIRA et vos autres applications métier.

Traçabilité des développements

L’élément clé de toute solution de gestion de configuration est sa relation avec les incidents. Connectez Stash à votre gestionnaire d’incidents JIRA pour tirer partie de la traçabilité entre la les incidents et le code source.

Stash garde la trace de tous les incidents associés aux commits. Les utilisateurs peuvent utiliser Stash pour voir rapidement tous les incidents associés à un commit, ou utiliser l’onglet Source des incidents JIRA pour afficher une vue agrégée de tous les changements de code relatifs à un incident particulier. Grâce à cette information, votre équipe de développement gagne du temps lors de l’analyse d’une correction de bug ou du développement d’une évolution.

Navigation rapide dans les sources

Le contrôle de versions distribué est rapide, et de nombreuses équipes ont maintenant le pouvoir de « committer tôt et committer souvent ». Il est donc facile de passer à coté de ce qui se passe quotidiennement sur votre projet. Plutôt qu’afficher les commits sur la ligne de commande, vous pouvez utiliser Stash pour naviguer dans les commits récents, inspecter l’historique d’un fichier, examiner des changesets ou afficher des sources annotées. Cela signifie également que le code source est accessible facilement pas les release managers, les testeurs et les autres membres de l’équipe qui ne travaillent pas avec un IDE.

Essayez Stash aujourd’hui – 25% de remise pendant une durée limitée

Nous sommes très heureux de vous présenter Stash, et nous voulons que tout le monde partage ce plaisir. Pour une durée limitée, Atlassian offre une remise de 25% sur votre nouvelle licence Stash.

Stash – Gestion de Repository Git Repository pour les Projets d’Entreprise. Essayez-le, nous savons que vous allez l’aimer.

Questions & Feedback

Vous avez des questions à propos de Stash? Nous avons les réponses. Visitez la FAQ de Stash, posez des questions sur Atlassian Answers, ou demandez une évolution sur le site JIRA public d’Atlassian.

bouton_atlassian_netapsys