Cet article est un billet d'invité de Matt Shelton de Nuance Healthcare. Il s'agit du premier d'une série consacrée à la migration de son équipe de Subversion vers Git, aux raisons qui ont motivé cette migration et aux problèmes rencontrés. Matt a également évoqué ce sujet à l'Atlassian Summit 2015. Cette série développera tous les points qu'il n'a pas pu aborder lors de sa présentation de 30 minutes, avec davantage de contexte.

Nous migrons vers Git et nous adorons Gitflow. Et maintenant ? Nous allons tester tout ça ! Mon équipe est géniale. Elle a dressé une liste de workflows de développeurs dans Confluence sur la base des travaux qu'elle a effectués et de toutes les tâches bizarres que nous pensons devoir faire à l'avenir. Ensuite, nous avons testé tous les workflows dans une structure de projet similaire à la nôtre (mais sans code, seulement un pom.xml).

Les workflows DVCS des entreprises se mettent en place et les modèles se renforcent. Git apporte une telle flexibilité aux équipes qu'au sein d'une seule entreprise, plusieurs équipes peuvent utiliser différentes approches pour partager le code et collaborer.

Il existe des centaines de guides. Mais, seuls certains sont utiles pour garder vos forks à jour par rapport aux dépôts upstream (si vous vous demandez pourquoi utiliser des forks dans une configuration d'entreprise, vous trouverez quelques raisons ici). Dans ce blog, nous vous présenterons quelques façons dont le fork interagit avec les dépôts upstream : les notions fondamentales, les pièges et une astuce utile. Pour couronner le tout, vous serez très jaloux ou très impatient, c'est vous qui déciderez. Intéressé ? Poursuivez votre lecture.

Après la livraison de Git 2.0.0 il y a deux mois et demi, nous avons eu le plaisir de voir arriver une nouvelle version mineure de Git, 2.1.0, avec une foule de nouvelles fonctionnalités intéressantes !

L'intégration de submodules à votre développement Git vous permet d'inclure d'autres projets à votre base de code, tout en conservant des historiques distincts, mais synchronisés avec le vôtre. C'est une méthode pratique pour résoudre les problèmes de dépendance et de bibliothèque de fournisseur. Comme toujours et à tout niveau avec Git, l'approche est très pointilleuse et nécessite un peu d'étude pour être utilisée avec efficacité. Il existe déjà des informations fiables et précises sur les submodules à divers endroits, je ne vais donc pas les répéter. Je vais maintenant partager avec vous certains points utiles qui vous aideront à tirer le meilleur parti de cette fonctionnalité.

La question est simple : pour une équipe de développement qui utilise Git et la création de branche de fonctionnalité, quel est le meilleur moyen d'intégrer le travail fini dans la ligne de développement principale ? Ce débat est sulfureux. Les opinions sont bien tranchées et les conversations sont rarement constructives (pour d'autres exemples de débats sulfureux, voir : Internet).

Aujourd'hui, pour apporter des corrections à un projet, il suffit de faire un fork (le fork est une copie distante complète du projet que vous pouvez hacker), de sélectionner le fichier à modifier, d'appuyer sur Edit, puis de faire des commits de vos corrections.

Posez-vous les questions suivantes. Comment gérer les dépendances de projet avec Git ? Notre projet est composé de plusieurs dépôts interdépendants. Actuellement, ils sont gérés avec svn:externals. Quelle est la meilleure façon de les gérer avec Git ? Comment diviser un dépôt très volumineux en plusieurs petits composants avec Git ? Vous trouverez ci-dessous quelques-unes des questions les plus fréquemment posées lors de la tournée européenne récente Getting Git Right.

De nombreuses équipes ont déjà adopté Git et beaucoup d'autres sont en cours de migration. Outre la formation individuelle des développeurs et la désignation de Champions pour faciliter l'adoption, il est essentiel de choisir une pratique de collaboration autour du code qui ne complique pas trop les choses. Avec Git, vous pouvez traiter des workflows très compliqués, j'en suis témoin.

Avant de rejoindre Atlassian, je travaillais sur divers projets qui faisaient encore appel au système de contrôle de version Subversion (SVN). J'étais déjà passé à Git des années auparavant et je voulais continuer de l'utiliser autant que possible.