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, maître est une branche locale et télécommandes/Origine/maître est distant.
Mais qu'est-ce exactement que Origin/master?
Prenez un clone d'un référentiel distant et exécutez git branch -a
(pour afficher toutes les branches connues de git). Cela ressemblera probablement à ceci:
* master
remotes/Origin/HEAD -> Origin/master
remotes/Origin/master
Ici, master
est une branche du référentiel local. remotes/Origin/master
est une branche nommée master
sur la télécommande nommée Origin
. Vous pouvez vous y référer soit en tant que Origin/master
, comme dans:
git diff Origin/master..master
Vous pouvez également vous y référer en tant que remotes/Origin/master
:
git diff remotes/Origin/master..master
Ce ne sont que deux façons différentes de se référer à la même chose (incidemment, ces deux commandes signifient "montre-moi les changements entre la branche distante master
et ma branche master
).
remotes/Origin/HEAD
est le default branch
de la télécommande nommée Origin
. Cela vous permet simplement de dire Origin
au lieu de Origin/master
.
Réponse courte pour les nuls comme moi (volés à Torek):
Techniquement, il n'y a pas vraiment de choses "à distance" du tout1 Dans votre repo Git, il n'y a que des noms locaux qui devrait correspondent aux noms d'un autre repo, différent. Ceux nommés Origin/whatever
apparaîtront dans un premier temps avec ceux du référentiel à partir duquel vous avez cloné:
git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...
fait une copie locale de l'autre repo. En cours de route, il note toutes les branches présentes et les commits auxquels il est fait référence, et les colle dans votre dépôt local sous les noms refs/remotes/Origin/
.
Selon le temps que vous passez avant git fetch
ou l’équivalent pour mettre à jour "ma copie de quelqu’un.où.out.there", ils peuvent modifier leurs branches, en créer de nouvelles et en supprimer. Lorsque vous faites votre git fetch
(ou git pull
qui est vraiment chercher plus la fusion), votre référentiel fera des copies de leur nouveau travail et modifiera toutes les entrées refs/remotes/Origin/<name>
selon les besoins. C'est ce moment de fetch
qui fait tout correspondre (enfin, cela, et le clone initial, et quelques cas de Push
aussi - en gros, chaque fois que Git a l'occasion de vérifier - mais voyez l'avertissement ci-dessous).
Normalement, Git vous fait référence à votre propre refs/heads/<name>
comme simplement <name>
, et à ceux qui sont distants comme Origin/<name>
, et tout cela fonctionne, car il est évident de savoir lequel est lequel. Il est parfois possible de créer vos propres noms de branches qui ne rendent pas cela évident, mais ne vous inquiétez pas jusqu'à ce que cela se produise. :-) Donnez simplement à Git le nom le plus court qui le rende évident, et cela ira de là: Origin/master
est "où maître était la dernière fois que j'ai vérifié", et master
est "où maître est ici en fonction de ce que je faisais ". Exécutez git fetch
pour mettre à jour Git "où le maître est là-bas" selon les besoins.
Mise en garde: dans les versions de Git antérieures à la 1.8.4, git fetch
a certains modes qui ne mettent pas à jour "où maître est là-bas" (plus précisément, des modes qui ne mettent à jour aucune branche de suivi à distance). Lancer git fetch Origin
, ou git fetch --all
, ou même simplement git fetch
, fait met à jour. En cours d'exécution git fetch Origin master
non. Malheureusement, ce mode "pas de mise à jour" est déclenché par un git pull
ordinaire. (Ceci est principalement une gêne mineure et est corrigé dans Git 1.8.4 et ultérieur.)
1Eh bien, il y a une chose qui est appelée une "distante". Mais c'est aussi local! Le nom Origin
est ce que Git appelle "une télécommande". En gros, il s’agit d’un nom court pour l’URL que vous avez utilisée lors de la création du clone. C'est aussi d'où la Origin
dans Origin/master
. Le nom Origin/master
est appelé une branche de suivi à distance, qui est parfois abrégée en "branche distante", en particulier dans les documents plus anciens ou plus informels.
J'essaierais de simplifier la réponse de @ ErichBSchulz pour les débutants:
Une précision (et un point qui m'a confondu):
"télécommandes/Origine/HEAD est la branche par défaut" n'est pas vraiment correct.
remotes/Origin/master était la branche par défaut du référentiel distant (la dernière fois que vous avez coché). HEAD n'est pas une branche, il pointe simplement sur une branche.
Pensez à HEAD comme à votre zone de travail. Quand vous pensez de cette façon, alors 'git checkout branchname' prend tout son sens pour changer vos fichiers de zone de travail pour qu'ils soient ceux d'une branche particulière. Vous "récupérez" des fichiers de branche dans votre zone de travail. HEAD à toutes fins pratiques, c'est ce que vous voyez dans votre espace de travail.
$ git remote add Origin https://github.com/git/git.git
--- Vous allez exécuter cette commande pour lier votre projet github à Origin. Ici Origin est défini par l'utilisateur Vous pouvez le renommer par $ git remote rename old-name new-name
$ git fetch Origin
- Télécharge les objets 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 branche maître locale à moins que vous ne les fusionniez avec $ git merge Origin/master
. N'oubliez pas de vérifier la bonne branche où vous devez fusionner avant d'exécuter cette commande
Remarque: le contenu récupéré est représenté comme une branche distante. Fetch vous permet de passer en revue les modifications avant de les intégrer à votre copie du projet. Pour afficher les modifications entre le vôtre et la télécommande $git diff master..Origin/master
Je pense que cette notation git slash est probablement mieux comprise en regardant à l'intérieur de votre dossier .git
.
Par exemple, voici une arborescence quelque peu abrégée de mon .git pour la base source LibreOffice.
Dans linuxSudo apt-get install tree
est utile pour afficher ceci.
Dans Windows Je pense que la commande tree
pourrait encore fonctionner.
Faites défiler la liste et jetez un coup d'œil aux références (références) situées en bas:
$ tree
.
├── branches
├── config
├── description
├── FETCH_HEAD
├── gitk.cache
├── HEAD
├── hooks
│ ├── applypatch-msg.sample
...
├── index
├── info
│ └── exclude
├── logs
│ ├── HEAD
│ └── refs
│ ├── heads
│ │ ├── master
│ │ └── remotes
│ │ └── Origin
│ └── remotes
│ └── Origin
│ ├── distro
│ │ ├── cib
│ │ │ └── libreoffice-6-0
│ │ ├── collabora
│ │ │ └── cp-6.0
│ │ └── lhm
│ │ └── libreoffice-5-2+backports
│ ├── HEAD
│ ├── libreoffice-6-2
│ ├── master
│ └── private
│ └── mst
│ └── sw_redlinehide_4a
├── objects
│ ├── info
│ └── pack
│ ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.idx
│ ├── pack-b80087dc57e2b3315f449ca0f1aaa91987bf0c5e.pack
│ ├── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.idx
│ └── pack-eb4e6808029e712d8d9c2671accbbd98aaeb9a04.pack
├── ORIG_HEAD
├── packed-refs
└── refs
├── heads
│ ├── master
│ └── remotes
│ └── Origin
├── remotes
│ └── Origin
│ ├── distro
│ │ ├── cib
│ │ │ └── libreoffice-6-0
│ │ ├── collabora
│ │ │ └── cp-6.0
│ │ └── lhm
│ │ └── libreoffice-5-2+backports
│ ├── HEAD
│ ├── libreoffice-6-2
│ ├── master
│ └── private
│ └── mst
│ └── sw_redlinehide_4a
└── tags
└── libreoffice-6-2-branch-point
32 directories, 45 files
Cela aurait peut-être été moins déroutant si cela avait été présenté ainsi, mais ce n'était pas le cas:
repositories (i.e. independent trees)
├──local
│ └──master
│
└──Origin1
│ └──master
└──Origin2
└──master
Nous avons trois types de base de références: têtes, télécommandes, et tags.
.git/refs/têtes contient notre maître.
.git/refs/télécommandes peut contenir un certain nombre de télécommandes, même si pour le moment nous n’avons que Origin.
.git/refs/tags (est discuté ailleurs).
Origine est donc notre seule et unique télécommande. Il est valable Origin/master.
Nous constatons que nous avons 2 TÊTES (pointeurs vers les branches actuelles), un local et un distant:
$ cat .git/HEAD # local: HEAD -> master
ref: refs/heads/master
$ cat .git/refs/remotes/Origin/HEAD # remote Origin: HEAD -> master
ref: refs/remotes/Origin/master
Si vous listez vos branches:
$ git branch -a
* master
remotes/Origin/HEAD -> Origin/master
remotes/Origin/aoo/aw080
remotes/Origin/aoo/trunk
remotes/Origin/distro/capgemini/cg-4.1
remotes/Origin/distro/cib/libreoffice-5-0
remotes/Origin/distro/cib/libreoffice-5-1
remotes/Origin/distro/cib/libreoffice-5-2
...
Ensuite, vous pouvez avoir de nombreuses branches de suivi à distance, et nous le faisons ici. Vous savez que ce sont des branches de suivi à distance car elles portent le préfixe ' télécommandes/'. Ceux indiqués ici sont pour la télécommande nommée Origin.
La deuxième ligne est donc le pointeur branche actuelle de Origin. Télécommandes/Origine: HEAD --points to -> master. Cela montre que dans le référentiel distant, la branche actuelle est leur branche nommée maître, (à ne pas confondre avec notre branche locale nommée maître).
Les branches restantes ne se trouvent pas dans votre arbre .git/refs /, mais vous les trouverez plutôt dans .git/packed-refs
.
Lorsque nous (git fetch), nous téléchargeons les modifications du référentiel distant dans notre référentiel de suivi distant.
Lorsque nous (fusion de git), nous fusionnons les modifications de ce référentiel de suivi local et distant dans notre ou nos branches locales actives, dans ce cas dans notre branche principale.
(Lorsque nous git pull nous effectuons ces deux étapes en une seule opération.)
Il est également intéressant de noter que les local et distant les UUID pour maître pointent actuellement sur le même noeud (aka "commit"):
$ cat refs/heads/master # local master
1ca409292272632f443733450313de5a82c54a9c
$ cat refs/remotes/Origin/master # remote Origin master
1ca409292272632f443733450313de5a82c54a9c
Ainsi, notre maître local pointe au même endroit que le maître Origin de la télécommande:
[local] master = [remote] Origin master
Enfin, je pense qu’il est également utile de jeter un coup d’œil sur .git/packed-refs
$ cat packed-refs
# pack-refs with: peeled fully-peeled
3c1d4742e649fe9c8aed8c2817fe3e1f3364f298 refs/remotes/Origin/aoo/aw080
e87c8b7922e9a73e0abb7f9a7a47c9ac3374a826 refs/remotes/Origin/aoo/trunk
b70fdffb041c12f124dcc0822b61bf3450e53137 refs/remotes/Origin/distro/capgemini/cg-4.1
5dbc3f1754809b9489faaf380b1a4bdbcfbb6205 refs/remotes/Origin/distro/cib/libreoffice-5-0
cfdbc96ca47d68d6785fd21829a8d61f49d6e591 refs/remotes/Origin/distro/cib/libreoffice-5-1
5189c8c47461ef09739086e55512fc6a10245273 refs/remotes/Origin/distro/cib/libreoffice-5-2
3bee5917569ca8e6ee3b086458f5b1a917b88ca1 refs/remotes/Origin/distro/cib/libreoffice-5-3
92fbe703f9ca480d3a2b8610d87e991c729edf77 refs/remotes/Origin/distro/cib/libreoffice-5-4
05c0a5df66cc69d75280f05b804cf82f3387d42b refs/remotes/Origin/distro/cib/libreoffice-6-0
7fe193e759b24b90852e6e327115b77114d7b119 refs/remotes/Origin/distro/cib/libreoffice-6-1
8187f7aa413e7ef7b377eea2b057d336bf256867 refs/remotes/Origin/distro/collabora/cd-5.3
7a6b608591e21ef61dc05cff9fc58da531035755 refs/remotes/Origin/distro/collabora/cd-5.3-3.1
....
Nul doute que cela laisse plus de questions que de réponses, mais je pense que cela peut commencer à vous aider à répondre à vos propres questions sur ce qui est quoi.