2010-05-26 16 views
122

Honestamente no tengo claro la semántica aquí. Se trata de copias/variantes de un código + unidad de historial, pero más allá de eso no estoy seguro de poder decirlo. ¿Esta estructura lógica se explica en alguna parte?¿Qué significan estas palabras en Git: repositorio, fork, branch, clone, track?

+5

Recomendaría leer los primeros dos capítulos del libro Pro Git (http://progit.org/book/). – ewall

+56

+1.Muchos de los tutoriales de git le muestran cómo realizar ciertas tareas sin explicar qué significan ciertas palabras o cómo funciona git. Pedir un recurso que aborde esos temas es una pregunta legítima. –

+12

Desearía poder hacer +1 el comentario de Daniel más. Si bien el significado de algunos de los términos (por ejemplo, el repositorio) debe ser obvio, su relación no es siempre (rama vs. fork), y el significado real es fácilmente malinterpretado por alguien acostumbrado a un VCS centralizado. Además, mira "¿qué es una rama?" De Pro Git. sección: ¿un usuario básico realmente quiere saber sobre blobs y árboles, o solo quiere saber cualitativamente qué es una rama? – Cascabel

Respuesta

137

Un repositorio es simplemente un lugar donde se almacena el historial de su trabajo. A menudo vive en un subdirectorio .git de su copia de trabajo, una copia del estado más reciente de los archivos en los que está trabajando.

Para bifurcar un proyecto (tomar la fuente del repositorio de alguien en cierto punto en el tiempo, y aplicarle sus propios cambios divergentes), clonaría el repositorio remoto para crear una copia y luego haría su propio trabajo en su repositorio local y comprometer cambios.

Dentro de un repositorio tiene sucursales, que son realmente tenedores dentro de su propio repositorio. Sus ramas tendrán un ancestro comprometido en su repositorio, y divergirán de ese compromiso con sus cambios. Luego puede fusionar los cambios de sucursal. Las ramas le permiten trabajar en múltiples características dispares a la vez.

También puede rastrear ramas individuales en repositorios remotos. Esto le permite obtener cambios de las ramas de otra persona y fusionarlas en una rama propia. Esto puede ser útil si usted y un amigo están trabajando juntos en una nueva función.

Hay muchos libros geniales en línea. Eche un vistazo a ProGit y Git Magic para comenzar, así como los tutoriales oficiales y el libro de la comunidad.

+0

Por supuesto, leer los manuales y tutoriales F es fundamental. Pero esto me parece un gran resumen de todo el asunto. ¡Muy apreciado! – brasofilo

+0

Tenga en cuenta que puede cambiar su directorio de trabajo local a una nueva rama ("git checkout "). En este caso, los archivos de su directorio de trabajo local se REEMPLAZAN por el contenido de la rama a la que está cambiando. Pero no pierde su trabajo: Git almacena todos los cambios comprometidos ("commit de git") que realizó en la rama anterior en la "base de datos" de Git (carpeta oculta .git) y le permitirá volver a cambiar sus archivos. – KrisWebDev

+3

Creo que requiere una mención especial que, históricamente, independientemente de qué VCS haya utilizado, bifurcación y ramificación se consideraron dos cosas separadas. La ramificación se consideró acuerdo favorable e implícito entre los desarrolladores. Bifurcar fue más serio ya que implicaba que los desarrolladores que trabajaban en un proyecto no estaban de acuerdo en algunas cosas y decidieron separarse. Entonces, los tenedores exitosos generalmente se fusionaron en un proyecto luego de que ambas partes llegaron a un acuerdo. Desde entonces, Git (y GitHub) han difuminado estos términos y ambos términos básicamente representan la misma idea pero de diferentes maneras. – redteam316

12

Voy a responder mi propia pregunta con un RTFM.

Pero, lea this manual fino. Como dice el autor:

“ La conclusión que saco de esto es que solo puedes usar realmente Git si entiendes cómo funciona Git. Simplemente memorice qué comandos debe ejecutar a qué horas funcionará a corto plazo, pero es solo cuestión de tiempo antes de que se quede atascado o, lo que es peor, se rompa algo.

“ La mitad de los recursos existentes en Git, desafortunadamente, adoptan ese mismo enfoque: te guían por los comandos que ejecutar cuando, y esperan que te vaya bien si solo imitas esos comandos. La otra mitad analiza todos los conceptos, pero por lo que he visto explican a Git de una manera que asume que ya entiendes cómo funciona Git. ”

+0

Esta introducción parece haberse trasladado a http://www.sbf5.com/~cduan/technical/git/. La URL original todavía funciona por ahora. –

+1

Esto es cierto dentro del contexto. Si necesitas ser productivo de inmediato o simplemente verificar el código, está bien no tener un conocimiento profundo de cómo funciona Git. Los tutoriales están bien. Así es como me metí en git. Sin embargo, si necesitas estar más avanzado como crear ramas, fork, rebase y otras tareas más avanzadas, entonces debes saber cómo funciona git, especialmente si tu fondo está en un control de fuente centralizado. – Phil

3

This GoogleTechTalk es una fantástica introducción a Git para aprender lo que realmente está sucediendo detrás de las escenas, mientras que el aprendizaje de la lengua también. Lo dio un colaborador muy temprano de Git y dio esta charla en 2007 como una forma de presentación en Git. Si mira esta charla, no solo sabrá qué es cada palabra, como repositorio, bifurcación, bifurcación, etc., sino que también sabrá lo que ocurre detrás de las escenas cuando cada una de ellas está hecha, fusionada, etc.

La dirección es larga pero muy informativa. También contrasta a Git con otros sistemas de control de versiones para que pueda conocer por qué se creó Git tal como era y cuáles son sus ventajas comparativas con respecto a otros sistemas de control. Aunque la charla es antigua, es muy útil comenzar a funcionar. Vería esto antes de saltar a los manuales. Creo que las cosas tendrán mucho más sentido como resultado.