Discussion :

[foxbille]

Bonjour,
Est-ce qu'il est possible d'utiliser GIT uniquement en local.
Le dépot serait par exemple sur /home/$USER/git/projet1
Travaillant dans /var/www/public/projet1, le clone marche
par contre la commande git add . suivie de git commit -m "bla bla bla" n'opère que sur ce qui est dans /var/ et rien n'est remonté dans le "dépot".
Est-ce qu'il y a moyen de faire ça ?
cordialement,
Eric

[Obsidian]

Bonjour,

Bonjour,
Est-ce qu'il est possible d'utiliser GIT uniquement en local.

Absolument. Il n'est d'ailleurs pas impossible que cela soit devenu son usage le plus fréquent aujourd'hui, mais ça mériterait d'être dûment mesuré.

Le dépot serait par exemple sur /home/$USER/git/projet1

Tu n'es pas obligé de partir directement d'un projet existant pour travailler avec Git. Tu peux initialiser n'importe quel dépôt Git à partir d'un répertoire vide ou recelant déjà des fichiers avec git init.

Travaillant dans /var/www/public/projet1, le clone marche
par contre la commande git add . suivie de git commit -m "bla bla bla" ne met que ce qui est dans /var/ et rien dans le "dépot".

Peux-tu détailler ce dernier point, qui n'est pas tout-à-fait clair ?

— D'où vient /var/www/public/projet1 ? Est-ce un répertoire réseau ou s'agit d'un dépôt poussé en ligne pour le publier ? (ça se fait souvent, mais ce n'est pas toujours une bonne idée).
— Est-ce que tu veux travailler sur un projet web en particulier ?
— Comment et à quel endroit as-tu cloné un projet existant, le cas échéant ?

[foxbille]

Bonjour,
Merci pour ta réponse

Peux-tu détailler ce dernier point, qui n'est pas tout-à-fait clair ?
— D'où vient /var/www/public/projet1 ? Est-ce un répertoire réseau ou s'agit d'un dépôt poussé en ligne pour le publier ? (ça se fait souvent, mais ce n'est pas toujours une bonne idée).

Je ne peux pas partir d'un dépot vide car le projet existe.
J'ai cloné le projet /home/$USER/git/projet1
dans /var/www/public/projet1
J'ai fait des modifs, je veux les remonter dans le dépot, puis travailler sur un autre projet.
J'ai fait git add . puis git commit ...
J'ai aussi essayé un peu au pif

Code :

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

1
2
3
4
git push
git push origin
git push origin master

en récoltant chaque fois une erreur

Code :

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

1
2
3
4
5
6
7
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: Par défaut, mettre à jour la branche actuelle dans un dépôt non-nu
...
To /home/$USER/git/projet1/.git
 ! [remote rejected] master -> master (branch is currently checked out)
erreur*: impossible de pousser des références vers '/home/$user/git/projet1/.git'

[Obsidian]

D'accord,

Je ne peux pas partir d'un dépot vide car le projet existe.
J'ai cloné le projet /home/$USER/git/projet1
dans /var/www/public/projet1

Donc je suppose que /home/$USER est le répertoire personnel d'un tiers, que ce projet concerne un site web, que tu l'as cloné dans /var/www/public/projet1 pour pouvoir le faire fonctionner en local chez toi à l'aide d'un serveur Apache ou nginx et que par conséquent, tu le modifies directement in situ. Peux-tu me confirmer que tout ceci est bien exact ?

Si ça l'est, dans la mesure du possible (certains serveurs et certaines distributions commencent à y mettre des entraves), il vaut mieux créer toi-même un répertoire « git » dans ton home, y cloner tous les projets qui t'intéresse et, le cas échéant, configurer un dépôt dans /var/www sous forme de lien symbolique vers le dépôt Git.

J'ai fait des modifs, je veux les remonter dans le dépot, puis travailler sur un autre projet.
J'ai fait git add . puis git commit ...

Tant que tu restes en local, git add et git commit suffisent.

Si tu veux partager ton travail et surtout le faire remonter ensuite vers le dépôt original, il faut utiliser git push et git pull (ainsi que les commandes sous-jacentes git fetch, git merge et git remote <commande> pour gérer les dépôts distants). Mais ce n'est pas si simple :

