¿Cuáles son las diferencias entre git branch, fork, fetch, merge, rebase y clone?


502

¿Quiero entender la diferencia entre una rama, una bifurcación y un clon en Git?

Del mismo modo, ¿qué significa cuando hago un git fetchen lugar de un git pull?

Además, ¿qué rebasesignifica en comparación con merge?

¿Cómo puedo aplastar los compromisos individuales juntos?

¿Cómo se usan, por qué se usan y qué representan?

¿Cómo figura GitHub?


19
¿Puedes cambiar la respuesta aceptada para que sea la respuesta de Michael Durrant?
siride

11
Por supuesto que puede , pero esta debe ser su elección, y, francamente, la mayoría de las personas que llegan aquí (como yo) quieren algo más conciso, exactamente como la respuesta que eligió, que en este momento era la
tuya

Respuestas:


366

Un clon es simplemente una copia de un repositorio. En la superficie, su resultado es equivalente a svn checkout, donde descargas el código fuente de algún otro repositorio. La diferencia entre VCS centralizado como Subversion y DVCS como Git es que en Git, cuando clonas, en realidad estás copiando todo el repositorio de origen, incluido todo el historial y las ramas. Ahora tiene un nuevo repositorio en su máquina y cualquier confirmación que realice irá a ese repositorio. Nadie verá ningún cambio hasta que envíe esas confirmaciones a otro repositorio (o al original) o hasta que alguien extraiga las confirmaciones de su repositorio, si es de acceso público.

Una rama es algo que está dentro de un repositorio. Conceptualmente, representa un hilo de desarrollo. Por lo general, tiene una rama maestra, pero también puede tener una rama en la que está trabajando en alguna característica xyz, y otra para corregir errores abc. Cuando haya desprotegido una rama, las confirmaciones que realice permanecerán en esa rama y no se compartirán con otras ramas hasta que las combine o las rebase en la rama en cuestión. Por supuesto, Git parece un poco extraño cuando se trata de ramas hasta que observas el modelo subyacente de cómo se implementan las ramas. En lugar de explicarlo yo mismo (ya he dicho demasiado, creo), enlazaré con la explicación "informática" de cómo Git modela ramas y se compromete, tomada del sitio web de Git:

http://eagain.net/articles/git-for-computer-scientists/

Una bifurcación no es realmente un concepto Git, es más una idea política / social. Es decir, si algunas personas no están contentas con la forma en que se desarrolla un proyecto, pueden tomar el código fuente y trabajar en él por separado de los desarrolladores originales. Eso se consideraría un tenedor. Git facilita la bifurcación porque todos ya tienen su propia copia "maestra" del código fuente, por lo que es tan simple como cortar los lazos con los desarrolladores del proyecto original y no requiere exportar el historial desde un repositorio compartido como podría tener que ver con SVN .

EDITAR: dado que no estaba al tanto de la definición moderna de "fork" como la usan sitios como GitHub, por favor, eche un vistazo a los comentarios y también a la respuesta de Michael Durrant debajo de la mía para obtener más información.


125
Una bifurcación no significa necesariamente que el desarrollador no esté contento con el repositorio principal. Por lo general, significa que otro desarrollador ha leído, pero no ha escrito, acceso a ese repositorio. El desarrollador puede bifurcar el repositorio, hacer cambios, pero como no puede escribir en el repositorio principal, debe enviar sus cambios como un parche. Entonces, la bifurcación también es un medio para alentar la colaboración sin otorgar acceso de escritura.
brycemcd

55
Supongo que es verdad. Solo he visto "fork" en el contexto de la creación de una versión nueva y potencialmente competitiva de un proyecto.
siride

32
Se podría decir que una bifurcación es una rama que no se espera que se fusione en sentido ascendente
2010

66
Git Hub usa "fork" como se entiende fork. Es un nuevo repositorio almacenado en github, separado del original. Sin embargo, github también hace que sea muy simple implementar solicitudes de extracción. Las solicitudes de extracción esencialmente le piden al propietario del repositorio original que "extraiga" los cambios de la bifurcación del repositorio de vuelta al origen. De esa manera, todos pueden usar el control de fuente y tener un historial de todos los cambios, incluido el suyo, pero no todos necesitan acceso de escritura al repositorio original.
mklauber

44
He actualizado mi respuesta para decirle a la gente que mire la respuesta de Michael Durrant para obtener más información sobre el modelo de github.
siride

531

Git

