Discussion :

[CinePhil]

Bonjour,

J'ai beau lire des tutoriels en français ou en anglais, j'ai encore du mal à piger les principes de fonctionnement de Git.

En local, j'ai fait ceci :
1) Création d'un projet PHP dans Eclipse avec une arborescence et quelques fichiers PHP, CSS...
Emplacement : /home/[moi]/[chemin vers mon projet]/[mon_projet]/

2) Création d'un lien symbolique dans /var/www/html pointant vers mon projet
J'accède à mon projet via Apache, no problem.

3) Création avec Egit d'un dépôt Git dans /home/[moi]/[chemin vers mon projet]/[mon_projet]/.git
J'ai pu faire "Equipe / Add to index" et "commit" avec Egit et il s'est créé une arborescence avec des dossiers portant des codes exadécimaux dans .../.git/objects.

Sur le serveur, à partir de ce tutoriel, j'ai fait ceci :
A) Création de l'utilisateur git

B) Création du dépôt dans /home/git/git/[mon_projet].git

C) Configuration SSH du serveur comme expliqué dans le tutoriel pour accéder au dépôt serveur avec ssh git@mon_serveur.

Ensuite, retour dans Eclipse sur ma machine locale et :
4) "Equipe / Push branch master"
Ça a bien envoyé l'arborescence .git de ma machine sur le dépôt git du serveur (avec les dossiers à codes hexadécimaux) mais je ne vois pas les fichiers de programme de mon projet sur le serveur donc un truc m'échappe encore.
Mon collègue, qui devra travailler sur le même projet que moi ne pourra, il me semble, pas importer le projet du serveur vers sa machine pour développer de son côté.

Bref, je nage !
Quelqu'un a une bouée ?

[Marco46]

mais je ne vois pas les fichiers de programme de mon projet sur le serveur donc un truc m'échappe encore.

Comment cherches-tu à accéder à ces fichiers ?

Ces fichiers sont-ils bien commités dans ton projet local ?

Le plus simple reste d'installer une solution web type gitlab sur un serveur, d'y créer un projet, de cloner ce projet en local, de remplir ce projet par tes fichiers, de commit, puis de push. Tout autre utilisateur n'aura alors plus qu'à cloner à son tour depuis le serveur.

[Obsidian]

Bonjour,

Une fois qu'on a compris les deux ou trois grands principes suivis par Git, tout le reste devient clair et même assez séduisant. Plusieurs autres SCM s'appuient sur les mêmes principes et/ou partagent des technologies communes, donc il est difficile de dire ce qui est spécifique à l'un ou commun à tous, surtout quand ils se font la course entre eux, mais quoi qu'il en soit, voici déjà ce qui est valable pour Git :

Bonjour,
J'ai pu faire "Equipe / Add to index" et "commit" avec Egit et il s'est créé une arborescence avec des dossiers portant des codes exadécimaux dans .../.git/objects.

C'est cela qui est très intéressant :

• Git fonctionne par snapshots, comme ceux des systèmes de fichiers. Chaque fois que tu modifies un fichier, ne fût-ce que d'une ligne, il est ré-enregistré dans sa totalité. Ça peut faire bondir dit comme ça mais en réalité, cela n'est que très peu pénalisant. Par exemple, le projet du noyau Linux (pour lequel Git a été initialement développé), qui compte des milliers de contributeurs et autant de commits par mois (1431 commits pour la branche master ces trente derniers jours, 16607 contributeurs depuis le début, entre 1 et 8000 commits par contributeur, 22000 pour Linus) depuis le 16 avril 2005, soit douze ans de développement, ne représente actuellement que 14 Go sur le disque, ce qui est largement à la portée des supports de stockage modernes. Par contre, il comprime systématiquement tous ses enregistrements au format *.gz. Sur de petits fichiers, cela peut représenter une empreinte à peine plus importante que le diff lui-même ;
• Git est distribué et décentralisé : il n'y a pas de « serveur de référence » à proprement parler mais simplement un dépôt local et des dépôts distants que l'on peut atteindre et/ou enrichir. Un peu comme des stations radio-amateur réparties sur le territoire… En ce sens, le dépôt que tu as créé sur le serveur voit ton propre dépôt comme une source distante. Après, certaines branches peuvent être configurées à tout moment pour suivre l'état d'une branche distante où qu'elle soit, et cette configuration est automatique lorsque l'on clone un dépôt ;
• Git fonctionne par objets. Il n'y a que quatre types d'objets : commit, tag, tree et blob. Un blob peut contenir des données de n'importe quelle nature et de longueur arbitraire (définition habituelle d'un blob en informatique), un tree est une arborescence, c'est-à-dire une liste de noms de fichiers ou de répertoires associés à un mode et référençant chacun soit un blob dans le cas d'un fichier (qui définit son contenu), soit un autre tree dans le cas d'un répertoire. Un commit est formé d'un certain nombre d'informations comme le nom de l'auteur, la date, et surtout un tree indiquant tous les fichiers enregistrés lors de l'opération ET une référence au commit précédent, voire AUX commits dans le cas d'une fusion. Un tag contient plusieurs informations comme son nom, une signature numérique éventuelle et une référence à un tree, indiquant les fichiers à taguer ;
• Le nom de chaque objet est en fait sa propre somme SHA1. Ce sont les fameux codes hexadécimaux que tu as aperçus.

