Envoyé par
Gluups
C'est-à-dire que chez moi j'ai un dépôt local et un dépôt distant dans un autre répertoire. Ce qui permet d'être économe en télécom vers Github.
Les deux sont synchronisés assez régulièrement, et puis là il s'est avéré que ce programme peut intéresser quelqu'un, et que le plus simple pour le partager est de l'enregistrer dans un dépôt sur Github.
D'accord. Donc, si tu synchronises régulièrement avec ton « autre dépôt local » et que tu pousses occasionnellement vers Github pour partager ton travail, il est normal que ton dépôt soit configuré ainsi. Cela dit, à présent que tu as ouvert un dépôt Github, il est inutile de conserver en parallèle un dépôt local sur le même disque. Je te suggère donc d'utiliser ton dépôt Github comme dépôt distant par défaut et de configurer tes branches pour qu'elles le suivent, quitte à utiliser des branches privées si tu ne veux pas tout révéler à chaque fois.
Alors en effet je me rappelle que si un dépôt est créé alors que le développement est déjà bien entamé voire terminé, il faut ajouter les fichiers un par un.
Pas forcément. À tout moment dans le développement d'un projet avec Git, tu peux ajouter plusieurs fichiers à la fois (en indiquant tous les noms sur la ligne de commande) mais également ajouter un répertoire.
Il vaut le coup de rappeler, à ce stade, que Git ne gère pas les répertoires comme entités propres. Il n'enregistre que les fichiers proprement dits, qui ont du contenu (ou sont des fichiers spéciaux comme les liens symboliques) et qui forment les « feuilles » de l'arborescence (les « terminaux »). Les répertoires eux-mêmes font partie du chemin d'accès complet vers le fichier dans l'objet « tree » qui les référence.
C'est notamment pour cela que Git ne peut pas gérer les répertoires vides. A contrario, ça te permet d'ajouter directement un fichier enterré sous un grand nombre de répertoires sans avoir à les ajouter eux-mêmes un par un.
Mais cela signifie également que partout où l'on attend un fichier, passer un répertoire revient en fait à passer l'intégralité de son contenu. Cela implique donc tous les fichiers qui s'y trouvent mais s'il contient en plus des sous-répertoires, alors ils seront ajoutés comme les autres et traités comme expliqué ici, ce qui implique qu'ils seront forcement traités récursivement en profondeur.
Passer le répertoire courant avec git add . a donc pour effet d'ajouter en une fois la totalité du contenu du répertoire courant, que celui-ci se trouve ou non à la racine du dépôt. Par contre, méfiance : cela implique par défaut les fichiers et répertoires cachés (sauf .git, naturellement).
La commande git status te montre tous les fichiers qui ne sont pas encore suivis. Si un répertoire non suivi est vide, il n'apparaîtra pas (car il ne pourra pas être enregistré). Par contre, si un répertoire non suivi contient des fichiers, git status va également te montrer ce répertoire, mais pas ce qu'il contient tant qu'il ne sera pas ajouté.
Pour un dépôt local on utilise "Git add", mais pour le nouveau dépôt distant, si je dois utiliser add je suppose qu'il y a autre chose à mettre avant, pour préciser la cible du add.
Non. « add » ne sert qu'à ajouter des fichiers à la liste des fichiers suivis en local dans un working directory (l'index) et, sous Git en particulier, le dernier contenu en date de ces fichiers de façon à indiquer ce qui doit être enregistré dans le prochain commit. Ce sont ensuite ces commits qui forment le graphe de l'historique et c'est uniquement eux que tu pousses vers les autres dépôts. Les branches et tags, sous Git, ne sont alors que des étiquettes qui pointent vers une révision donnée, laquelle est formée par un commit propre.
Chaque fois que tu veux pousser ou tirer quelque chose d'un endroit ou un autre, que ce soit purement en local ou entre un dépôt local et un dépôt distant, Git s'efforce d'utiliser un comportement implicite ou par défaut chaque fois qu'il le peut. Autrement, il faut utiliser une refspec : https://git-scm.com/book/fr/v2/Les-t...Git-La-refspec
Il s'agit simplement d'une révision en local (donc d'une position dans le graphe) suivie d'une révision distante, les deux séparées par un deux-points « : » et éventuellement précédée d'un « + » pour effectuer la mise à jour même s'il ne s'agit pas d'une avance rapide (« ff »).
La commande exacte dans le problème initial de ce fil aurait donc été :
git push gith master:master
… et c'est en fait exactement celle qu'il a implicitement utilisé. On remarque ici qu'il s'agit bien de master:master et pas de master:gith/master car gith/master et origin/master ne sont en fait que des branches locales qui suivent l'état des branches homologues des autres dépôts et savoir où ils en sont. Avec une refspec, les dépôts sources et destination sont déjà identifiés et on utilise le nom des ressources en vigueur de chaque côté.
Nouveau dépôt, à alimenter
Répondre avec citation
Partager