Esta respuesta incluye GitHub ya que muchas personas también han preguntado sobre eso.

Repositorios locales

Git (localmente) tiene un directorio ( .git) al que compromete sus archivos y este es su 'repositorio local'. Esto es diferente de los sistemas como SVN donde agrega y se compromete al repositorio remoto de inmediato.

Git almacena cada versión de un archivo que cambia guardando todo el archivo. También es diferente de SVN a este respecto, ya que podría acceder a cualquier versión individual sin 'recrearla' a través de cambios delta.

Git no 'bloquea' archivos en absoluto y, por lo tanto, evita la funcionalidad 'bloqueo exclusivo' para una edición (los sistemas más antiguos como pvcs vienen a la mente), por lo que todos los archivos siempre se pueden editar, incluso cuando están fuera de línea. En realidad, hace un trabajo increíble al fusionar los cambios de archivos (¡dentro del mismo archivo!) Juntos durante las extracciones o recuperaciones / empujes a un repositorio remoto como GitHub. La única vez que necesita hacer cambios manuales (en realidad editando un archivo) es si dos cambios involucran las mismas líneas de código.


Ramas

Las ramas le permiten conservar el código principal (la rama 'maestra'), hacer una copia (una nueva rama) y luego trabajar dentro de esa nueva rama. Si el trabajo lleva un tiempo o el maestro recibe muchas actualizaciones desde que se realizó la bifurcación, se debe hacer una fusión o rebase (a menudo preferido para un mejor historial y conflictos más fáciles de resolver) contra la bifurcación maestra. Cuando haya terminado, fusionará los cambios realizados en la rama nuevamente en el repositorio maestro. Muchas organizaciones usan ramas para cada trabajo, ya sea un elemento de función, error o tarea. Otras organizaciones solo usan sucursales para cambios importantes, como actualizaciones de versión.

Bifurcación: con una bifurcación usted controla y administra la bifurcación, mientras que con una bifurcación alguien más controla la aceptación del código nuevamente.

En términos generales, hay dos enfoques principales para hacer ramas. El primero es mantener la mayoría de los cambios en la rama maestra, solo usando ramas para cosas más grandes y de mayor duración, como cambios de versión, donde desea tener dos ramas disponibles para diferentes necesidades. El segundo es mediante el cual básicamente se hace una rama para cada solicitud de función, corrección de errores o tarea y luego se decide manualmente cuándo fusionar esas ramas en la rama maestra principal. Aunque esto suena tedioso, este es un enfoque común y es el que uso y recomiendo actualmente porque esto mantiene la rama maestra más limpia y es la maestra que promovemos a la producción, por lo que solo queremos un código completo y probado, a través del rebase y fusión de ramas.

La forma estándar de traer una rama 'en' al maestro es hacer a merge. Las ramas también se pueden "rebasear" para "limpiar" el historial. No afecta el estado actual y se hace para dar un historial 'más limpio'.

Básicamente, la idea es que te ramifiques desde cierto punto (generalmente desde el maestro). Desde que se bifurcó, 'master' se ha movido desde ese punto de bifurcación. Será 'más limpio' (más fácil de resolver problemas y el historial será más fácil de entender) si todos los cambios que ha realizado en una rama se juegan contra el estado actual del maestro con todos sus últimos cambios. Entonces, el proceso es: guardar los cambios; obtenga el 'nuevo' maestro, y luego vuelva a aplicar (esta es la parte de rebase) los cambios nuevamente contra eso. Tenga en cuenta que el rebase, al igual que la fusión, puede generar conflictos que debe resolver manualmente (es decir, editar y corregir).

Una pauta a tener en cuenta: ¡
Solo vuelva a crear un rebase si la sucursal es local y aún no la ha colocado en remota!
Esto se debe principalmente a que el rebase puede alterar la historia que otras personas ven y que puede incluir sus propios compromisos.

Rastreo de ramas

Estas son las ramas que se nombran origin/branch_name(en lugar de solo branch_name). Cuando empuja y tira el código hacia / desde repositorios remotos, este es realmente el mecanismo a través del cual eso sucede. Por ejemplo, cuando git pushllama una rama building_groups, su rama va primero origin/building_groupsy luego va al repositorio remoto. Del mismo modo, si hace una git fetch building_groups, el archivo que se recupera se coloca en su origin/building_groupsrama. Luego puede optar por fusionar esta rama en su copia local. Nuestra práctica es hacer siempre una git fetchfusión manual y una en lugar de solo una git pull(que hace las dos cosas anteriores en un solo paso).