Ce dernier point est très important car il a beaucoup de conséquences :

• Un objet est donc immuable de fait : si on modifie son contenu, on change sa somme. Donc, toute modification d'objet se traduit en fait par son remplacement par un autre objet ;
• Ce type d'architecture permet de fait de retrouver facilement et instantanément n'importe quelle révision sans avoir à la résoudre. Même s'il s'agit du commit initial ;
• Il est trivial de comparer deux révisions choisies de façon complètement arbitraire. En fait, même si elles ne font pas partie d'un même projet, l'opération reste la même ;
• Si l'on fait abstraction des collisions éventuelles, dont on fait l'hypothèse qu'elles ne se produiront jamais, l'utilisation d'une somme SHA1 permet de garantir à l'avance que deux objets identiques auront la même somme et que deux objets à la même somme seront forcément identiques, et ce même si les dépôts qui les produisent ne sont pas en communication, ou ne travaillent pas au même moment ;
• Chaque « version » d'un même fichier n'est enregistrée qu'une seule fois (mais plusieurs fois référencée) et ce, là encore, sans avoir à faire de contrôle explicite pour en être sûr. La somme l'impose. Ainsi, un fichier modifié par un commit puis ramené à l'état initial par un autre commit, lors d'un revert par exemple, retrouvera forcément sa somme initiale. C'est intéressant entre autres lorsque les fichiers sont auto-générés ou sont copiés tel quels (copie de la GPL, par exemple). Même chose si tu y reviens par hasard beaucoup plus loin sur ta branche ;
• Le fait d'avoir des objets immuables d'une part et indépendants mais se référençant entre eux (comme le font les dépôts, d'ailleurs) forme de fait un graphe orienté, mais cela rend aussi le dépôt très résilient. Il est possible de l'endommager, mais il est pratiquement impossible de le corrompre. Même en supprimant au hasard un grand nombre d'objets, les morceaux de branches restants restent exploitables.

Enfin, Git utilise un système de garbage collector : lorsqu'un ou plusieurs objets sont « supprimés » parce qu'ils ne sont plus référencés, par exemple quand tu détruis une branche ou quand tu en coupes l'extrémité avec un git reset pour annuler les derniers commits en date, ceux-ci ne sont pas immédiatement retirés du disque mais ils restent simplement en l'état parmi la collection d'objet accumulée. Parallèlement, un GC est lancé soit à intervalles réguliers et à l'initiative de Git, soit à ta propre initiative avec « git gc ». Lorsque cela se produit, un certain nombre d'opérations sont lancées, opérations que tu peux éventuellement lancer individuellement avec leur propre commande, et parmi elles, la suppression des objets obsolètes : pour qu'un objet soit réellement supprimé, il faut par défaut (car cela se configure) que l'objet ne soit plus référencé nulle part, pas même dans les reflogs, et qu'il ait un certain âge, environ 3 mois au minimum.

C'est intéressant parce qu'à partir du moment où un objet est un commit en soi (et que les objets qu'il référence sont toujours là aussi), tu peux faire un git checkout ou un git show dessus, même s'il n'est relié à rien. De fait, il est pratiquement impossible, également, de perdre quelque chose par accident : si une ressource n'est plus référencée, il est toujours possible dans un temps raisonnable de la retrouver soit par sa propre somme SHA1, soit en retrouvant celle-ci dans le reflog, soit en demandant à git de faire le bilan des branches qui pendouillent dans le vide (dangling) ou de faire un git fsck --unreachable ou --lost+found.

Ça a bien envoyé l'arborescence .git de ma machine sur le dépôt git du serveur (avec les dossiers à codes hexadécimaux) mais je ne vois pas les fichiers de programme de mon projet sur le serveur donc un truc m'échappe encore.
Mon collègue, qui devra travailler sur le même projet que moi ne pourra, il me semble, pas importer le projet du serveur vers sa machine pour développer de son côté.

C'est normal : tout le contenu d'un dépôt est enregistré sous forme d'objets à l'intérieur de « .git ». Les fichiers que tu vois à la racine, ceux-là mêmes que tu modifies et que tu ajoutes à chaque fois que tu fais un commit, font partie du « working directory », c'est-à-dire de l'espace de travail. C'est à ce même endroit que vont être réécrits les fichiers d'une autre révision chaque fois que tu fais un checkout. Donc, si personne ne travaille sur le serveur ni ne fait de checkout explicite de ce côté, alors il n'y a pas de raison pour que le working directory change d'état et il restera vide.

Cela n'empêchera pas du tout ton collègue de rapatrier l'état du projet que tu as poussé puisque, là encore, tout se passe en dessous de « .git ». Il ne s'agira que de transférer des objets et configurer des branches.

À noter que, vu comme ça, personne n'est en principe censé travailler sur un serveur d'hébergement. Du coup, le working directory y devient complètement inutile : si le serveur héberge plusieurs projets (ce qui est généralement le cas), on se retrouverait avec un grand nombre de répertoires tous vides en apparence, et ne contenant qu'un répertoire caché « .git » chacun, qui lui contiendrait toute la substantifique moelle du projet hébergé. C'est pour cela que Git propose l'option « --bare » (« nu ») lors d'un « git init ». Quand elle est spécifiée, le dépôt est configuré quasiment de la même façon qu'en temps normal, à ceci près que l'infrastructure est déposée directement dans le répertoire initialisé et plus dans un sous-répertoire « .git », et que le fichier de configuration « config » contient l'option « bare = true ». Quand Git tombe dessus, il sait alors où retrouver ses petits, d'une part, et rejette toutes les demandes de checkout en local.

[CinePhil]

Bonjour Marco,

Comme Eclipse me faisait des misères, je recommence...

Le plus simple reste d'installer une solution web type gitlab sur un serveur, d'y créer un projet, de cloner ce projet en local, de remplir ce projet par tes fichiers, de commit, puis de push. Tout autre utilisateur n'aura alors plus qu'à cloner à son tour depuis le serveur.

J'ai réutilisé ce tutoriel pour configurer mon serveur.

SUR LE SERVEUR de développement :
J'ai, d'une part, le dépôt git vide créé avec les commandes suivantes :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
sudo mkdir /home/git/[mon-projet].git
cd /var/git/[mon-projet].git
sudo git init --bare
sudo chown -R git:git /home/git/[mon-projet].git

Ce qui a donné le dossier /home/git/[mon-projet].git avec son arborescence git :
branches
config
description
HEAD
hooks
info
objects
refs

D'autre part, j'ai le dossier web du projet /srv/www/htdocs/[mon-projet] avec son arborescence de dossiers et quelques fichiers. Le projet est accessible via un navigateur web.

À ce stade, je n'ai pas encore de lien entre le dossier web et le dépôt git sur le serveur.

Le tutoriel dit ensuite de faire ceci SUR MA MACHINE CLIENTE :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

git clone git@mon-serveur.fr:mon-depot.git

Cela m'a créé un dossier [mon-projet] vide et c'est tout, au lieu d'un dossier [mon-projet].git, comme prévu par le tutoriel !

Ensuite, le tutoriel dit de créer un premier fichier (dans le dépôt git local ou c'est possible de le faire ailleurs sur ma machine locale ?) puis de faire ceci pour pousser le projet vers le serveur :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$> git add [le-fichier-créé]
$> git commit -m "Initial commit" [le-fichier-créé]
$> git push origin master

En faisant ça (en ayant créé le fichier dans le dépôt git sinon ça m'insulte), il a été créé sur le serveur, dans l'arborescence du dépôt git, dans le répertoire objects, les répertoires suivants :
1e
47
91

Chacun de ses répertoires contient un fichier de quelques dizaines d'octets portant un nom sous forme de chaîne hexadécimale. Chaque fichier contient lui aussi un texte incompréhensible.

Je ne trouve pas, sur mon serveur, de trace du fichier créé et poussé, en clair, exploitable et accessible via un navigateur web.

Bref, je suis toujours paumé !

Ce que je souhaite, c'est récupérer mon projet, situé sur le serveur, sur ma machine locale, via git, afin que moi et mon collègue puissions travailler ensemble sur le projet situé sur le serveur de développement, y pousser nos ajouts et modifications depuis notre machine locale en ayant la possibilité de revenir en arrière en cas de problème. Je ne vois toujours pas comment faire ça.

[Mickael_Istria]

Je pense qu'il est important que tu comprennes que les repos "clients" dans lesquels on manipule le code ne sont pas orgnaises pareil que les repos "serveur". Les dossiers <projets>.git correspondent souvent aux serveurs, qui ne sont pas ceux qui tu manipules depuis un IDE. Le serveur n'est PAS un miroir du client, c'est un "service" avec lequel on interagit via Git.
Le repo serveur n'est pas specialement navigable via filesystem en l'etat. On utilise generalement un front-end web type cGit, Gerrit+Gitiles, GitLab, GitHub... pour le naviguer. Ces couches de presentations savent lire le format du repo "serveur/bare".

Cela m'a créé un dossier [mon-projet] vide et c'est tout, au lieu d'un dossier [mon-projet].git, comme prévu par le tutoriel !

Le tutoriel n'est pas bon. Si tu veux le dossier project.git (qui n'est pas le code du projet), tu dois passer l'option "--bare" lors du git clone. Ca te fait un clone du repo "serveur". Mais dans ton cas, je ne pense pas que ce soit ce que tu cherches a avoir.
Un simple `git clone` te cree plutot un repo "client" (dont tu peux naviguer le code). Ensuite, depuis le repo client, tu peux envoyer tes commits au serveur avec `git push`.

Ce que je souhaite, c'est récupérer mon projet, situé sur le serveur, sur ma machine locale, via git, afin que moi et mon collègue puissions travailler ensemble sur le projet situé sur le serveur de développement, y pousser nos ajouts et modifications depuis notre machine locale en ayant la possibilité de revenir en arrière en cas de problème. Je ne vois toujours pas comment faire ça

Depuis le repo "client" sur ta machine de dev local, tu fais juste `git clone` pour creer le repo, et ensuite `git pull` pour recuperer les derniers commits. Il y a plein d'options possibles que tu decouvriras pas la suite.

PS: tes question n'ont strictement rien a voir avec Eclipse IDE. Toutes les integrations Git dans les IDE pre-supposent que tu as une comprehension de Git minimale pour pouvoir l'utiliser.
PPS: dans ton cas, je te suggere de dissocier ton probleme en 2 parties pour progresser plus vite dans ta formation: Git client et Git hebergement. Pour le 1er, tu crees un repo de test sur GitHub et tu vois comment interagir avec lui cote client (creer un commit, le "push"er sur le repo Git, et le recuperer depuis une autre machine); ensuite, quand tu te sens plus a l'aise avec ca, tu peux passer a l'hebergement, et comme recommande plus haut, peut-etre prendre la direction de services tout prets (Gerrit, GitLab...) plutot que de tout faire a la main.

[CinePhil]

Depuis le repo "client" sur ta machine de dev local, tu fais juste `git clone` pour creer le repo, et ensuite `git pull` pour recuperer les derniers commits.

Il faudrait donc que j'établisse déjà un lien entre mon dossier projet sur le serveur dans /srv/www/htdocs et mon dépôt git sur le serveur dans /home/git/[mon-projet].git, non ?

Je fais ça comment ?

tes question n'ont strictement rien a voir avec Eclipse IDE

Ces dernières questions oui. D'ailleurs, mon message montre que je n'ai pas encore utilisé Eclipse pour ce recommencement.

Après avoir réinstallé Eclipse PHP, il me propose ces options :
- "Import existing PHP Project" qui semble être simplement la création d'un projet PHP dans Eclipse se référant à un répertoire de ma machine contenant déjà un projet ;
- "Checkout projects from Git" qui me demande de sélectionner une Repository Source (laquelle ? locale ou serveur ?).

[Mickael_Istria]

Il faudrait donc que j'établisse déjà un lien entre mon dossier projet sur le serveur dans /srv/www/htdocs et mon dépôt git sur le serveur dans /home/git/[mon-projet].git, non ?

En fait, je pense qu'avant, tu faisais des SCP ou des CVS/SVN pour deployer en remote et ca allait. Avec Git -comme le repo serveur n'est pas utilisable-, il te faut une etape de deploiement en plus.
Il faudrait qu'a chaque fois que tu pushes un commit sur le serveur, tu mettes a jour le contenu de /src/www/htdocs. Pour ce faire, tu peux mettre cote server un hook qui lancera automatiquement une action pour deployer ton code dans le dossier qui va bien. Un truc du genre `pushd /src/www/htdocs && git clone file:/home/git/projet.git && git pull && popd`.

[CinePhil]

Je pense avoir trouvé la solution...

1) Initialisation du dépôt Git
cd /srv/www/htdocs/monprojet
git init

=> Le dépôt Git est dans /srv/www/htdocs/monprojet/.git

2) Ajout des répertoires du projet au dépôt Git
git add application
git add public

3) Création de la version initiale
git commit -m 'Version 0.1 - Initiale'

