Comment utiliser Git Subtree pour gérer plusieurs référentiels de projets –

Les programmeurs réutilisent souvent le code. En fait, c’est l’un des principes fondamentaux de toute bonne base de code : ne vous répétez pas (DRY). Que faire si vous souhaitez utiliser un projet partagé dans plusieurs autres référentiels ? Les git subtree commande peut aider à gérer cela.

Le problème de la réutilisation du code

L’intégration de projets dans d’autres projets présente un problème ; Le projet 1 et le projet 2 sont tous deux connectés à Git, mais utiliser directement le sous-projet partagé pour les deux n’est pas un bon choix de conception. Il s’agit essentiellement de forger le sous-projet pour l’utiliser à deux endroits, et il sera impossible de maintenir une version officielle du sous-projet.

Il existe quelques solutions à ce problème, chacune avec ses propres inconvénients.

Premièrement, la solution la plus évidente consiste à transformer le sous-projet en package et à le distribuer sur un gestionnaire de packages comme NPM ou NuGet. Cela fonctionne très bien pour les éléments qui ne sont pas mis à jour ou maintenus souvent, et peuvent se permettre d’être distribués à leurs consommateurs dans des numéros de version discrets. Cependant, si vous modifiez ce code régulièrement, devoir intégrer, publier et extraire de nouvelles versions du projet à partir d’une source tierce ne fonctionne tout simplement pas aussi bien que d’avoir le code directement accessible. Elle introduit également des complications pour le développement local.

L’autre solution consiste à utiliser un monorepo, un référentiel géant pour tout votre code. Ce n’est pas aussi fou que vous pourriez le penser, et fonctionne bien si tout votre code est dans le même domaine ; Google utilise un monorepo pour tout son code et Microsoft en utilise un pour tous les assemblys .NET qu’il gère. Cela résout le problème, car si vous modifiez le code dans le sous-projet, il sera mis à jour à chaque reconstruction. Dans Visual Studio, cela peut être fait facilement avec Project References.

Cependant, il existe de nombreux cas où vous voudriez le meilleur des deux mondes – le maintenir de manière centralisée en tant que package, mais également permettre l’intégration et l’édition directes dans plusieurs projets. Pour cela, Git Subtree fournit une solution.

Le concept de base est assez simple : vous pouvez avoir des dépôts Git plus petits, avec leurs

Habituellement, Git est suffisamment intelligent pour gérer automatiquement le transfert et la fusion, en fonction des modifications provenant de quel sous-arbre. C’est une bonne pratique cependant de ne pas mélanger les commits entre le code de la sous-arborescence et le code du projet principal, car il y a des cas où vous pouvez rencontrer une fusion plus compliquée qui vous oblige à utiliser les outils Git sous-jacents qui git subtree enveloppes.

Configuration du sous-arbre Git

Si vous venez de configurer un projet vide et que vous allez configurer des sous-arbres, vous devrez effectuer un commit initial, même s’il est vide, sinon Git renverra une erreur à propos d’un HEAD ambigu. Vous pouvez faire un commit vide avec la commande suivante :

git commit --allow-empty -n -m "Initial commit."

Vous voudrez ajouter la télécommande pour le sous-projet et lui donner un nom. Vous utiliserez ce nom pour vous y référer :

git remote add -f SubTreeName https://github.com/user/project.git

Ensuite, vous pouvez ajouter le sous-arbre, au préfixe donné. Utilisez le --squash afin que tout l’historique du sous-projet ne soit pas stocké dans le projet principal.

git subtree add --prefix .Path/To/SubTree SubTreeName master --squash

Utiliser le sous-arbre Git

Lorsque vous devez extraire, Git ne mettra à jour que le projet principal automatiquement, vous devrez donc récupérer la télécommande, puis utiliser une commande d’extraction spécifique à la sous-arborescence. C’est un peu long, car vous devez passer le préfixe, mais le travail est fait :

git fetch SubTreeName master

git subtree pull --prefix .Path/To/SubTree SubTreeName SubTreeName master --squash

Notez que vous pouvez récupérer des commits à partir de la télécommande, mais les tirer dans la sous-arborescence, ou les pousser vers la télécommande, vous oblige à utiliser git subtree Plus précisément.

Lorsque viendra le temps de contribuer en amont, vous devrez utiliser git subtree push:

git subtree push --prefix=.Path/To/SubTree SubTreeName master