Terminología utilizada por Git

parece que tengo que aprender a usar git. Lo cual probablemente sea una buena cosa (TM). Sin embargo, la lectura de guías en línea y páginas de manual, simplemente no puedo entender la terminología. Todo está siempre definido en términos de sí mismos u otros términos inexplicables (haz un "hombre idiota" y verás lo que quiero decir).

Entonces, ¿hay una estructura de definiciones de términos similar a DAG, incluyendo algunas de las siguientes (todas tomadas de las páginas de git man). Tal vez usar un sistema de files como punto de partida y no asumir que el lector está bien versado en svn (que no soy).

  • repo
  • repository
  • un idiota
  • "el git"
  • índice
  • clon
  • cometer
  • twig
  • tree
  • río arriba
  • una cabeza
  • CABEZA
  • versión
  • label
  • file
  • parche
  • sumisión
  • set de cambios
  • alijo
  • file
  • object
  • module
  • submodule
  • refspec
  • una historia

Aunque puedo encontrar explicaciones para algunos, por lo general son en términos del otro. También algunos otros términos que sí sé de otros contexts (como un diff de UNIX). Sin embargo, algunos otros pensé que sabía …

He llegado a la conclusión de que hay repositorys (¿similares a gits? Y / o treees? Upstream?), Que copy (clone? Branch?) Para get los files físicamente en su disco duro. Luego, ¿hay twigs (similares a los sets de cambios?), Etiquetas y confirmaciones (similares a los parches?), Pero su distinción no es clara. ¿Qué files hacen qué modificar? ¿Qué hace que mis files se mantengan locales y qué podría (cielo no lo permita) enviar mi código a los internets?

¿Cuál es la forma recomendada de trabajar, cuando se trata de twigs, tags y compromisos, por lo que es fácil intercambiar versiones e importar actualizaciones de gits disponibles públicamente.

// T, mordiéndose la lengua para controlar su frustración …

Aquí hay un bash de completar su glosario (desde lo más alto de mi cabeza, tratando de usar mis propias palabras):

  • Repo, repository : esta es su database de objects donde se almacenó su historial y configuration. Puede contener varias twigs. A menudo también contiene un tree de trabajo.

  • un git, "el idiota": nunca he oído hablar, lo siento. "the git" probablemente describe el software en sí, pero no estoy seguro

  • index, staging area: es un "caching" entre tu worktree y tu repository. Puede agregar cambios al índice y crear su siguiente compromiso paso a paso. Cuando el contenido de su índice es de su agrado, puede crear un compromiso a partir de él. También se usa para mantener información durante las fusiones fallidas (su lado, su lado y estado actual)

  • clone: Un clon de un repository ("solo otro repository") o el acto de hacerlo ("para clonar un repository (crea un nuevo clon)")

  • commit: un estado de su proyecto en un momento determinado. Contiene un puntero a su confirmación primaria (en el caso de una fusión: múltiples padres) y un puntero a la estructura del directory en este punto en el time.

  • twig: una línea diferente de desarrollo. Una twig en git es solo una "label" que apunta a un compromiso. Puede get el historial completo a través de los pointers principales. Una twig por defecto es solo local para su repository.

  • tree: básicamente hablando un directory. Es solo una list de files (blobs) y subdirectorys (treees). (La list también puede contener confirmaciones en caso de que use submodules, pero ese es un tema avanzado)

  • upstream: después de clonar un repository, a menudo se llama a ese repository "original" "upstream". En git se alias al origin

  • a head: la confirmación superior de una twig (asigna los puntos a la label)

  • CABEZA: Un nombre simbólico para describir la confirmación actualmente desprotegida. A menudo, el compromiso más elevado

  • versión: podría ser lo mismo que un compromiso. También podría significar una versión lanzada de su proyecto.

  • label: un nombre descriptivo dado a uno de sus commits (o treees, o blobs). También puede contener un post (por ejemplo, changelog). Las tags se pueden firmar criptográficamente con GPG.

  • file: un file simple (.tar, .zip), nada especial wrt git.

  • parche: un compromiso exportado al formatting de text. Puede ser enviado por correo electrónico y aplicado por otros usuarios. Contiene el autor original, post de confirmación y diferencias de files

  • presentación: ninguna idea. ¿Enviar un parche a un proyecto tal vez?

  • changeset: sinónimo de "commit"

  • escondite: Git te permite "esconder" cambios. Esto le da un tree de trabajo limpio sin ningún cambio. Más tarde pueden ser "reventados" para ser devueltos. Esto puede ser un salvavidas si necesita trabajar temporalmente en un cambio no relacionado (por ejemplo, corrección de errores de time crítico)

  • object: puede ser uno de commit , tree , blob , tag . Un object ha asociado su hash SHA1 mediante el cual se hace reference (el commit con id deadbeaf , the tree decaf ). El hash es idéntico entre todos los repositorys que comparten el mismo object. También pone en peligro la integridad de un repository: no puede cambiar las confirmaciones pasadas sin cambiar los valores hash de todas las confirmaciones secundarias.

  • (module,) submodule: un repository incluido en otro repository (por ejemplo, biblioteca externa). Cosas avanzadas

  • revspec: una expresión revspec (o revparse) describe un cierto object git o un set de confirmaciones a través de lo que se llama la syntax SHA1 extendida (por ejemplo, HEAD , master~4^2 , origin/master..HEAD , deadbeaf^! … )

  • refspec: Un refspec es un patrón que describe el mapeo a realizar entre references remotas y locales durante las operaciones de búsqueda o de inserción

  • history: describe todos los commit de antepasados ​​antes de una confirmación que se remonta al primer commit.