— Il faut déjà avoir les droits en écriture sur le dépôt distant, que ce soit par le réseau ou directement via le système de fichiers (dans ton cas). Et il est fort peu problable que tu aies le droit d'écrire par défaut dans le répertoire /home de ton collègue. Il faut prendre contact avec lui pour que soit il te les accorde directement (rapide mais hasardeux), soit il publie lui-même sur un serveur partagé le projet en question. Et il est probable qu'il le soit déjà. Dans ce cas, c'est lui qu'il aurait fallu cloner en premier lieu ;

— Il va falloir que tu apprennes également à utiliser les branches.

J'ai aussi essayé un peu au pif

Code :

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

1
2
3
4
git push
git push origin
git push origin master

en récoltant chaque fois une erreur

Code :

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

1
2
3
4
5
6
7
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: Par défaut, mettre à jour la branche actuelle dans un dépôt non-nu
...
To /home/$USER/git/projet1/.git
 ! [remote rejected] master -> master (branch is currently checked out)
erreur*: impossible de pousser des références vers '/home/$user/git/projet1/.git'

Ce qu'il se passe ici est que le dépôt original contient une branche par défaut : master. C'est la branche que Git crée lors d'un git init. Par la suite, cette branche devient une branche ordinaire comme les autres. On peut en théorie la renommer et/ou la supprimer, mais on ne le fait pour ainsi dire jamais en pratique. Quelqu'un qui se contente d'ajouter incrémentalement son travail le fait en fait implicitement au sommet de cette branche.

Toi, tu as cloné le projet. Git a donc créé en local une copie de ce dépôt avec tout son historique, mais ce dépôt t'es propre et il vit désormais sa propre vie « indépendamment » de sa source, comme si tu l'avais créé initialement avec git init.

Ce dépôt est toutefois informé de l'existence d'un autre dépôt, celui-là même dont il provient. Par défaut, git baptise ce dépôt distant « origin » mais là encore, tu peux le renommer et/ou le supprimer, et tu peux surtout ajouter d'autres dépôts distants autour de lui s'il y a lieu. C'est important parce que cela signifie qui n'y a pas de relation hiérarchique entre les dépôts Git a priori. Ils sont vus comme un ensemble de « villes » ou de « stations » indépendantes sur un même territoire, chacune ayant conscience ou non de l'existence de ses voisines.

À noter que le dépôt cloné a automatiquement conscience de sa source mais que l'inverse n'est pas vraie : cloner un dépôt ne va pas automatiquement mettre à jour la liste des dépôts distants du site original, et heureusement.

La deuxième conséquence de tout cela est que tu obtiens, automatiquement là aussi, une copie de toutes les branches qui ont été déclarées, ne serait-ce que pour y placer l'historique. Celles-ci sont a priori des références « remotes » mais qui peuvent donner naissance à leur homologue local, alors positionné au même endroit dans le graphe des révisions. Enfin, chose importante : chaque branche peut être paramétrée ou non pour « suivre » une autre branche, locale ou distante, depuis laquelle on tirera du contenu avec pull ou vers laquelle on poussera celui qui a été ajouté en local si on n'en précise pas explicitement la destination.

Là encore, c'est automatique avec git clone. Ta branche locale master est paramétrée par défaut pour suivre origin/master.

Les raisons, à présent, pour lesquelles push échoue sont les suivantes :

• Tu n'as toujours pas les droits en écriture vers le dépôt distant mais ça, git ne le sait même pas encore (l'échec se produit avant) ;
• Comme ton collègue travaille sur sa propre branche master (celle qui est référencée par origin/master de ton côté), elle est actuellement déployée dans son répertoire de travail (implicitement ou avec git checkout). Elle ne peut donc pas être mise à jour parce qu'il faudrait également mettre à jour les fichiers qui y sont actuellement déployés, de la même façon qu'une personne tierce ne pourrait pas, depuis son poste, mettre à jour la branche master de ton dépôt local cloné parce que tu travailles toi-même dessus.

