En git, ¿en qué se diferencia fetch de pull y en qué se diferencia merge de rebase?
160
Simplemente no puedo entender esto. He estado leyendo mucho en la web y en los libros, y algo no se me pasa por la cabeza. ¿Puede alguien darme la versión ficticia de lo siguiente:
Simpatizo con el interrogador. La documentación y los consejos son tan pesados y las posibles permutaciones del flujo de trabajo son tan enormes que uno se confunde mucho. La cabeza de uno explotó y uno no sabe qué preguntar, simplemente no es tan obvio.
Ed Randall
3
¿Por qué no elegir la respuesta de Pestrella como aceptada?
Arashsoft
@Arashsoft porque no se lo ve desde 2013
VdeX
Respuestas:
415
buscar vs tirar
fetch descargará cualquier cambio desde la sucursal remota *, actualizando los datos de su repositorio, pero sin modificar su sucursal local *.
pullrealizará ay fetchademás mergelos cambios en su sucursal local.
¿Cual es la diferencia? pullactualiza su sucursal local con cambios desde la sucursal extraída. A fetchno adelanta su sucursal local.
fusionar vs rebase
Dada la siguiente historia:
C --- D --- E local
/ /
A --- B --- F --- G remoto
mergeune dos historias de desarrollo juntas. Para ello, reproduce los cambios que ocurrieron en su sucursal local después de que divergiera en la parte superior de la sucursal remota y registra el resultado en una nueva confirmación. Esta operación conserva la ascendencia de cada confirmación.
El efecto de un mergeserá:
C --- D --- E local
/ \
A --- B --- F --- G --- H remoto
rebasetomará confirmaciones que existen en su sucursal local y las volverá a aplicar en la parte superior de la sucursal remota. Esta operación reescribe los antepasados de sus commits locales.
El efecto de un rebaseserá:
C '- D' - E 'local
/ /
A --- B --- F --- G remoto
¿Cual es la diferencia? A mergeno cambia la ascendencia de los commits. A rebase
reescribe la ascendencia de tus commits locales.
*Esta explicación supone que la rama actual es una sucursal local, y que la rama especifica como el argumento para fetch, pull, merge, o rebasees una rama remota. Este es el caso habitual. pull, por ejemplo, descargará cualquier cambio desde la rama especificada , actualizará su repositorio y mergelos cambios en la rama actual .
Esta es, con mucho, la mejor y más simple explicación sin entrar en el debate detrás de cada práctica. ¡Gracias!
Jonathan S. Fisher
3
Respuesta absolutamente dorada
ChaseMoskal
55
Ojalá pudiera "favorito" esta respuesta. Tal vez solo lo imprima y lo pegue en mi pared.
LarsH
2
Diría la mejor de las mejores respuestas que tengo en stackoverflow, gracias
Shahab J
1
Si fetch solo descarga los cambios desde la rama remota y actualiza los datos del repositorio, pero deja la rama local sin cambios, entonces, ¿cuál es el punto de recuperación si el directorio de trabajo no muestra / refleja los cambios? Originalmente, mi pregunta era cómo podía ver los cambios que alguien más había hecho y luego decidir si me gustaría fusionarlos en mi directorio de trabajo (es decir, experimentar con los cambios de otras personas para asegurarme de que no interrumpa mi trabajo), pero todavía estoy confundido cómo hacer eso? ¿Debería simplemente pulsar y experimentar / explorar, y si era problemático, hacer un restablecimiento completo?
28
Fetch vs Pull
Git fetch solo actualiza sus datos de repositorio, pero un git pull básicamente realizará una recuperación y luego fusionará la rama extraída
La fusión reúne dos líneas de desarrollo al tiempo que preserva la ascendencia de cada historial de confirmación.
Por el contrario, el rebase unifica las líneas de desarrollo al reescribir los cambios desde la rama de origen para que aparezcan como elementos secundarios de la rama de destino, pretendiendo efectivamente que esas confirmaciones se escribieron en la parte superior de la rama de destino todo el tiempo.
Además, echa un vistazo a Learn Git Branching , que es un buen juego que acaba de publicarse en HackerNews ( enlace a la publicación ) y enseña muchos trucos de ramificación y fusión. Creo que será muy útil en este asunto.
gracias Felips ... así que si hago una búsqueda desde un control remoto, ¿mi rama maestra no tendrá las actualizaciones? También suena como si tuviera que hacer más que rebase Merga
techsjs2013
rebase vs merge depende de cuál sea su intención, teniendo en cuenta que rebase reescribe todo el historial de commits. Y sí, si solo busca, la rama maestra no se cambiará, tendrá que fusionar (o extraer) para que aplique los cambios remotos
Felipe Sabino
git merge <remote>/<branch>. por ejemplo, si usted es la rama maestra y su control remoto se llama origen, puede hacerlo git merge origin/master.
Felipe Sabino
por lo que parece que siempre debería hacer un git checkout master git fetch git diff origin / master git rebase origin master
techsjs2013
8
pull vs fetch :
La forma en que entiendo esto es que git pulles simplemente git fetchseguido por git merge. Es decir, busca los cambios desde una rama remota y luego los combina en la rama actual.
fusionar vs rebase :
Una fusión hará lo que dice el comando; fusionar las diferencias entre la rama actual y la rama especificada (en la rama actual). Es decir, el comando git merge another_branchse fusionará another_branchcon la rama actual.
Un rebase funciona un poco diferente y es genial. Digamos que ejecuta el comando git rebase another_branch. Git primero encontrará la última versión común entre la rama actual y another_branch. Es decir, el punto antes de que las ramas divergieran. Entonces git moverá este punto divergente a la cabeza del another_branch. Finalmente, todos los commits en la rama actual desde el punto divergente original se reproducen desde el nuevo punto divergente. Esto crea un historial muy limpio, con menos ramas y fusiones.
Sin embargo, no está exento de dificultades. Como el historial de versiones se "reescribe", solo debe hacer esto si las confirmaciones solo existen en su repositorio local de git. Es decir: nunca haga esto si ha enviado las confirmaciones a un repositorio remoto.
La explicación sobre rebase dada en este libro en línea es bastante buena, con ilustraciones fáciles de entender.
tirar con rebase en lugar de fusionar
De hecho, estoy usando rebase bastante, pero generalmente está en combinación con pull:
git pull --rebase
buscará cambios remotos y luego volverá a crear una base en lugar de fusionar. Es decir, reproducirá todas sus confirmaciones locales desde la última vez que realizó una extracción. Encuentro esto mucho más limpio que hacer una extracción normal con la fusión, lo que creará una confirmación adicional con las fusiones.
así que si estoy trabajando en una rama y quiero fusionarla nuevamente en el maestro antes de hacer un empujón ¿Debería pagar master, luego obtener una corrección de rebase?
techsjs2013
Todavía no entiendo fusionar vs rebase
techsjs2013
Creo que las ilustraciones proporcionadas por la respuesta de Pestrella muestran la diferencia con bastante claridad. Además, consulte: git-scm.com/book/en/Git-Branching-Rebasing , que hace un trabajo bastante decente al explicarlo (el mismo enlace que el de la respuesta, pero dado nuevamente para los perezosos).
Steinar
0
Fusionar : la rama HEAD generará una nueva confirmación, preservando la ascendencia de cada historial de confirmación. La historia puede contaminarse si varias personas que trabajan en la misma rama en paralelo realizan compromisos de fusión.
Rebase : reescribe los cambios de una rama en otra sin crear una nueva confirmación. El historial de código es simplificado, lineal y legible, pero no funciona con solicitudes de extracción, porque no puede ver qué cambios menores realizó alguien.
Lo usaría git mergeal tratar con el flujo de trabajo basado en características o si no estoy familiarizado con rebase. Pero, si quiero un historial más limpio y lineal, entonces git rebasees más apropiado. Para obtener más detalles, asegúrese de consultar este artículo de combinación o cambio de base .
Respuestas:
buscar vs tirar
fetchdescargará cualquier cambio desde la sucursal remota *, actualizando los datos de su repositorio, pero sin modificar su sucursal local *.pullrealizará ayfetchademásmergelos cambios en su sucursal local.¿Cual es la diferencia?
pullactualiza su sucursal local con cambios desde la sucursal extraída. Afetchno adelanta su sucursal local.fusionar vs rebase
Dada la siguiente historia:
C --- D --- E local / / A --- B --- F --- G remotomergeune dos historias de desarrollo juntas. Para ello, reproduce los cambios que ocurrieron en su sucursal local después de que divergiera en la parte superior de la sucursal remota y registra el resultado en una nueva confirmación. Esta operación conserva la ascendencia de cada confirmación.El efecto de un
mergeserá:C --- D --- E local / \ A --- B --- F --- G --- H remotorebasetomará confirmaciones que existen en su sucursal local y las volverá a aplicar en la parte superior de la sucursal remota. Esta operación reescribe los antepasados de sus commits locales.El efecto de un
rebaseserá:C '- D' - E 'local / / A --- B --- F --- G remoto¿Cual es la diferencia? A
mergeno cambia la ascendencia de los commits. Arebasereescribe la ascendencia de tus commits locales.*Esta explicación supone que la rama actual es una sucursal local, y que la rama especifica como el argumento parafetch,pull,merge, orebasees una rama remota. Este es el caso habitual.pull, por ejemplo, descargará cualquier cambio desde la rama especificada , actualizará su repositorio ymergelos cambios en la rama actual .fuente
Fetch vs Pull
Git fetch solo actualiza sus datos de repositorio, pero un git pull básicamente realizará una recuperación y luego fusionará la rama extraída
¿Cuál es la diferencia entre 'git pull' y 'git fetch'?
Combinar vs Rebase
del blog, fusión o rebase de Atlassian SourceTree :
Además, echa un vistazo a Learn Git Branching , que es un buen juego que acaba de publicarse en HackerNews ( enlace a la publicación ) y enseña muchos trucos de ramificación y fusión. Creo que será muy útil en este asunto.
fuente
git merge <remote>/<branch>. por ejemplo, si usted es la rama maestra y su control remoto se llama origen, puede hacerlogit merge origin/master.pull vs fetch :
La forma en que entiendo esto es que
git pulles simplementegit fetchseguido porgit merge. Es decir, busca los cambios desde una rama remota y luego los combina en la rama actual.fusionar vs rebase :
Una fusión hará lo que dice el comando; fusionar las diferencias entre la rama actual y la rama especificada (en la rama actual). Es decir, el comando
git merge another_branchse fusionaráanother_branchcon la rama actual.Un rebase funciona un poco diferente y es genial. Digamos que ejecuta el comando
git rebase another_branch. Git primero encontrará la última versión común entre la rama actual yanother_branch. Es decir, el punto antes de que las ramas divergieran. Entonces git moverá este punto divergente a la cabeza delanother_branch. Finalmente, todos los commits en la rama actual desde el punto divergente original se reproducen desde el nuevo punto divergente. Esto crea un historial muy limpio, con menos ramas y fusiones.Sin embargo, no está exento de dificultades. Como el historial de versiones se "reescribe", solo debe hacer esto si las confirmaciones solo existen en su repositorio local de git. Es decir: nunca haga esto si ha enviado las confirmaciones a un repositorio remoto.
La explicación sobre rebase dada en este libro en línea es bastante buena, con ilustraciones fáciles de entender.
tirar con rebase en lugar de fusionar
De hecho, estoy usando rebase bastante, pero generalmente está en combinación con pull:
buscará cambios remotos y luego volverá a crear una base en lugar de fusionar. Es decir, reproducirá todas sus confirmaciones locales desde la última vez que realizó una extracción. Encuentro esto mucho más limpio que hacer una extracción normal con la fusión, lo que creará una confirmación adicional con las fusiones.
fuente
Fusionar : la rama HEAD generará una nueva confirmación, preservando la ascendencia de cada historial de confirmación. La historia puede contaminarse si varias personas que trabajan en la misma rama en paralelo realizan compromisos de fusión.
Rebase : reescribe los cambios de una rama en otra sin crear una nueva confirmación. El historial de código es simplificado, lineal y legible, pero no funciona con solicitudes de extracción, porque no puede ver qué cambios menores realizó alguien.
Lo usaría
git mergeal tratar con el flujo de trabajo basado en características o si no estoy familiarizado con rebase. Pero, si quiero un historial más limpio y lineal, entoncesgit rebasees más apropiado. Para obtener más detalles, asegúrese de consultar este artículo de combinación o cambio de base .fuente