Cosas que no mencionaste, pero que probablemente sea bueno saber:

Todo lo que haces es local para tu repository (ya sea creado por git init o git clone git://url.com/another/repo.git ). Hay solo unos pocos commands en git que interactúan con otros repositorys (también conocidos como interwebz), incluyendo clone , fetch , pull , push .

Push & Pull se utilizan para sincronizar repositorys. Extraiga los objects de fetch de otro repository y los fusione con su twig actual. Push se utiliza para tomar sus cambios y enviarlos a otro repository. No puede enviar confirmaciones o cambios únicos, solo puede enviar un compromiso que incluya su historial completo.

Un solo repository puede contener múltiples twigs pero no necesita hacerlo. La twig pnetworkingeterminada en git se llama master . Puedes crear tantas twigs como quieras, fusionar es pan comido con git. Las twigs son locales hasta que ejecute git push origin <branch> .

Un compromiso describe un estado completo del proyecto. Esos estados se pueden comparar entre sí, lo que produce un "diff" ( git diff origin/master master = ver diferencias entre origin/master y master )

Git es bastante poderoso cuando se trata de preparar tus compromisos. El ingnetworkingiente key aquí es el "índice" (o "área de preparación"). Puede agregar cambios individuales al índice (usando git add ) hasta que crea que el índice se ve bien. git commit activa su editor de text y necesita proporcionar un post de confirmación (por qué y cómo hizo ese cambio); después de ingresar su post de confirmación, git creará una nueva confirmación, que contiene el contenido del índice, además de la confirmación anterior (el puntero principal es el SHA1 de la confirmación anterior).

Git viene con documentation para exactamente lo que estás buscando.

 $ git help glossary 

Encontré este libro (gratuito) muy útil cuando aprendí a usar git: http://progit.org/ . El libro también existe en forma impresa.

Creo que la forma más rápida de aprender git es search un libro o tutorial que te enseñe los conceptos y términos básicos.

Otro buen recurso para aprender Git es la Inmersión Git de Edgecase. Tratar de aprender Git a través de las páginas man es probablemente muy difícil, hay una curva de aprendizaje corta y empinada que primero hay que superar. Primero debe conocer el concepto de DCVS (Sistema de control de versiones distribuidas).

Progit recomendado por @fulhack también es muy bueno.

También puedo recomendar encarecidamente Think Like A Git . La explicación de la rebase aquí vale su peso en oro.

Lo mejor que he encontrado para entender git es The Git Parable

Imagine que tiene una computadora que no tiene nada más que un editor de text y algunos commands del sistema de files. Ahora imagine que ha decidido escribir un gran progtwig de software en este sistema. Debido a que usted es un desarrollador de software responsable, decide que necesita devise algún tipo de método para realizar un seguimiento de las versiones de su software para que pueda recuperar el código que modificó o eliminó previamente. Lo que sigue es una historia sobre cómo diseñar uno de esos sistemas de control de versiones (VCS) y el razonamiento detrás de esas elecciones de layout …

Creo que le puede gustar este artículo: Git para informáticos

Y otro aspecto importante para entender cuando se usa git es el flujo de trabajo. Lee esta maravillosa publicación de blog: model de ramificación de Git