Structure de répertoires
Chaque référence, ou instantané étiqueté d’une validation, dans un projet est organisée dans des sous-répertoires spécifiques, tels que trunk
, branches
et tags
. Par exemple, un projet SVN avec deux fonctionnalités en cours de développement pourrait ressembler à ceci :
sample_project/trunk/README.md
sample_project/trunk/lib/widget.rb
sample_project/branches/new_feature/README.md
sample_project/branches/new_feature/lib/widget.rb
sample_project/branches/another_new_feature/README.md
sample_project/branches/another_new_feature/lib/widget.rb
Un workflow SVN ressemble à ceci :
- Le répertoire
trunk
représente la dernière mise en production stable d’un projet. - Le travail sur une fonctionnalité active est développé dans des sous-répertoires sous
branches
. - Quand une fonctionnalité est terminée, son répertoire est fusionné dans
trunk
et supprimé.
Les projets Git sont également stockés dans un seul répertoire. Toutefois, Git masque les détails de ses références en les stockant dans un répertoire .git spécial. Par exemple, un projet Git avec deux fonctionnalités en cours de développement pourrait ressembler à ceci :
sample_project/.git
sample_project/README.md
sample_project/lib/widget.rb
Un workflow Git ressemble à ceci :
- Un dépôt Git stocke l’historique complet de toutes ses branches et étiquettes dans le répertoire .git.
- La dernière mise en production stable est contenue dans la branche par défaut.
- Le travail sur une fonctionnalité active est développé dans des branches distinctes.
- Quand une fonctionnalité est terminée, sa branche est fusionnée dans la branche par défaut et supprimée.
Contrairement à SVN, avec Git, la structure de répertoire reste la même, mais le contenu des fichiers change en fonction de votre branche.
Inclusion de sous-projets
Un sous-projet est un projet développé et managé quelque part en dehors de votre projet principal. Vous importez généralement un sous-projet pour ajouter des fonctionnalités à votre projet sans avoir à gérer le code vous-même. Chaque fois que le sous-projet est mis à jour, vous pouvez le synchroniser avec votre projet pour vous assurer que tout est à jour.
Dans SVN, un sous-projet est appelé SVN externe. Dans Git, il est appelé sous-module Git. Bien que conceptuellement similaires, les sous-modules Git ne sont pas automatiquement tenus à jour. Vous devez demander explicitement l’introduction d’une nouvelle version dans votre projet.
Pour plus d’informations, consultez « Outils Git - Sous-modules » dans la documentation de Git.
Conservation de l’historique
SVN est configuré pour supposer que l’historique d’un projet ne change jamais. Git vous permet de modifier des validations et modifications antérieures à l’aide d’outils tels que git rebase
.
GitHub prenant en charge les clients Subversion, des résultats inattendus peuvent se produire si vous utilisez à la fois Git et SVN sur le même projet. Si vous avez manipulé l’historique des validations de Git, ces mêmes validations restent toujours dans l’historique de SVN. Si vous avez accidentellement validé des données sensibles, nous avons un article qui vous aidera à les supprimer de l’historique de Git.
**Remarque **: la prise en charge de Subversion sera supprimée avec la version 3.13 de GitHub. Pour plus d'informations, consultez le blog de GitHub.
Pour aller plus loin
- « Création de branches et fusion » dans le livre Git SCM
- « Importation d’un dépôt Subversion »