=> Résultat :
4 files changed, 163 insertions(+)
create mode 100644 application/conf/constantes.php
create mode 100644 public/css/general.css
create mode 100644 public/img/ENSFEA.png
create mode 100644 public/index.php

4) Récupération du projet sur mon poste local
a) Dans Eclipse, sur la page d'accueil, utiliser l'option "Checkout projects from Git".
b) Dans la fenêtre "Select repository source", choisir "Clone URI", puis cliquer sur "Next".
c) Dans la fenêtre "Source Git repository" :
- Host : [IP du serveur de dev] => cela modifie en conséquence l'URI ;
- Repository path : /srv/www/htdocs/monprojet => cela modifie en conséquence l'URI ;
- Protocol : ssh => cela modifie en conséquence l'URI ;
- Authentication : git => cela modifie l'URI en conséquence ;
- Password : rien ! => on utilise la clé publique du user git sur le serveur et qui a été importée sur le poste local.

d) La fenêtre "Branch Selection" affiche la branche "master" qui est précochée.
Cliquer sur Next.

e) Dans la fenêtre "Local Destination" :
- Directory : /chemin/ver/mon/projet/monprojet
- Cliquer sur Next.

f) Dans la fenêtre "Select a wizard to use for importing projects", choisir "Import using the New Project wizard", puis cliquer sur "Finish".

