blog ntic de revolunet

Premiers pas Git : team workflow

GIT est un logiciel de gestion de version, crée par Linus Torvalds, qui permet à plusieurs développeurs de travailler ensemble sur les mêmes projets, et de gérer toute l’évolution du code du projet (le workflow) voir même le déploiement et la maintenance des applications.

L’utilisation de GIT peut être assez déroutante au premier abord, notamment pour les habitués à SVN, mais on devient très vite accro à la gestion des branches de GIT , qui permet d’organiser correctement son propre code, celui d’une équipe et de suivre l’évolution du projet. GIT possède son propre vocabulaire, j’espère vous éclairer un peu avec ces premiers pas. Pour tous les détails, consultez les livres online : Pro Git et GIT community Book.

Quelques avantages de git :

• Souplesse dans la gestion des branches
• Décentralisé
• Pas de serveur, un accès SSH suffit
• Un seul dossier .git à la racine du projet
• Le développeur peut créer ses propres branches locales
• Espace disque et transferts réseau très limités

A contrario de SVN, les branches sont stockées dans le même répertoire de travail, et vous switchez de l’une à l’autre grâce la commande ‘git checkout’. cette commande remplace/supprimer et déplace les fichiers à la demande. Pour pouvoir changer de branche, tous les changements doivent être commités.

Dans un cas classique, plusieurs développeurs vont travailler sur le même projet, chacun sur sa branche, et l’un d’eux (le ‘dictator’) sera chargé de réintégrer toutes les modifs dans le ‘master’ (via des ‘merge’). Une fois ces modifs publiées, chaque développeur pourra alors les réintégrer dans son propre code. Ce workflow est un exemple de base, de nombreux cas plus évolués sont possibles.

Si vous avez besoin de centraliser votre repository, vous pouvez utiliser un simple serveur avec accès SSH pour vos users, ou GitHub.com qui offre des repos gratuits pour les projets open source et 12$/mois pour 5 repos privés si besoin. L’avantage de cette dernière solution est sa facilité de mise en oeuvre ainsi que l’accès à l’excellente interface web de GitHub qui permet de consulter le code, les commits, d’avoir des stats, un systeme de wiki, but tracker… De plus, GitHub propose une fonction de Click&Fork qui permet de forker nimporte quel projet en un clic. La mise à jour du code peut ensuite se faire dans les deux sens… ce qui est parfait pour le modèle open source.

Une fois l’installation de git effectuée, récupérez un projet :

pour un projet hébérgé sur un serveur SSH :

pour un projet hébérgé sur GitHub :

Dans les deux cas,  cela crée un dossier KillerApp.git avec le projet et la branche ‘master’ uniquement.

Si vous voulez rappatrier d’autres branches du serveur distant (origin), il faut les ajouter manuellement ;

Ceci crée les branches locales, qui sont ‘linkées’ à leurs branches remotes respectives

On va passer dans la branche ‘juju’

l’étoile indique qu’on travaille dans la branche ‘juju’

Pour créer une nouvelle branche locale ‘newfeature’ depuis la branche actuelle et se déplacer dedans :

Attention, la branche est issue par defaut de la branche en cours, et pas du ‘master’

Pour changer de branche :

Pour repasser dans la branche newfeature :

Une fois dans votre branche de dev, faites des git commit dès que nécessaire. Les fichiers modifies/ajoutes doivent etre ajoutés a l’index GIT via :

ou, pour ajouter automatiquement tous les fichiers :

Il faut savoir que GIT est complètement décentralisé et que les branches locales/remote ne sont pas forcement synchronisées (’trackées’). Dans notre exemple, la branche ‘newfeature’ n’existe qu’en local et ne pourra pas etre ‘pushée’ sur le remote, sauf si on spécifie manuellement un lien vers un repo distant.

Une fois la ‘newfeature’ codée, le développeur doit la réintégrer dans sa branche;  il doit bien sur d’abord commit son code, puis faire un merge :

Il passe d’abord dans sa branche :

Puis merge le code de sa ‘newfeature’

Maintenant, la branche juju contient le code de newfeature et il a été commit automatiquement (en local).

Envoi de notre nouveau code sur le repository distant

Envoyer sur la branche ‘juju’

Il peut envoyer son code sur le remote (cela pushera la branche juju vers la branche remote ‘juju’) :

Un responsable se chargera alors de merger la branche juju dans la branche master et de mettre a jour le master sur le repo central.

Envoyer sur la branche ‘master’ directement

Éventuellement, le développeur peut intégrer ses modifs directement dans la branche ‘master’ :

Il passe sur la branch master :

Il récupère déjà le code du master actuel :

Puis merge sa branche dedans :

Puis envoi sur le remote :

Récupération de code sur le repository distant

Si le developpeur veut réintégrer dans sa branche les mises à jour de ses collègues :

récupérer toutes les branches distantes configurées :

merger le code du master dans la branch actuelle

La branche ‘juju’ est alors mise à jour avec le nouveau code issu de ‘master’ (le trunk)

Quelques commandes utiles :

• Lister les branches sur le repo distant :

• Créer une nouvelle branche ‘daniel’  locale, la créer aussi sur le remote, et la tracker : (double – before ‘track’)

• Sauvegarder en mémoire les modifs depuis le dernier checkout pour les réappliquer dans une autre branche. Attention, ‘git stash’ reset votre branch au dernier commit (HEAD) :

• Créer un nouveau repository local vide : (double – before ‘bare’)

• Express local commit :

• Afficher un diff des modifications

• Afficher un logdes commits

Tips :

• Créez un fichier .gitignore pour ignorer des fichiers/dossiers (ce fichier peut etre different par branche)
• Utilisez ce script dans votre .bashrc pour afficher la branche dans votre prompt
• Consultez stackoverflow.com il y a pleins d’idées intéressantes
• SVN GIT Crach course : http://git.or.cz/course/svn.html
• GIT magic
• Exemple de workflow, avec des graphiques instructifs