Je pense que je suis sur la bonne voie pour comprendre les concepts de base de git.
J’ai déjà configuré et cloné un référentiel distant. J’ai également créé un référentiel vide côté serveur et y ai lié mon référentiel local.
Mon problème est que je ne comprends pas la différence entre:
Pour autant que je sache, master est une twig locale et les télécommandes / origine / maître sont distantes.
Mais quelle est exactement l’ origine / maître ?
Prenez un clone d’un repository distant et lancez git branch -a
(pour afficher toutes les twigs connues de git). Cela ressemblera probablement à ceci:
* master remotes/origin/HEAD -> origin/master remotes/origin/master
Ici, master
est une twig dans le référentiel local. remotes/origin/master
est une twig nommée master
sur l’ origin
nommée distante. Vous pouvez vous référer à ceci comme origin/master
, comme dans:
git diff origin/master..master
Vous pouvez aussi vous y référer comme remotes/origin/master
:
git diff remotes/origin/master..master
Ce ne sont que deux manières différentes de faire référence à la même chose (incidemment, ces deux commandes signifient “montrez-moi les changements entre la twig master
distante et ma twig principale).
remotes/origin/HEAD
est la default branch
de l’ origin
nommée à distance. Cela vous permet simplement de dire origin
au lieu d’ origin/master
.
Réponse courte pour les nuls comme moi (volés chez Torek):
Techniquement, il n’y a pas vraiment d’objects “distants” dans votre repository Git, il y a juste des noms locaux qui devraient correspondre aux noms sur un autre repository. Ceux qui s’appellent origin/whatever
vont d’abord correspondre avec ceux de la pension que vous avez clonés:
git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...
fait une copie locale de l’autre repo. Tout au long du chemin, il note toutes les twigs qui se trouvaient là, et les commits se réfèrent à celles-ci, et les insère dans votre repo local sous les noms refs/remotes/origin/
.
Selon le temps que vous passez avant de git fetch
vos git fetch
ou l’équivalent pour mettre à jour “ma copie de ce que sont les fichiers quelque part”, ils peuvent modifier leurs twigs, en créer de nouvelles et en supprimer. Lorsque vous faites votre recherche de git fetch
(ou de git pull
qui est vraiment extraite plus la fusion), votre repository va faire des copies de leur nouveau travail et modifier toutes les entrées refs/remotes/origin/
selon vos besoins. C’est ce moment de la fetch
qui fait que tout concorde (bon, ça, et le clone initial, et quelques cas de push
aussi, essentiellement à chaque fois que Git a une chance de vérifier, mais voyez l’avertissement ci-dessous).
Git fait normalement référence à vos propres refs/heads/
comme
, et les plus éloignés comme origin/
, et tout fonctionne simplement parce qu’il est évident lequel. Il est parfois possible de créer vos propres noms de twig qui ne le rendent pas évident, mais ne vous inquiétez pas avant que cela ne se produise. 🙂 Donne simplement à Git le nom le plus court qui le rend évident, et il partira de là: l’ origin/master
est “là où le maître était là la dernière fois que j’ai coché” faisait”. Exécutez git fetch
pour mettre à jour Git sur “où le maître est là-bas” selon les besoins.
Attention: dans les versions de Git antérieures à la version 1.8.4, git fetch
possède des modes qui ne mettent pas à jour “où master est là-bas” (plus précisément, les modes qui ne mettent à jour aucune twig de suivi à distance). Lancer git fetch origin
, ou git fetch --all
, ou même simplement git fetch
, met à jour. Exécuter git fetch origin master
ne le fait pas . Malheureusement, ce mode “ne se met pas à jour” est déclenché par un git pull
ordinaire. (Il s’agit principalement d’un désagrément mineur et est corrigé dans Git 1.8.4 et versions ultérieures.)
1 Eh bien, il y a une chose qui s’appelle une “télécommande”. Mais c’est aussi local! Le nom d’ origin
est la chose que Git appelle “une télécommande”. C’est simplement un nom court pour l’URL que vous avez utilisé lorsque vous avez fait le clone. C’est aussi d’où vient l’ origin
d’ origin/master
. Le nom d’ origin/master
est appelé une twig de suivi à distance , qui est parfois raccourcie en “twig distante”, en particulier dans une documentation plus ancienne ou plus informelle.
Une précision (et un point qui m’a confondu):
“télécommandes / origine / HEAD est la twig par défaut” n’est pas vraiment correct.
remotes / origin / master était la twig par défaut du référentiel distant (la dernière fois que vous avez coché). HEAD n’est pas une twig, il pointe simplement vers une twig.
Considérez HEAD comme votre zone de travail. Lorsque vous y réfléchissez de cette façon, alors «git checkout branchname» a un sens en ce qui concerne la modification de vos fichiers de zone de travail pour qu’ils soient ceux d’une twig particulière. Vous “vérifiez” les fichiers de twig dans votre zone de travail. HEAD à toutes fins pratiques est ce qui est visible dans votre zone de travail.
$ git remote add origin https://github.com/git/git.git
— Vous allez exécuter cette commande pour lier votre projet github à l’origine. Ici l’origine est définie par l’utilisateur. Vous pouvez le renommer par $ git remote rename old-name new-name
$ git fetch origin
– Télécharge les objects et les références du référentiel distant sur votre ordinateur local [origine / maître]. Cela signifie que cela n’affectera pas votre twig principale locale à moins que vous ne les fusionniez en utilisant l’ $ git merge origin/master
. N’oubliez pas de vérifier la twig correcte où vous devez fusionner avant d’exécuter cette commande
Remarque: le contenu extrait est représenté sous la forme d’une twig distante. Fetch vous permet d’examiner les modifications avant de les intégrer à votre copie du projet. Pour afficher les changements entre le vôtre et le $git diff master..origin/master
Je voudrais essayer de rendre la réponse de @ ErichBSchulz plus simple pour les débutants: