Je suis un utilisateur Eclipse/Subversion typique qui commence la migration vers Git. J'ai fait des recherches sur les concepts de base de git et j'ai décidé de m'en tenir à une approche par projet par référentiel au départ pour garder les choses simples. J'ai toujours du mal à décider où placer le référentiel pour chaque projet.
J'ai passé beaucoup de temps à examiner les réponses à cette question , bien que je pense que l'auteur de cette question supposait que vous ne pouvez utiliser Eclipse pour gérer le référentiel que si le référentiel se trouve dans l'espace de travail Eclipse , ce qui n'est bien sûr pas vrai.
La chose qui m'a le plus frappé à propos de cette question, cependant, était le fait que toutes les réponses sauf une (y compris la réponse acceptée) suggéraient de conserver le référentiel à l'intérieur de l'espace de travail Eclipse, alors qu'une seule réponse indiquait que le EGit User Guide recommande l'exact opposé.
Il semblerait cependant qu'en pratique, il existe un certain nombre d'approches mises en œuvre par Eclipse/EGit, dont certaines semblent contredire les recommandations d'EGit.
Par exemple, si vous utilisez le nouveau projet Wizard pour créer un nouveau PHP projet de Git et que le référentiel est distant, Eclipse/EGit se fera un plaisir de créer un projet dans l'espace de travail Eclipse et placez le référentiel (.git) dans le dossier du projet. C'est le résultat final que je veux réellement, car il conserve tout encapsulé dans l'espace de travail Eclipse.
Cependant, si vous utilisez le nouveau projet Wizard et sélectionnez un référentiel Git local, Eclipse/EGit ne clone pas le référentiel comme il le fait pour les référentiels distants. Au lieu de cela, il utilise la copie de travail de ce référentiel en tant qu'emplacement du projet, crée son projet et d'autres éléments de méta à cet emplacement et crée également un nouveau dossier (apparemment inutile) dans cette copie de travail avec le même nom que votre projet (vous vous retrouvez donc avec, par exemple, ~/git/blah/blah
). Si vous supprimez ce dossier superflu, vous vous retrouvez avec une structure identique au premier exemple, la seule différence étant que le dossier de projet n'est pas un sous-dossier de votre dossier d'espace de travail Eclipse, il se trouve ailleurs sur votre système de fichiers (par exemple . ~/git/blah
). La seule chose positive que cette approche semble avoir, c'est qu'elle adhère aux recommandations du guide de l'utilisateur EGit, mais d'un point de vue technique, il est difficile de voir comment cela est vraiment si différent du premier exemple.
Compte tenu de ces observations déroutantes, je me demande quel type d'expériences les gens ont eu en utilisant chacune de ces approches et quels pourraient être les pièges si l'on ignore les recommandations du Guide de l'utilisateur EGit.
Les implications des deux solutions sont répertoriées directement dans le guide de l'utilisateur que vous avez lié. Je peux vous dire que la partie
Cela peut entraîner des problèmes de performances
est malheureusement très vrai. Donc, si vous avez un répertoire git avec un grand nombre de fichiers dans votre espace de travail, de nombreuses opérations git commenceront par une boîte de dialogue "compter les objets ..." qui bloque votre IDE car il scanne tous les fichiers dans l'espace de travail. Pour mes 20000 fichiers actuels, cela signifie attendre 10 à 20 secondes pour chaque commit, chaque switch, ...
Dans les activités de temps libre, où je peux heureusement utiliser l'autre alternative (avoir le répertoire de travail git en dehors de l'espace de travail), tout semble beaucoup plus vif et c'est amusant de fusionner et de basculer.
Donc, si vous optez pour de grands projets, considérez le répertoire git en dehors de l'espace de travail comme premier choix.
Je fais la même migration que l'affiche originale et j'ai trouvé un autre thread où les mêmes doutes sont exprimés sur la recommandation Egit: Dois-je stocker le dépôt git dans Home ou Eclipse Workspace?
@JamesG Voici donc votre mise en page?
~/projectA/workspace/.metadata
~/projectA/workspace/subproj1/.project
~/projectA/workspace/subproj2/.project
~/projectA/subproj1/.git
~/projectA/subproj1/file1
~/projectA/subproj2/.git
~/projectA/subproj1/file2