g) Dans la fenêtre "Select a wizard", sélectionner "PHP Project" et cliquer sur "Next"

h) Dans la fenêtre "Create a PHP Project" :
- Name : pef ;
- Choisir l'option "Create project at existing location..." ;
- Directory : /chemin/ver/mon/projet/monprojet ;
- Cliquer sur "Next"

i) Dans la fenêtre "PHP Include Path", cliquer sur "Next".

j) Dans la fenêtre "PHP Build Path", cliquer sur "Finish".

=> Le projet "monprojet [monprojet master]" apparaît et l'arborescence des fichiers du projet du serveur a bien été importée.
Petit bémol cependant : seul les sous répertoires contenant des fichiers ont été importés. J'avais créé toute une arborescence MVC sur le serveur qui n'a pas été importée, faute de fichiers dans la plupart des répertoires.
Je recréerai demain l'arborescence sur Eclipse et je tenterai d'exporter ça vers le serveur. On verra comment ça se passera. À suivre...

[Rikky]

Je pense avoir trouvé la solution...

[…]

Je recréerai demain l'arborescence sur Eclipse et je tenterai d'exporter ça vers le serveur. On verra comment ça se passera. À suivre...

Bonsoir,

Je suis intéressé par l'issue de votre tentative.

Je chercher à pusher un dépôt GITBLIT vers un serveurs apache et je constaté que les fichiers qui m'intéressent portent des noms différents entre le dépôt GIT et le poste de travail / le serveur vers lequel je veux les envoyer.

Bien à vous