Pour que ce soit possible, outre les droits d'accès, il faudrait soit que ton collègue fasse temporairement un git checkout vers une autre branche pour te permettre d'y pousser tes modifications avant d'y revenir, soit que toi et ton collègue travailliez tous les deux sur un troisième dépôt commun qui servirait de serveur officiel, soit encore — et c'est là la solution à préférer — que tu travailles sur ta propre branche, que tu pousses cette branche (et non master) vers le serveur distant et que tu formules une « pull request » à ton collègue pour lui demander de l'intégrer lui-même à master.

Pour l'heure, je te suggère de faire les choses en deux temps. Commence déjà par te familiariser avec Git en local puis fais avancer le travail de ton côté. Lorsque tu seras à l'aise, on reprendra le dépôt en l'état pour voir quelle serait la meilleure approche pour pousser tes changements.

Conseil supplémentaire : si tu travailles sous Linux, utilise un outil tel que tig pour disposer d'une vue un peu plus claire de l'historique et te permettre de le parcourir facilement.

[foxbille]

Pour l'heure, je te suggère de faire les choses en deux temps. Commence déjà par te familiariser avec Git en local puis fais avancer le travail de ton côté. Lorsque tu seras à l'aise, on reprendra le dépôt en l'état pour voir quelle serait la meilleure approche pour pousser tes changements.

Merci pour ta réponse très claire. Je vais reprendre tout ça calmement.
Juste quelques précisions : on est dans le cadre d'un hobby, pas d'une activité professionnelle. Il n'y a que ma machine et pas d'autre développeur que moi. Le but de l'utilisation de GIT, c'est de me permettre d'avoir une gestion simple et sans pièges des versions de mes applis. La version stable et actuellement en ligne est stockée dans le dépot, Je veux pouvoir travailler à des améliorations sur une branche et pouvoir rapidement réparer des bugs apparus sur la version stable sans me mélanger les crayons par la suite. Je ne sais pas si je suis assez clair...
Bref, je vois plus clair dans le fonctionnement général de GIT et je t'en remercie.
Eric

[Obsidian]

Juste quelques précisions : on est dans le cadre d'un hobby, pas d'une activité professionnelle.

Raison de plus pour ne pas se précipiter. :-)

Git a l'air cryptique de prime abord mais quand on y regarde bien, on comprend qu'il s'appuie sur trois ou quatre concepts très simple et extrêmement bien pensés, à tel point qu'il est difficile d'avoir meilleur modèle. Donc ça vaut le coup de prendre le temps de les assimiler correctement, car tout le reste vient naturellement ensuite.

Il n'y a que ma machine et pas d'autre développeur que moi. Le but de l'utilisation de GIT, c'est de me permettre d'avoir une gestion simple et sans pièges des versions de mes applis. La version stable et actuellement en ligne est stockée dans le dépot, Je veux pouvoir travailler à des améliorations sur une branche et pouvoir rapidement réparer des bugs apparus sur la version stable sans me mélanger les crayons par la suite. Je ne sais pas si je suis assez clair...

Si, si, et c'est même là l'usage principal de tout logiciel de versioning, avant même le partage entre collaborateurs.

Le plus simple pour faire ce que tu veux faire est de travailler sur une seule branche (master, en principe), d'y ajouter régulièrement son travail et de poser un tag sur une révision considérée stable, avant de continuer à faire évoluer la branche avec la suite du développement. Tu peux donc tout-à-fait faire évoluer le site de cette façon tant que tu restes tout seul dessus.

Le problème commence à se poser lorsque tu veux ajouter ton travail à un dépôt existant et, donc, l'intégrer à l'existant. Et ce problème se pose avec tous les logiciels de versioning : que se passe-t-il si vous êtes deux à travailler simultanément sur les mêmes parties d'un même fichier mais chacun de votre côté, et que vous essayez d'envoyer tous les deux votre travail vers le serveur ou le dépôt de référence ? Un « conflit » va apparaître et il faudra alors procéder à une fusion de l'état de vos branches respectives et à une résolution de ces conflits si les modifications ne peuvent cohabiter. C'est très fréquent (c'est même le quotidien des développeurs qui travaillent à plus de deux sur le même sous-ensemble d'un projet) mais il faut apprendre à le faire.