Obteniendo nuevas ramas.

Obtención de nuevas ramas: en el punto inicial de un clon tendrá todas las ramas. Sin embargo, si otros desarrolladores agregan ramas y las envían al control remoto, debe haber una manera de 'saber' sobre esas ramas y sus nombres para poder desplegarlas localmente. Esto se realiza a través de una git fetchque llevará todas las ramas nuevas y modificadas al repositorio local utilizando las ramas de seguimiento (por ejemplo, origin/). Una vez fetcheditado, se puede git branch --remoteenumerar las ramas de seguimiento y git checkout [branch]cambiar a una determinada.

Fusionando

La fusión es el proceso de combinar cambios de código de diferentes ramas, o de diferentes versiones de la misma rama (por ejemplo, cuando una rama local y remota no están sincronizadas). Si uno ha desarrollado trabajo en una rama y el trabajo está completo, listo y probado, entonces puede fusionarse en la masterrama. Esto se hace git checkout masterpara cambiar a la masterrama, entonces git merge your_branch. La fusión traerá todos los diferentes archivos e incluso diferentes cambios a los mismos archivos juntos. Esto significa que en realidad cambiará el código dentro de los archivos para fusionar todos los cambios.

Al hacer la checkoutde masterTambién es recomendable hacer una git pull origin masterpara obtener la última versión de la maestra remota fusionado en su maestro local. Si el maestro remoto cambió, es decir, moved forwardverá información que refleje eso durante eso git pull. Si ese es el caso (maestro cambiado), se le recomienda que lo haga git checkout your_branchy luego rebaselo haga para que sus cambios se "reproduzcan" en la parte superior del "nuevo" maestro. Luego continuaría con la actualización del master como se muestra en el siguiente párrafo.

Si no hay conflictos, el maestro tendrá los nuevos cambios agregados. Si hay conflictos, esto significa que los mismos archivos tienen cambios alrededor de líneas de código similares que no se pueden combinar automáticamente. En este caso git merge new_branchinformará que hay conflictos que resolver. Los 'resuelve' editando los archivos (que tendrán ambos cambios), seleccionando los cambios que desea, literalmente eliminando las líneas de los cambios que no desea y luego guardando el archivo. Los cambios están marcados con separadores como ========y <<<<<<<<.

Una vez que haya resuelto cualquier conflicto que, una vez más git addy git commitesos cambios para continuar la fusión (que obtendrá retroalimentación de git durante este proceso para guiarle).

Cuando el proceso no funciona bien, encontrará que git merge --abortes muy útil para restablecer las cosas.

Rebajas interactivas y aplastamiento / reordenamiento / eliminación de confirmaciones

Si ha trabajado en muchos pasos pequeños, por ejemplo, confirma el código como "trabajo en progreso" todos los días, es posible que desee "aplastar" esas pequeñas confirmaciones en unas pocas confirmaciones más grandes. Esto puede ser particularmente útil cuando desea hacer revisiones de código con colegas. No desea volver a reproducir todos los 'pasos' que realizó (a través de commits), solo quiere decir que aquí está el efecto final (diff) de todos mis cambios para este trabajo en un commit.

El factor clave a evaluar cuando se considera si hacer esto es si las confirmaciones múltiples están en contra del mismo archivo o archivos más de una vez (mejor aplastar las confirmaciones en ese caso). Esto se hace con la herramienta interactiva de rebase. Esta herramienta le permite aplastar confirmaciones, eliminar confirmaciones, reformular mensajes, etc. Por ejemplo, git rebase -i HEAD~10( nota: eso es ~, no a- ) muestra lo siguiente:

rebase interactivo en Git

Sin embargo, tenga cuidado y use esta herramienta "con cautela". Haga un squash / delete / reordenar a la vez, salga y guarde ese commit, luego vuelva a ingresar la herramienta. Si las confirmaciones no son contiguas, puede reordenarlas (y luego eliminarlas según sea necesario). En realidad, también puede eliminar confirmaciones aquí, ¡pero realmente necesita estar seguro de lo que está haciendo cuando hace eso!

tenedores

