Premiers pas Git : team workflow

November 24, 2009 on 1:39 pm | In Linux | No Comments

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
pro git example

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 :

# git clone jul@revolunet.com:/var/git/KillerApp.git

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

# git clone git://github.com/julienb/KillerApp.git

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

# git branch
* master

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

# git checkout –track -b juju origin/juju
# git checkout –track -b gary origin/gary

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

On va passer dans la branche ‘juju’

# git checkout juju
# git branch
gary
* juju
master

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 :

# git checkout -b newfeature
# Switched to a new branch “newfeature “

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

Pour changer de branche :

# git checkout juju
# git branch
gary
* juju
master
newfeature

Pour repasser dans la branche newfeature :

# git checkout 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 :

# git add fichier.py fichier2.py

ou, pour ajouter automatiquement tous les fichiers :

# git commit -a 

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 :

# git checkout juju

Puis merge le code de sa ‘newfeature’

# git merge 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’

# git checkout juju

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

# git push

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 :

# git checkout master

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

# git pull

Puis merge sa branche dedans :

# git merge juju

Puis envoi sur le remote :

# git push

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 :

# git checkout juju

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

# git fetch

merger le code du master dans la branch actuelle

# git merge origin/master

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 :
# git branch -r
  • Créer une nouvelle branche ‘daniel’  locale, la créer aussi sur le remote, et la tracker : (double – before ‘track’)
# git push origin origin:refs/heads/daniel
# git fetch origin
# git checkout –track -b daniel origin/daniel

  • 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) :
# git stash # enregistre vos modifs
# git checkout -b newfeature #crée une nouvelle branche
# git stash apply # re-apply les modifs dans la nouvelle branche ‘newfeature’
  • Créer un nouveau repository local vide : (double – before ‘bare’)
# mkdir /pub/my-repo.git
# cd /pub/my-repo.git
# git –bare init
  • Express local commit :
# git commit -a -m “killer feature ready”
  • Afficher un diff des modifications
# git diff –color
  • Afficher un logdes commits
# git log

Tips :

Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds. Valid XHTML and CSS. ^Top^