Juan Rumpel
Creo que estoy en el camino correcto para comprender los conceptos básicos de git.
Ya configuré y cloné un repositorio remoto. También creé un repositorio vacío del lado del servidor y lo vinculé con mi repositorio local.
Mi problema es que no entiendo la diferencia entre:
Por lo que tengo entendido, Maestro es una sucursal local, y remotos/origen/maestro es uno remoto.
Pero que es exactamente origen/maestro?
Tome un clon de un repositorio remoto y ejecute git branch -a (para mostrar todas las ramas que conoce git). Probablemente se verá algo como esto:
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Aquí, master es una rama en el repositorio local. remotes/origin/master es una rama llamada master en el control remoto llamado origin. Puedes referirte a esto como origin/mastercomo en:
git diff origin/master..master
También puede referirse a él como remotes/origin/master:
git diff remotes/origin/master..master
Estas son solo dos formas diferentes de referirse a lo mismo (por cierto, ambos comandos significan “muéstrame los cambios entre el control remoto master rama y mi master rama).
remotes/origin/HEAD es el default branch para el control remoto llamado origin. Esto le permite simplemente decir origin en lugar de origin/master.
Buena respuesta. creo git branch -a mostrando la rama remota como remotes/origin/master es en parte porque la referencia subyacente está almacenada en .git/refs/remotes/origin (si no ha sido embalado). En mi opinión, la salida de git branch -a podría ser mucho más claro, tal vez separando el nombre del control remoto del nombre de la sucursal con algo que no sea una barra oblicua.
– Mate
14 mayo 2012 a las 18:13
También tenga en cuenta que git branch -rque es para mostrar solo sucursales remotas, mostrará la sucursal como origin/master porque el remotes/ el prefijo no es necesario.
– Mate
14 mayo 2012 a las 19:26
@misterbiscuit: eso es cierto. El resultado es más confuso que clarificador. Muchas gracias, una gran respuesta a mi pregunta que me dio las pistas correctas.
– John Rumpel
17 mayo 2012 a las 11:44
si miro git log veo commit fa9sd8jasdf98 (HEAD -> master), ¿Qué quiere decir esto? ¿Qué es HEAD en este caso? Pensé que actualmente era “maestro” y me estaba comprometiendo a origin/master. Creo que me confundí algo, ¿alguien podría ayudar a calmar? ACTUALIZACIÓN DE EDICIÓN: creo que lo entendí, ¿es correcto suponer que HEAD actualmente apunta a la rama maestra, lo que significa que actualmente estoy en el proceso de comprometerme con la maestra?
– Sebastián Nielsen
27 de julio de 2018 a las 11:54
Sin embargo, estoy un poco confundido con esta respuesta. ¿Remotes/origin/master no es diferente de origin/master si alguien cambió la rama del maestro remoto y aún no la hemos obtenido?
– iRestMyCaseYourHonor
23 de marzo de 2020 a las 22:57
Respuesta corta para tontos como yo (robada de Torek):
origin/master = copia de seguridad de la máquina remota, actualizada la última vez que verificó master = su copia de origin/master
– sakura shinken
17 de marzo de 2016 a las 0:27
Torek
Técnicamente, en realidad no hay nada “remoto” en absoluto.1 en su repositorio de Git, solo hay nombres locales que deberían corresponden a los nombres en otro repositorio diferente. los nombrados origin/whatever inicialmente coincidirá con los del repositorio desde el que clonó:
git clone ssh://some.where.out.there/some/path/to/repo # or git://some.where...
hace una copia local del otro repositorio. En el camino, anota todas las ramas que estaban allí, y los compromisos a los que se refieren, y los pega en su repositorio local con los nombres refs/remotes/origin/.
Dependiendo de cuánto tiempo pase antes de que usted git fetch o equivalente a actualizar “mi copia de lo que está en algún lugar”, pueden cambiar sus ramas, crear otras nuevas y eliminar algunas. cuando haces tu git fetch (o git pull que es realmente buscar más fusionar), su repositorio hará copias de su nuevo trabajo y cambiará todos los refs/remotes/origin/<name> entradas según sea necesario. es ese momento de fetchque hace que todo coincida (bueno, eso, y el clon inicial, y algunos casos de pushing también, básicamente cada vez que Git tiene la oportunidad de verificar, pero vea la advertencia a continuación).
Git normalmente te hace referirte a tu propio refs/heads/<name> tan solo <name>y los remotos como origin/<name>, y todo funciona porque es obvio cuál es cuál. A veces es posible crear sus propios nombres de rama para que no sea obvio, pero no se preocupe por eso hasta que suceda. 🙂 Solo dale a Git el nombre más corto que lo haga obvio, y comenzará desde allí: origin/master es “dónde estaba el maestro allí la última vez que revisé”, y master es “dónde está el maestro aquí basado en lo que he estado haciendo”. Correr git fetch para actualizar Git en “donde está el maestro allí” según sea necesario.
Advertencia: en versiones de Git anteriores a 1.8.4, git fetch tiene algunos modos que no actualizan “donde está el maestro allí” (más precisamente, modos que no actualizan ninguna rama de seguimiento remoto). Corriendo git fetch origino git fetch --allo incluso simplemente git fetch, lo hace actualizar. Corriendo git fetch origin master no. Desafortunadamente, este modo “no se actualiza” se activa por git pull. (Esto es principalmente una molestia menor y se solucionó en Git 1.8.4 y versiones posteriores).
1Bueno, hay una cosa que es llamado un mando a distancia”. ¡Pero eso también es local! El nombre origin es lo que Git llama “un control remoto”. Básicamente es solo un nombre corto para la URL que usó cuando hizo la clonación. También es donde el origin en origin/master viene de. El nombre origin/master se llama un rama de seguimiento remotoque a veces se abrevia como “rama remota”, especialmente en documentación más antigua o más informal.
Excelente descripción para un novato como yo, ¡gracias! Aclaró por qué puso el origin/master pegatina en el local gráfico de repo, y no en el remote uno (recomiendo de todo corazón la presentación “Git Happens” de Jessica Kerr para las personas nuevas en git: vimeo.com/46010208. Me estaba rascando la cabeza entre las 30:00 y las 30:19).
– anciano anciano
17 de noviembre de 2016 a las 17:04
MKJ
Intentaría simplificar la respuesta de @ErichBSchulz para principiantes:
$ git remote add origin https://github.com/git/git.git — Ejecutará este comando para vincular su proyecto github al origen. Aquí el origen es usuario definido.
Puedes renombrarlo por $ git remote rename old-name new-name
$ git fetch origin – Descarga objetos y referencias desde un repositorio remoto a su computadora local [origin/master]. Eso significa que no afectará su rama maestra local a menos que los fusione usando $ git merge origin/master. Recuerde verificar la rama correcta donde necesita fusionarse antes de ejecutar este comando
Nota: el contenido obtenido se representa como una rama remota. Fetch le brinda la oportunidad de revisar los cambios antes de integrarlos en su copia del proyecto. Para mostrar los cambios entre el tuyo y el remoto $git diff master..origin/master
almiar
Una aclaración (y un punto que me confundió):
“remotes/origin/HEAD es la rama predeterminada” no es realmente correcto.
remotes/origin/master era la rama predeterminada en el repositorio remoto (la última vez que lo comprobó). HEAD no es una rama, solo apunta a una rama.
Piensa en HEAD como tu área de trabajo. Cuando lo piensa de esta manera, ‘git checkout branchname’ tiene sentido con respecto a cambiar los archivos de su área de trabajo para que sean los de una rama en particular. Usted “desprotege” los archivos de rama en su área de trabajo. HEAD a todos los efectos prácticos es lo que es visible para usted en su área de trabajo.
Creo que esta notación de git slash probablemente se entienda mejor mirando dentro de tu .git carpeta.
Por ejemplo, aquí hay un árbol algo abreviado de mi .git para la base fuente de LibreOffice.
En linux sudo apt-get install tree es útil para ver esto.
En ventanas Pienso que el tree el comando aún podría funcionar.
Desplácese hacia abajo y eche un vistazo a las referencias (también conocidas como ‘referencias’) cerca de la parte inferior:
$ 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
Podría haber sido menos confuso si se hubiera presentado así, pero no lo fue:
repositories (i.e. independent trees)
├──local
│ └──master
│
└──origin1
│ └──master
└──origin2
└──master
Tenemos tres tipos básicos de referencias: cabezas, controles remotosy etiquetas.
.git/refs/cabezas tiene nuestro local Maestro.
.git/refs/controles remotos puede albergar varios mandos, aunque de momento solo tenemos origen en eso.
.git/refs/etiquetas (se discute en otra parte).
origen por lo tanto, es nuestro único control remoto. Se mantiene origen/maestro.
encontramos que tenemos 2 CABEZAS (punteros a las ramas actuales), uno local y otro remoto:
$ 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 enumera su sucursales:
$ 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
...
A continuación, es posible que tenga muchas sucursales de seguimiento remoto, y nosotros lo hacemos aquí. Sabes que estas son ramas de seguimiento remoto porque tienen el prefijo ‘controles remotos/‘. Los que se muestran aquí son para el origen con nombre remoto.
Así que la segunda línea es del origen. rama actual puntero. Remotos/origen: HEAD –apunta a–> maestro. Esto muestra que en el repositorio remoto, la rama actual es su rama llamada Maestro(que no debe confundirse con nuestra sucursal local llamada Maestro).
Las ramas restantes no se encuentran en su árbol .git/refs/, sino que las encontrará en .git/packed-refs.
Cuando nosotros buscar descargamos los cambios del repositorio remoto a nuestro repositorio de seguimiento remoto.
Cuando nosotros combinación de git fusionamos los cambios en este repositorio de seguimiento remoto local en nuestra sucursal o sucursales locales en funcionamiento, en este caso en nuestra sucursal maestra.
(Cuando nosotros tirar de git hacemos estos dos pasos en una sola operación.)
También es interesante notar estos local y remoto UUID para Maestro actualmente apunta al mismo nodo (también conocido como ‘commit’):
$ cat refs/heads/master # local master
1ca409292272632f443733450313de5a82c54a9c
$ cat refs/remotes/origin/master # remote origin master
1ca409292272632f443733450313de5a82c54a9c
Entonces, nuestro maestro local apunta al mismo lugar que el maestro de origen del control remoto:
[local] master = [remote] origin master
Por último, creo que también es útil echar un vistazo a .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
....
Sin duda, esto deja más preguntas que respuestas, pero creo que puede comenzar a ayudarlo a responder sus propias preguntas sobre qué es qué.
@ChristopherWallace: Provocaste dos preguntas en meta con tu edición: “¿Realmente necesitamos un [origin] etiqueta?” y “¿Cuál es la verdadera [Master]?”.
– Deduplicador
1 de julio de 2015 a las 17:19
@Deduplicator ¿Es eso un problema?
– nbro
1 de julio de 2015 a las 18:52
@ChristopherWallace: Bueno, muchos parecen pensar que ambas etiquetas (la que creó y la que acaba de agregar) son malas. Estoy de acuerdo, pero tal vez tenga algo que agregar a la discusión vinculada que no se consideró. Si no, parece que sí.
– Deduplicador
2 de julio de 2015 a las 12:52
Posible duplicado de In Git, ¿cuál es la diferencia entre origin/master vs origin master?
– roottraveller
9 de septiembre de 2019 a las 13:41
Pregunta de seguimiento: ¿Por qué
.git/refs/origin/masteralguna vez a la deriva de.git/refs/remotes/origin/master? Esto me está pasando ahora y me están echando.– Pablo
7 de mayo de 2020 a las 8:45