Hay dos enfoques principales para la colaboración en repositorios de Git. El primero, detallado anteriormente, es directamente a través de ramas que la gente tira y empuja desde / hacia. Estos colaboradores tienen sus claves SSH registradas con el repositorio remoto. Esto les permitirá empujar directamente a ese repositorio. La desventaja es que debe mantener la lista de usuarios. El otro enfoque, la bifurcación, permite a cualquiera 'bifurcar' el repositorio, básicamente haciendo una copia local en su propia cuenta de repositorio Git. Luego pueden hacer cambios y, cuando terminen, enviar una 'solicitud de extracción' (en realidad es más una 'inserción' de ellos y una solicitud de 'extracción' para el responsable del repositorio real) para que se acepte el código.

Este segundo método, el uso de horquillas, no requiere que alguien mantenga una lista de usuarios para el repositorio.


GitHub

GitHub (un repositorio remoto) es una fuente remota a la que normalmente empuja y extrae esos cambios confirmados si tiene (o se agrega) a dicho repositorio, por lo que local y remoto son realmente bastante distintos. Otra forma de pensar en un repositorio remoto es que es una .gitestructura de directorio que vive en un servidor remoto.

Cuando 'bifurca' - en la GUI del navegador web de GitHub puedes hacer clic en este botón Imagen del botón de horquilla- creas una copia ('clonar') del código en tu cuenta de GitHub. Puede ser un poco sutil la primera vez que lo haces, así que asegúrate de mirar en qué repositorio se enumera una base de código, ya sea el propietario original o 'bifurcado' y tú, por ejemplo, así:

Imagen del nombre del repositorio bifurcado

Una vez que tenga la copia local, puede hacer los cambios que desee (tirando y empujándolos a una máquina local). Cuando termine, envíe una 'solicitud de extracción' al propietario / administrador del repositorio original (suena elegante, pero en realidad solo hace clic en esto:) Imagen del botón de solicitud de extraccióny lo 'extraen'.

Más común para un equipo que trabaja en código juntos es 'clonar' el repositorio (haga clic en el icono 'copiar' en la pantalla principal del repositorio). Luego, escriba git cloney pegue localmente . Esto lo configurará localmente y también puede empujar y tirar a la ubicación (compartida) de GitHub.

Clones

Como se indica en la sección de GitHub, un clon es una copia de un repositorio. Cuando tiene un repositorio remoto, emite el git clonecomando contra su URL y luego termina con una copia local, o clon, del repositorio. Este clon tiene todo , los archivos, la rama maestra, las otras ramas, todos los commits existentes, todo el shebang. Es a este clon con el que hace sus adiciones y confirmaciones y luego el repositorio remoto es a lo que empuja esas confirmaciones. Es este concepto local / remoto lo que hace que Git (y sistemas similares a él, como Mercurial), sea un DVCS ( Sistema de control de versiones distribuido ) en lugar de los CVS (sistemas de control de versiones de código) más tradicionales, como SVN, PVCS, CVS, etc., donde usted se compromete directamente con el repositorio remoto.

Visualización

La visualización de los conceptos básicos se puede ver en
http://marklodato.github.com/visual-git-guide/index-en.html y
http://ndpsoftware.com/git-cheatsheet.html#loc=index

Si desea una visualización de cómo funcionan los cambios, no puede superar la herramienta visual gitg( gitxpara macOS) con una GUI que llamo 'el mapa del metro' (especialmente London Underground), ideal para mostrar quién hizo qué, cómo cambian las cosas, divergen y se fusionan, etc.

¡También puede usarlo para agregar, confirmar y administrar sus cambios!

Imagen de la interfaz gitg / gitx

Aunque gitg / gitx es bastante mínimo, la cantidad de herramientas GUI continúa expandiéndose. Muchos usuarios de Mac usan la bifurcación de gitx de brotherbard y para Linux, una gran opción es smart-git con una interfaz intuitiva pero potente:

Imagen de la GUI de smart-git

Tenga en cuenta que incluso con una herramienta GUI, probablemente ejecutará muchos comandos en la línea de comandos.

Para esto, tengo los siguientes alias en mi ~/.bash_aliasesarchivo (que se llama desde mi ~/.bashrcarchivo para cada sesión de terminal):

# git
alias g='git status'
alias gcob='git checkout -b '
alias gcom='git checkout master'
alias gd='git diff'
alias gf='git fetch'
alias gfrm='git fetch; git reset --hard origin/master'
alias gg='git grep '
alias gits='alias | grep "^alias g.*git.*$"'
alias gl='git log'
alias gl1='git log --oneline'
alias glf='git log --name-status'
alias glp='git log -p'
alias gpull='git pull '
alias gpush='git push '

