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 clair de l'historique et te permettre de le parcourir facilement.