En tant que développer à 2toLead une de mes tâches récurrentes consiste à définir des bonnes pratiques de gestion du code source en interne ou pour nos clients. Une des questions qui revient souvent est la suivante : Si je veux partir d’une base de code existante et la modifier, devrais-je forker ce repo ou bien faire quelque chose d’autre ?
Il n’est aujourd’hui pas facile de trouver des explications simples et claires sur le web, aussi me suis-je dit que j’aller m’y essayer.
Comme nous utilisons Visual Studio Team Services, mes exemples et captures d’écran seront basés dessus, mais cela s’applique à n’importe quel service git comme Github ou même des serveurs en interne.
Les options dont vous disposez
De mon point de vue, lorsque vous avez un repo existant quelque part, vous disposez des options suivantes pour le déplacer/copier dépendamment de votre scenario :
- Copie manuelle: comme son nom l’indique, prendre les fichiers et les copier autre part, puis exécuter un git init ou quelque chose de similaire pour démarrer sur des bases fraiches. Si cette option semble attirante aux premiers abords, vous le regretterez rapidement en perdant l’historique ainsi que la capacité de rapidement rapatrier des changements vers la source.
- Option d’import: cette option est fournie par VSTS sur les nouveaux repos. Cela importera l’historique et les branches d’un autre repo. Et c’est une bonne solution pour les scénarios de migration simples. Utilisez là si vous comptez supprimer la source ensuite ou bien si la source n’est pas sur le même service (ie : github => VSTS).
- Fork de repo: (depuis la source) c’est probablement la meilleure option si vous prévoyez que la source et la copie coexistent après cette opération. Cela vous permettra de porter vos commits d’un repo à un autre facilement (via des pull requests). Ce choix devrait probablement être votre approche par défaut.
Capture: créer une pull request entre différents repos.
Capture: importer un repo existant
Se sortir d’une situation compromettante
Admettons que vous soyez arrivé(e) sur cet article car la situation est déjà hors de contrôle. Vous avez le « même » ensemble de sources dans plusieurs repos, et cela n’a pas été mis en place de la manière la plus recommandée, comment faire pour réparer ça ?
Avant de commencer laissez-moi vous avertir que cette opération est sujette à erreurs, peut vous faire perdre du travail accompli, va impliquer une « interruption de service » pour vos développeurs (même courte) et est fournie sans aucune garantie. Aussi, avant de commencer, assurez-vous que l’ensemble des modifications en attentes sont commises et poussées, pour chaque développeur.
Vous êtes probablement face à un de ces deux cas :
- Vos différents repos ont un arbre de commits en commun à un certain point (ils ont été forkés ou importés). Git va « comprendre » ce qu’il s’est passé et pouvoir vous aider.
- Vos repos n’ont pas de commits en commun (car il s’agît probablement d’une copie manuelle), vous allez devoir rejouer les changements à la main, bonne chance.
Scenario avec un arbre en commun
Supposons que vous avez la structure suivante :
ProjetA/RepoSource
ProjetB/ReposImporte
Le second étant un import du premier et le premier n’ayant pas subi de mises à jour depuis que le second a été créé. Et désormais vous souhaitez être capable de propager les modifications de ReposImporté vers la source sans avoir à le faire localement.
Commencez par forker le RepoSource vers ProjetB/RepoForke
Clonez le repo forké sur votre machine et exécutez les lignes de commande suivantes.
Assurez-vous de bien remettre en place les « stratégies de branches », définitions de build, release etc. Profitez-en pour exécuter un outil de comparaison branche à branche entre le RepoImporté et le RepoForké.
Pour les autres développeurs de la compagnie, demandez-leur d’exécuter ce srcipt.
Ma demande à l’équipe produit VSTS
Serait-il possible d’avoir la capacité de déplacer les repos git de projet en projet de manière simple ? et que les liens de fork suivent ?
Conclusion
J’espère que cet article aura apporté un peu de clarté sur le sujet et aidé certains d’entre vous à se sortir d’un mauvais pas.