Y tengo los siguientes "alias git" en mi ~/.gitconfigarchivo: ¿por qué tenerlos?
¡Para que la finalización de la rama (con la tecla TAB) funcione!

Entonces estos son:

[alias]
  co = checkout
  cob = checkout -b

Ejemplo de uso: git co [branch]<- completar la pestaña para las ramas funcionará.

Herramienta de aprendizaje GUI

Puede encontrar https://learngitbranching.js.org/ útil para aprender algunos de los conceptos básicos. Captura de pantalla: Video: https://youtu.be/23JqqcLPss0ingrese la descripción de la imagen aquí

¡Finalmente, 7 salvavidas clave!

  1. Haces cambios, los agregas y los confirmas (pero no presionas) y luego ¡oh! te das cuenta de que estás en el maestro!

    git reset [filename(s)]
    git checkout -b [name_for_a_new_branch]
    git add [file(s)]
    git commit -m "A useful message"
    
    Voila!  You've moved that 'master' commit to its own branch !
  2. Desordena algunos archivos mientras trabaja en una sucursal local y simplemente quiere volver a lo que tenía la última vez que hizo un git pull:

    git reset --hard origin/master  # You will need to be comfortable doing this!
  3. Empiezas a hacer cambios localmente, editas media docena de archivos y luego, oh mierda, todavía estás en la rama maestra (u otra):

    git checkout -b new_branch_name  # just create a new branch
    git add .                      # add the changes files
    git commit -m"your message"    # and commit them
  4. Arruina un archivo en particular en su rama actual y básicamente quiere 'restablecer' ese archivo (perder cambios) como estaba la última vez que lo sacó del repositorio remoto:

    git checkout your/directories/filename

    En realidad, esto restablece el archivo (como muchos comandos de Git, no está bien nombrado por lo que está haciendo aquí).

  5. Realiza algunos cambios localmente, desea asegurarse de no perderlos mientras realiza una git reseto rebase: a menudo hago una copia manual de todo el proyecto ( cp -r ../my_project ~/) cuando no estoy seguro de si podría estropear Git o perder importantes cambios

  6. Estás rebatiendo pero las cosas se complican:

    git rebase --abort # To abandon interactive rebase and merge issues
  7. Agregue su rama Git a su PS1solicitud (consulte https://unix.stackexchange.com/a/127800/10043 ), por ejemplo

    Imagen de aviso

    La rama es selenium_rspec_conversion.


1
20/02/12 Se agregó información sobre fusión vs. rebase
Michael Durrant

1
16/06/12 Se agregó una sección sobre clones para hacerlo más completo.
Michael Durrant

44
Tanto texto !! Me atendré a mi Subversion simple :-)
Jonny

66
eh? Un usuario de subversion también podría escribir un libro sobre el uso de subversion. En mi opinión, la subversión es una tecnología más antigua con menos funcionalidad. Personalmente, encuentro que git es muy fácil de usar. ymmv
Michael Durrant

3
¡Guau, Micheal! SO se trata de compartir conocimiento. Gracias por el gran trabajo, definitivamente +1
Michiel

143

Aquí está la imagen de Oliver Steele de cómo encaja todo:

ingrese la descripción de la imagen aquí


66
Esta imagen podría actualizarse para agregar "git clone", que estoy seguro de que la mayoría de la gente está familiarizada en cualquier caso.
Contango

3
@Gravitas, realmente me encanta este gráfico, pero no me dice cuándo se sobrescriben los archivos y cuándo se fusionan. ¿Podría decirme cuál es cuál para estos comandos? ¿Quizás los comandos de sobrescritura en la parte superior y los comandos de fusión debajo de las unidades? Gracias.
zylstra

Por lo que entiendo, git pull se desplegará desde un control remoto lo que pidas (por lo tanto, cualquier baúl que estés pidiendo) y se fusionará instantáneamente en la rama en la que te encuentras cuando realices la solicitud. Pull es una solicitud de alto nivel que ejecuta 'fetch' y luego una 'merge' de forma predeterminada, o un rebase con '–rebase'. Podrías prescindir de él, es solo una comodidad.
Contango

¿A dónde iría exactamente git clone en este diagrama? También git merge? Soy muy nuevo en git pero me gusta esta foto.
Mishelle

2
Veré si puedo hacer una versión actualizada del diagrama.
Contango

8

Tenedor vs. Clon: dos palabras que significan copia

Por favor vea este diagrama. (Originalmente de http://www.dataschool.io/content/images/2014/Mar/github1.png ).

.-------------------------.     1. Fork     .-------------------------.
| Your GitHub repo        | <-------------- | Joe's GitHub repo       |
| github.com/you/coolgame |                 | github.com/joe/coolgame |
| ----------------------- | 7. Pull Request | ----------------------- |
| master -> c224ff7       | --------------> | master -> c224ff7 (c)   |
| anidea -> 884faa1 (a)   |                 | anidea -> 884faa1 (b)   |
'-------------------------'                 '-------------------------'
    |                 ^
    | 2. Clone        |
    |                 |
    |                 |
    |                 |
    |                 |
    |                 | 6. Push (anidea => origin/anidea)
    v                 |
.-------------------------.
| Your computer           |  3. Create branch 'anidea'
| $HOME/coolgame          |
| ----------------------- |  4. Update a file
| master -> c224ff7       |
| anidea -> 884faa1       |  5. Commit (to 'anidea')
'-------------------------'

(a) - after you have pushed it
(b) - after Joe has accepted it
(c) - eventually Joe might merge 'anidea' (make 'master -> 884faa1')

Tenedor

  • Una copia a su repositorio remoto (nube) que lo vincula a Joe's
  • Una copia que luego puede clonar en su repositorio local y F *% $ - arriba
  • Cuando haya terminado, puede regresar a su control remoto
  • Luego puede preguntarle a Joe si quiere usarlo en su proyecto haciendo clic en pull-request

Clon

  • una copia a su repositorio local (disco duro)

Tenga en cuenta que la verdadera ventaja de DVCS es que no necesita ningún permiso de acceso específico al repositorio de Joe para hacer esto. Si Joe le pide que contribuya con más frecuencia, podría otorgarle derechos de acceso de inserción: ellos podrían presionar anideadirectamente a su repositorio y ahorrarle las tareas de mantener su tenedor actualizado. OTOH, si no logra llegar a un acuerdo con Joe, podría seguir desarrollando y utilizando su tenedor (y ver si puede hacer que cambie de opinión más adelante).
Alois Mahdal

6

Solo para agregar a otros, una nota específica para bifurcar.

Es bueno darse cuenta de que técnicamente, clonar el repositorio y bifurcar el repositorio es lo mismo. Hacer:

git clone $some_other_repo

y puedes tocarte en la espalda --- acabas de bifurcar otro repositorio.

Git, como VCS, de hecho se trata de bifurcación de clonación . Además de "simplemente navegar" usando la IU remota como cgit, hay muy poco que ver con el repositorio de git que no implica bifurcar la clonación del repositorio en algún momento.

Sin embargo,

  • cuando alguien dice que bifurqué el repositorio X , significan que han creado un clon del repositorio en otro lugar con la intención de exponerlo a otros, por ejemplo, para mostrar algunos experimentos o para aplicar un mecanismo de control de acceso diferente (por ejemplo, para permitir que las personas sin Acceso a Github pero con cuenta interna de la empresa para colaborar).

    Hechos que: el repositorio probablemente se crea con otro comando que git clone, probablemente esté alojado en algún lugar en un servidor en lugar de la computadora portátil de alguien, y lo más probable es que tenga un formato ligeramente diferente (es un "repositorio desnudo", es decir, sin árbol de trabajo) son todos solo detalles técnicos.

    El hecho de que probablemente contendrá diferentes conjuntos de ramas, etiquetas o confirmaciones es probablemente la razón por la que lo hicieron en primer lugar.

    (Lo que hace Github cuando hace clic en "tenedor", es simplemente clonar con azúcar agregada: clona el repositorio por usted, lo coloca en su cuenta, registra el "bifurcado de alguna parte", agrega el control remoto llamado "ascendente" y, lo más importante, reproduce la bonita animación)

  • Cuando alguien dice que cloné el repositorio X , significan que han creado un clon del repositorio localmente en su computadora portátil o de escritorio con la intención de estudiarlo, jugar con él, contribuir a él o construir algo a partir del código fuente.

La belleza de Git es que hace que todo encaje perfectamente: todos estos repositorios comparten la parte común de la cadena de confirmación de bloque , por lo que es posible fusionar de forma segura (ver la nota a continuación) los cambios de un lado a otro entre todos estos repositorios como mejor le parezca.


Nota: "con seguridad" siempre y cuando no reescriba la parte común de la cadena, y siempre que los cambios no sean conflictivos.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.