stringtranslate.com

Git

Git ( / ɡ ɪ t / ) [8] es un sistema de control de versiones distribuido [9] que rastrea las versiones de los archivos . Los programadores que desarrollan software de forma colaborativa suelen utilizarlo para controlar el código fuente .

Los objetivos de diseño de Git incluyen velocidad, integridad de datos y soporte para flujos de trabajo distribuidos y no lineales: miles de ramas paralelas que se ejecutan en diferentes computadoras. [10] [11] [12]

Git fue creado para su uso en el desarrollo del kernel de Linux por Linus Torvalds y otros desarrolladores del kernel. [13]

Al igual que con la mayoría de los otros sistemas de control de versiones distribuidos, y a diferencia de la mayoría de los sistemas cliente-servidor , Git mantiene una copia local de todo el repositorio , también conocido como repo, con capacidades de seguimiento de versiones e historial, independientemente del acceso a la red o un servidor central . Un repositorio se almacena en cada computadora en un directorio estándar con archivos ocultos adicionales para proporcionar capacidades de control de versiones. [14] Git proporciona características para sincronizar cambios entre repositorios que comparten historial; copiados (clonados) entre sí. Para la colaboración, Git admite la sincronización con repositorios en máquinas remotas . Aunque todos los repositorios (con el mismo historial) son pares, los desarrolladores a menudo usan un servidor central para alojar un repositorio para mantener una copia integrada.

Git es un software gratuito y de código abierto compartido bajo la licencia GPL-2.0 únicamente .

La marca "Git" está registrada por Software Freedom Conservancy , lo que marca su reconocimiento oficial y su evolución continua en la comunidad de código abierto .

En la actualidad, Git es el sistema de control de versiones estándar de facto . Es el sistema de control de versiones distribuido más popular, y casi el 95 % de los desarrolladores lo consideran su sistema de control de versiones principal en 2022. [15] Es la herramienta de gestión de código fuente más utilizada entre los desarrolladores profesionales. Existen ofertas de servicios de repositorio de Git, incluidos GitHub , SourceForge , Bitbucket y GitLab . [16] [17] [18] [19] [20]

Historia

Torvalds comenzó a desarrollar Git en abril de 2005 después de que la licencia libre de BitKeeper , el sistema propietario de gestión de control de fuente (SCM) utilizado para el desarrollo del kernel de Linux desde 2002, fuera revocada para Linux. [21] [22] El titular de los derechos de autor de BitKeeper, Larry McVoy , afirmó que Andrew Tridgell había creado SourcePuller mediante ingeniería inversa de los protocolos de BitKeeper . [23] El mismo incidente también estimuló la creación de Mercurial , otro sistema de control de versiones.

Torvalds quería un sistema distribuido que pudiera utilizar como BitKeeper, pero ninguno de los sistemas libres disponibles satisfacía sus necesidades. Citó un ejemplo de un sistema de gestión de control de código fuente que necesitaba 30 segundos para aplicar un parche y actualizar todos los metadatos asociados, y señaló que esto no sería escalable a las necesidades del desarrollo del núcleo Linux, donde la sincronización con otros mantenedores podría requerir 250 acciones de este tipo a la vez. Para su criterio de diseño, especificó que la aplicación del parche no debería tardar más de tres segundos, y agregó tres objetivos más: [10]

Estos criterios eliminaron todos los sistemas de control de versiones en uso en ese momento, por lo que inmediatamente después del lanzamiento del desarrollo del kernel de Linux 2.6.12-rc2, Torvalds se propuso escribir el suyo propio. [12]

El desarrollo de Git comenzó el 3 de abril de 2005. [24] Torvalds anunció el proyecto el 6 de abril y se convirtió en autohospedador al día siguiente. [24] [25] La primera fusión de múltiples ramas tuvo lugar el 18 de abril. [26] Torvalds logró sus objetivos de rendimiento; el 29 de abril, el naciente Git fue evaluado registrando parches en el árbol del núcleo de Linux a una velocidad de 6,7 parches por segundo. [27] El 16 de junio, Git logró el lanzamiento del núcleo 2.6.12. [28]

El 26 de julio de 2005, Torvalds entregó el mantenimiento a Junio ​​Hamano, uno de los principales colaboradores del proyecto. [29] Hamano fue responsable del lanzamiento de la versión 1.0 el 21 de diciembre de 2005. [30]

Nombramiento

Torvalds bromeó sarcásticamente sobre el nombre git (que significa "persona desagradable" en la jerga inglesa británica ): "Soy un bastardo egoísta y nombro a todos mis proyectos con mi nombre. Primero ' Linux ', ahora 'git'". [31] [32] La página del manual describe a Git como "el estúpido rastreador de contenido". [33]

El archivo read-me del código fuente explica con más detalle: [34]

"Git" puede significar cualquier cosa, dependiendo de tu estado de ánimo.

El código fuente de Git se refiere al programa como "el administrador de información del infierno".

Características

Diseño

El diseño de Git es una síntesis de la experiencia de Torvalds con Linux en el mantenimiento de un gran proyecto de desarrollo distribuido, junto con su profundo conocimiento del rendimiento del sistema de archivos obtenido en el mismo proyecto y la necesidad urgente de producir un sistema funcional en poco tiempo. Estas influencias llevaron a las siguientes opciones de implementación: [13]

Fuerte apoyo al desarrollo no lineal
Git admite la creación rápida de ramas y fusiones, e incluye herramientas específicas para visualizar y navegar por un historial de desarrollo no lineal. En Git, una suposición básica es que un cambio se fusionará con más frecuencia de la que se escribe, ya que se transmite a varios revisores. En Git, las ramas son muy ligeras: una rama es solo una referencia a una confirmación.
Desarrollo distribuido
Al igual que Darcs , BitKeeper , Mercurial , Bazaar y Monotone , Git proporciona a cada desarrollador una copia local del historial de desarrollo completo, y los cambios se copian de un repositorio a otro. Estos cambios se importan como ramas de desarrollo agregadas y se pueden fusionar de la misma manera que una rama desarrollada localmente. [35]
Compatibilidad con sistemas y protocolos existentes
Los repositorios se pueden publicar a través del Protocolo de transferencia de hipertexto seguro (HTTPS), el Protocolo de transferencia de hipertexto (HTTP), el Protocolo de transferencia de archivos (FTP) o un protocolo Git a través de un socket simple o Secure Shell (ssh). Git también tiene una emulación de servidor CVS, que permite el uso de clientes CVS existentes y complementos IDE para acceder a los repositorios Git. Los repositorios Subversion se pueden usar directamente con git-svn. [36]
Gestión eficiente de grandes proyectos
Torvalds ha descrito a Git como muy rápido y escalable, [37] y las pruebas de rendimiento realizadas por Mozilla [38] mostraron que era un orden de magnitud más rápido que Mercurial y GNU Bazaar al comparar repositorios grandes ; obtener el historial de versiones de un repositorio almacenado localmente puede ser cien veces más rápido que obtenerlo del servidor remoto. [39]
Autenticación criptográfica del historial
El historial de Git se almacena de tal manera que el ID de una versión en particular (un commit en términos de Git) depende del historial de desarrollo completo que condujo a ese commit. Una vez que se publica, no es posible cambiar las versiones anteriores sin que se note. La estructura es similar a un árbol de Merkle , pero con datos agregados en los nodos y las hojas. [40] ( Mercurial y Monotone también tienen esta propiedad).
Diseño basado en kits de herramientas
Git fue diseñado como un conjunto de programas escritos en C y varios scripts de shell que proporcionan envoltorios alrededor de esos programas. [41] Aunque la mayoría de esos scripts han sido reescritos desde entonces en C para mayor velocidad y portabilidad, el diseño permanece y es fácil encadenar los componentes. [42]
Estrategias de fusión conectables
Como parte del diseño de su conjunto de herramientas, Git tiene un modelo bien definido de una fusión incompleta y tiene múltiples algoritmos para completarla, culminando en informar al usuario que no puede completar la fusión automáticamente y que es necesaria una edición manual. [43]
La basura se acumula hasta que se recoge
La interrupción de operaciones o la reversión de cambios dejarán objetos sueltos e inútiles en la base de datos. Por lo general, estos son una pequeña fracción del historial de objetos deseados en constante crecimiento. Git realizará automáticamente la recolección de basura cuando se hayan creado suficientes objetos sueltos en el repositorio. La recolección de basura se puede llamar explícitamente usando git gc. [44] [45]
Empaquetado periódico explícito de objetos
Git almacena cada objeto recién creado como un archivo separado. Aunque se comprime individualmente, esto ocupa una gran cantidad de espacio y es ineficiente. Esto se soluciona mediante el uso de paquetes que almacenan una gran cantidad de objetos comprimidos en delta entre sí en un archivo (o flujo de bytes de red) llamado packfile . Los paquetes se comprimen utilizando la heurística de que los archivos con el mismo nombre probablemente sean similares, sin depender de esto para su corrección. Se crea un archivo de índice correspondiente para cada packfile, que indica el desplazamiento de cada objeto en el packfile. Los objetos recién creados (con el historial recién agregado) aún se almacenan como objetos individuales, y se necesita un reempaquetado periódico para mantener la eficiencia del espacio. El proceso de empaquetado del repositorio puede ser muy costoso computacionalmente. Al permitir que los objetos existan en el repositorio en un formato suelto pero generado rápidamente, Git permite que la costosa operación de empaquetado se posponga hasta más tarde, cuando el tiempo importa menos, por ejemplo, al final de una jornada laboral. Git realiza el reempaquetado periódico de forma automática, pero también es posible el reempaquetado manual con el git gccomando . [46] Para la integridad de los datos, tanto el archivo de paquete como su índice tienen una suma de comprobación SHA-1 [47] en su interior, y el nombre de archivo del archivo de paquete también contiene una suma de comprobación SHA-1. Para comprobar la integridad de un repositorio, ejecute el git fsckcomando. [48] [49]

Otra propiedad de Git es que captura instantáneas de los árboles de directorios de los archivos. Los primeros sistemas para rastrear versiones de código fuente, el Sistema de Control de Código Fuente (SCCS) y el Sistema de Control de Revisión (RCS), trabajaban en archivos individuales y enfatizaban el ahorro de espacio que se obtenía de las versiones (en su mayoría similares) con deltas intercalados (SCCS) o codificación delta (RCS). Los sistemas de control de revisión posteriores mantuvieron esta noción de que un archivo tiene una identidad a lo largo de múltiples revisiones de un proyecto. Sin embargo, Torvalds rechazó este concepto. [50] En consecuencia, Git no registra explícitamente las relaciones de revisión de archivos en ningún nivel por debajo del árbol de código fuente.

Desventajas

Estas relaciones de revisión implícitas tienen algunas consecuencias importantes:

Estrategias de fusión

Git implementa varias estrategias de fusión; se puede seleccionar una estrategia no predeterminada en el momento de la fusión: [56]

Estructuras de datos

Las primitivas de Git no son inherentemente un sistema de gestión de código fuente . Torvalds explica: [58]

En muchos sentidos, puedes ver a Git simplemente como un sistema de archivos: es direccionable por contenido y tiene una noción de control de versiones, pero realmente lo diseñé abordando el problema desde el punto de vista de una persona de sistemas de archivos (hey, los kernels son lo que hago) y, en realidad, no tengo absolutamente ningún interés en crear un sistema SCM tradicional.

A partir de este enfoque de diseño inicial, Git ha desarrollado el conjunto completo de características esperadas de un SCM tradicional, [59] con características que se crean principalmente según sea necesario y luego se perfeccionan y amplían con el tiempo.

Algunos flujos de datos y niveles de almacenamiento en el sistema de control de revisiones de Git

Git tiene dos estructuras de datos : un índice mutable (también llamado etapa o caché ) que almacena en caché información sobre el directorio de trabajo y la próxima revisión que se confirmará; y una base de datos de objetos que almacena objetos inmutables.

El índice sirve como punto de conexión entre la base de datos de objetos y el árbol de trabajo.

El almacén de objetos contiene cinco tipos de objetos: [60] [48]

Cada objeto se identifica mediante un hash SHA-1 de su contenido. Git calcula el hash y utiliza este valor para el nombre del objeto. El objeto se coloca en un directorio que coincide con los dos primeros caracteres de su hash. El resto del hash se utiliza como nombre de archivo para ese objeto.

Git almacena cada revisión de un archivo como un blob único. Las relaciones entre los blobs se pueden encontrar examinando el árbol y los objetos de confirmación. Los objetos recién agregados se almacenan en su totalidad mediante la compresión zlib. Esto puede consumir una gran cantidad de espacio en disco rápidamente, por lo que los objetos se pueden combinar en paquetes , que utilizan la compresión delta para ahorrar espacio y almacenan los blobs como sus cambios en relación con otros blobs.

Además, Git almacena etiquetas llamadas refs (abreviatura de referencias) para indicar las ubicaciones de varias confirmaciones. Se almacenan en la base de datos de referencia y son respectivamente: [66]

Comandos

Los comandos utilizados con frecuencia para la interfaz de línea de comandos de Git incluyen: [67] [68]

Se puede crear un archivo .gitignore en un repositorio Git como un archivo de texto sin formato. Git no rastreará los archivos enumerados en el archivo .gitignore . [69] : 3–4  Esta función se puede utilizar para ignorar archivos con claves o contraseñas, varios archivos extraños y archivos grandes (que GitHub se negará a cargar). [70]

Referencias de Git

Todos los objetos de la base de datos de Git a los que no se hace referencia pueden limpiarse mediante un comando de recolección de basura o de forma automática. Un objeto puede ser referenciado por otro objeto o por una referencia explícita. Git tiene diferentes tipos de referencias. Los comandos para crear, mover y eliminar referencias varían. git show-refenumera todas las referencias. Algunos tipos son:

Implementaciones

gitg es una interfaz gráfica que utiliza GTK+ .

Git (la implementación principal en C) se desarrolla principalmente en Linux , aunque también es compatible con la mayoría de los sistemas operativos principales, incluidos los BSD ( DragonFly BSD , FreeBSD , NetBSD y OpenBSD ), Solaris , macOS y Windows . [72] [73]

El primer puerto de Windows de Git fue principalmente un marco de emulación de Linux que aloja la versión de Linux. Instalar Git bajo Windows crea un directorio de Archivos de programa con un nombre similar que contiene el puerto Mingw-w64 de la Colección de compiladores GNU , Perl 5, MSYS2 (en sí mismo una bifurcación de Cygwin , un entorno de emulación similar a Unix para Windows) y varios otros puertos de Windows o emulaciones de utilidades y bibliotecas de Linux. Actualmente, las compilaciones nativas de Windows de Git se distribuyen como instaladores de 32 y 64 bits. [74] El sitio web oficial de Git actualmente mantiene una compilación de Git para Windows, que aún usa el entorno MSYS2. [75]

La implementación de Git en JGit es una biblioteca de software Java pura , diseñada para ser incorporada en cualquier aplicación Java. JGit se utiliza en la herramienta de revisión de código Gerrit y en EGit, un cliente Git para el IDE Eclipse . [76]

Go-git es una implementación de código abierto de Git escrita en Go puro . [77] Actualmente se utiliza para respaldar proyectos como una interfaz SQL para repositorios de código Git [78] y para proporcionar cifrado para Git. [79]

Dulwich es una implementación de Git escrita en Python puro con soporte para CPython 3.6 y posteriores y Pypy. [80]

La implementación libgit2 de Git es una biblioteca de software ANSI C sin otras dependencias, que se puede crear en múltiples plataformas, incluidas Windows, Linux, macOS y BSD. [81] Tiene enlaces para muchos lenguajes de programación, incluidos Ruby , Python y Haskell . [82] [83] [84]

JS-Git es una implementación en JavaScript de un subconjunto de Git. [85]

GameOfTrees es una implementación de código abierto de Git para el proyecto OpenBSD. [86]

Servidor Git

Captura de pantalla de la interfaz de Gitweb que muestra una diferencia de confirmación

Como Git es un sistema de control de versiones distribuido, se puede utilizar como servidor de forma inmediata. Se envía con un comando integrado git daemonque inicia un servidor TCP simple que se ejecuta en el protocolo Git. [87] [88] Los servidores HTTP de Git dedicados ayudan (entre otras características) agregando control de acceso, mostrando el contenido de un repositorio de Git a través de las interfaces web y administrando múltiples repositorios. Los repositorios de Git ya existentes se pueden clonar y compartir para que otros los usen como un repositorio centralizado. También se puede acceder a ellos a través de un shell remoto simplemente teniendo el software de Git instalado y permitiendo que un usuario inicie sesión. [89] Los servidores de Git generalmente escuchan en el puerto TCP 9418. [90]

Código abierto

Servidor Git como servicio

Existen muchas ofertas de repositorios Git como servicio. Los más populares son GitHub , SourceForge , Bitbucket y GitLab . [95] [17] [18] [19] [20]

Interfaces gráficas

Git, un potente sistema de control de versiones, puede resultar abrumador con su interfaz de línea de comandos. Los clientes GUI de Git ofrecen una interfaz gráfica de usuario (GUI) para simplificar la interacción con los repositorios de Git.

Estas GUI brindan representaciones visuales del historial de su proyecto, incluidas las ramas, las confirmaciones y los cambios de archivos. También agilizan acciones como preparar cambios, crear confirmaciones y administrar ramas. Las herramientas de comparación visual ayudan a resolver conflictos de fusión que surgen del desarrollo simultáneo.

Git viene con una GUI Tcl/Tk , que permite a los usuarios realizar acciones como crear y modificar confirmaciones, crear y fusionar ramas e interactuar con repositorios remotos. [96]

Además de la GUI oficial, existen muchas interfaces de terceros que proporcionan características similares a la GUI oficial distribuida con Git, como GitHub Desktop, SourceTree y TortoiseGit. [97]

Los clientes GUI hacen que Git sea más fácil de aprender y usar, lo que mejora la eficiencia del flujo de trabajo y reduce los errores. Las opciones más populares incluyen GitKraken Desktop (freemium) y Sourcetree (gratis/pago) multiplataforma, u opciones específicas de la plataforma como GitHub Desktop (gratis) para Windows/macOS y TortoiseGit (gratis) para Windows.

Lista de clientes GUI

Si bien Git proporciona herramientas GUI integradas (git-gui, gitk), una gama más amplia de opciones de terceros satisfacen las preferencias del usuario específicas de la plataforma.

GUI de Windows (GNU GPL/MIT y gratuitas)

GUI para Mac (GNU GPL/MIT y gratuitas)

GUI de Linux (GNU GPL/MIT y gratuitas)

Interfaz gráfica de usuario GIT propietaria

Adopción

La Fundación Eclipse informó en su encuesta comunitaria anual que, a partir de mayo de 2014, Git es ahora la herramienta de gestión de código fuente más utilizada, con un 42,9% de desarrolladores de software profesionales que informan que utilizan Git como su sistema principal de control de código fuente [98] en comparación con el 36,3% en 2013, el 32% en 2012; o para las respuestas de Git excluyendo el uso de GitHub : 33,3% en 2014, 30,3% en 2013, 27,6% en 2012 y 12,8% en 2011. [99] El directorio de código abierto Black Duck Open Hub informa una aceptación similar entre los proyectos de código abierto. [100]

Stack Overflow ha incluido el control de versiones en su encuesta anual para desarrolladores [101] en 2015 (16.694 respuestas), [102] 2017 (30.730 respuestas), [103] 2018 (74.298 respuestas) [104] y 2022 (71.379 respuestas). [15] Git fue el gran favorito de los desarrolladores que respondieron a estas encuestas, con un 93,9 % en 2022.

Sistemas de control de versiones utilizados por los desarrolladores que respondieron:

El sitio web de empleos de TI del Reino Unido itjobswatch.co.uk informa que a fines de septiembre de 2016, el 29,27 % de las ofertas de trabajo permanentes de desarrollo de software del Reino Unido han citado Git, [105] por delante del 12,17 % para Microsoft Team Foundation Server , [106] el 10,60 % para Subversion , [107] el 1,30 % para Mercurial , [108] y el 0,48 % para Visual SourceSafe . [109]

Extensiones

Existen muchas extensiones de Git , como Git LFS, que comenzó como una extensión de Git en la comunidad de GitHub y ahora es ampliamente utilizada por otros repositorios. Las extensiones suelen ser desarrolladas y mantenidas de forma independiente por diferentes personas, pero en algún momento en el futuro, una extensión ampliamente utilizada puede fusionarse con Git.

Otras extensiones de Git de código abierto incluyen:

Microsoft desarrolló la extensión Virtual File System for Git (VFS for Git; anteriormente Git Virtual File System o GVFS) para manejar el tamaño del árbol de código fuente de Windows como parte de su migración de 2017 desde Perforce . VFS for Git permite que los repositorios clonados utilicen marcadores de posición cuyo contenido se descarga solo una vez que se accede a un archivo. [110]

Convenciones

Git se puede utilizar de distintas maneras, pero algunas convenciones se adoptan comúnmente.

Seguridad

Git no proporciona mecanismos de control de acceso, pero fue diseñado para funcionar con otras herramientas que se especializan en el control de acceso. [120]

El 17 de diciembre de 2014, se encontró un exploit que afectaba a las versiones de Windows y macOS del cliente Git. Un atacante podría ejecutar código arbitrario en un equipo de destino con Git instalado creando un árbol Git malicioso (directorio) llamado .git (un directorio en los repositorios Git que almacena todos los datos del repositorio) en un caso diferente (como .GIT o .Git, necesario porque Git no permite que la versión en minúsculas de .git se cree manualmente) con archivos maliciosos en el subdirectorio .git/hooks (una carpeta con archivos ejecutables que ejecuta Git) en un repositorio que el atacante creó o en un repositorio que el atacante puede modificar. Si un usuario de Windows o Mac descarga una versión del repositorio con el directorio malicioso y luego cambia a ese directorio, el directorio .git se sobrescribirá (debido a la característica de no distinguir entre mayúsculas y minúsculas de los sistemas de archivos de Windows y Mac) y los archivos ejecutables maliciosos en .git/hooks pueden ejecutarse, lo que hace que se ejecuten los comandos del atacante. Un atacante también podría modificar el archivo de configuración .git/config , lo que le permite crear alias maliciosos de Git (alias para comandos de Git o comandos externos) o modificar alias existentes para ejecutar comandos maliciosos cuando se ejecutan. La vulnerabilidad fue parcheada en la versión 2.2.1 de Git, lanzada el 17 de diciembre de 2014, y anunciada al día siguiente. [121] [122]

La versión 2.6.1 de Git, publicada el 29 de septiembre de 2015, contenía un parche para una vulnerabilidad de seguridad (CVE-2015-7545) [123] que permitía la ejecución de código arbitrario. [124] La vulnerabilidad era explotable si un atacante podía convencer a una víctima de clonar una URL específica, ya que los comandos arbitrarios estaban incrustados en la propia URL. [125] Un atacante podía utilizar la vulnerabilidad a través de un ataque de intermediario si la conexión no estaba cifrada, [125] ya que podía redirigir al usuario a una URL de su elección. Los clones recursivos también eran vulnerables ya que permitían al controlador de un repositorio especificar URL arbitrarias a través del archivo gitmodules. [125]

Git utiliza hashes SHA-1 internamente. Linus Torvalds ha respondido que el hash era principalmente para protegerse contra la corrupción accidental, y la seguridad que brinda un hash criptográficamente seguro era solo un efecto secundario accidental, ya que la seguridad principal era firmar en otro lugar. [126] [127] Desde una demostración del ataque SHAttered contra Git en 2017, Git se modificó para usar una variante SHA-1 resistente a este ataque. Desde febrero de 2020 se está escribiendo un plan para la transición de la función hash. [128]

Marca

"Git" es una marca registrada de Software Freedom Conservancy bajo el número US500000085961336 desde el 2015-02-03.

Véase también

Notas

  1. ^ Solo GPL-2.0 desde el 11 de abril de 2005. Algunas partes están sujetas a licencias compatibles, como LGPLv2.1 . [6]
  2. ^ abcdefghijklmnopqrs No aparece como opción en esta encuesta

Citas

  1. ^ «Revisión inicial de «git», el gestor de información del infierno». GitHub . 8 de abril de 2005. Archivado desde el original el 16 de noviembre de 2015 . Consultado el 20 de diciembre de 2015 .
  2. ^ "Gráfico de confirmaciones". GitHub . 8 de junio de 2016. Archivado desde el original el 20 de enero de 2016 . Consultado el 19 de diciembre de 2015 .
  3. ^ Junio ​​C Hamano (7 de octubre de 2024). "[ANUNCIO] Git v2.47.0" . Consultado el 8 de octubre de 2024 .
  4. ^ "Sitio web de Git". Archivado desde el original el 9 de junio de 2022 . Consultado el 9 de junio de 2022 .
  5. ^ "Espejo de código fuente de Git". GitHub . Archivado desde el original el 3 de junio de 2022 . Consultado el 9 de junio de 2022 .
  6. ^ "Licencia LGPL de Git en github.com". GitHub . 20 de mayo de 2011. Archivado desde el original el 11 de abril de 2016 . Consultado el 12 de octubre de 2014 .
  7. ^ "Licencia GPL de Git en github.com". GitHub . 18 de enero de 2010. Archivado desde el original el 11 de abril de 2016 . Consultado el 12 de octubre de 2014 .
  8. ^ "Tech Talk: Linus Torvalds on git (at 00:01:30)". 14 de mayo de 2007. Archivado desde el original el 20 de diciembre de 2015. Consultado el 20 de julio de 2014 en YouTube.
  9. ^ Chacon y Straub 2014, págs. 29–31.
  10. ^ ab Torvalds, Linus (7 de abril de 2005). "Re: Kernel SCM saga..." linux-kernel (Lista de correo). Archivado desde el original el 1 de julio de 2019 . Consultado el 3 de febrero de 2017 ."Estoy escribiendo algunos scripts para intentar rastrear las cosas mucho más rápido".
  11. ^ ab Torvalds, Linus (10 de junio de 2007). "Re: fatal: grave inconsistencia en la inflación". git (lista de correo).
  12. ^ abcd Linus Torvalds (3 de mayo de 2007). Google tech talk: Linus Torvalds on git. El evento ocurre a las 02:30. Archivado desde el original el 28 de mayo de 2007. Consultado el 16 de mayo de 2007 .
  13. ^ ab "Una breve historia de Git". Pro Git (2.ª ed.). Apress. 2014. Archivado desde el original el 25 de diciembre de 2015 . Consultado el 26 de diciembre de 2015 .
  14. ^ Chacón, Scott (24 de diciembre de 2014). Pro Git (2ª ed.). Nueva York, Nueva York: Apress . págs. 29 y 30. ISBN 978-1-4842-0077-3Archivado desde el original el 25 de diciembre de 2015.
  15. ^ ab "Encuesta para desarrolladores de Stack Overflow 2022". Stack Overflow . Consultado el 4 de agosto de 2022 .
  16. ^ Krill, Paul (28 de septiembre de 2016). "Guerras de repositorios empresariales: GitHub vs. GitLab vs. Bitbucket". InfoWorld . Consultado el 2 de febrero de 2020 .
  17. ^ ab "github.com Análisis competitivo, combinación de marketing y tráfico". Alexa . Archivado desde el original el 31 de marzo de 2013 . Consultado el 2 de febrero de 2020 .
  18. ^ ab "sourceforge.net Análisis competitivo, combinación de marketing y tráfico". Alexa . Archivado desde el original el 20 de octubre de 2020 . Consultado el 2 de febrero de 2020 .
  19. ^ ab "bitbucket.org Análisis competitivo, combinación de marketing y tráfico". Alexa . Archivado desde el original el 23 de junio de 2017 . Consultado el 2 de febrero de 2020 .
  20. ^ ab "gitlab.com Análisis competitivo, combinación de marketing y tráfico". Alexa . Archivado desde el original el 30 de noviembre de 2017 . Consultado el 2 de febrero de 2020 .
  21. ^ Brown, Zack (27 de julio de 2018). "Una historia sobre el origen de Git". Linux Journal . Linux Journal. Archivado desde el original el 13 de abril de 2020 . Consultado el 28 de mayo de 2020 .
  22. ^ "BitKeeper y Linux: ¿el final del camino?". Linux.com . 11 de abril de 2005. Consultado el 18 de mayo de 2023 .
  23. ^ McAllister, Neil (2 de mayo de 2005). «El error de Linus Torvalds con BitKeeper». InfoWorld . Archivado desde el original el 26 de agosto de 2015. Consultado el 8 de septiembre de 2015 .
  24. ^ ab Torvalds, Linus (27 de febrero de 2007). "Re: Trivia: ¿Cuándo se autoalojó Git?". git (Lista de correo).
  25. ^ Torvalds, Linus (6 de abril de 2005). "La saga Kernel SCM". kernel-linux (lista de correo).
  26. ^ Torvalds, Linus (17 de abril de 2005). "¡La primera fusión real de núcleos con Git!". git (Lista de correo).
  27. ^ Mackall, Matt (29 de abril de 2005). "Evaluación comparativa de Mercurial 0.4b vs git patchbomb". git (lista de correo).
  28. ^ Torvalds, Linus (17 de junio de 2005). "Linux 2.6.12". git-commits-head (Lista de correo).
  29. ^ Torvalds, Linus (27 de julio de 2005). "Conozca al nuevo mantenedor". git (lista de correo).
  30. ^ Hamano, Junio ​​C. (21 de diciembre de 2005). "Anuncio: Git 1.0.0". git (lista de correo).
  31. ^ "GitFaq: ¿Por qué el nombre 'Git'?". Git.or.cz. Archivado desde el original el 23 de julio de 2012. Consultado el 14 de julio de 2012 .
  32. ^ "Tras la polémica, Torvalds empieza a trabajar en 'git'". PC World . 14 de julio de 2012. Archivado desde el original el 1 de febrero de 2011. Torvalds parecía consciente de que su decisión de abandonar BitKeeper también sería polémica. Cuando se le preguntó por qué llamaba al nuevo software 'git', una expresión del argot británico que significa 'una persona podrida', dijo: 'Soy un bastardo egoísta, así que nombro a todos mis proyectos con mi nombre. Primero Linux, ahora git'.
  33. ^ "Página del manual de git(1)". Archivado desde el original el 21 de junio de 2012 . Consultado el 21 de julio de 2012 .
  34. ^ "Revisión inicial de 'git', el gestor de información del infierno · git/git@e83c516". GitHub . Archivado desde el original el 8 de octubre de 2017 . Consultado el 21 de enero de 2016 .
  35. ^ "Git – Flujos de trabajo distribuidos". Git . Archivado desde el original el 22 de octubre de 2014 . Consultado el 15 de junio de 2020 .
  36. ^ Gunjal, Siddhesh (19 de julio de 2019). "¿Qué es la herramienta de control de versiones? Explora Git y GitHub". Medium . Consultado el 25 de octubre de 2020 .
  37. ^ Torvalds, Linus (19 de octubre de 2006). "Re: Tabla de comparación de VCS". git (Lista de correo).
  38. ^ Blog de Jst en Mozillazine «rendimiento de bzr/hg/git». Archivado desde el original el 29 de mayo de 2010. Consultado el 12 de febrero de 2015 .
  39. ^ Dreier, Roland (13 de noviembre de 2006). "Oh, qué alivio". Archivado desde el original el 16 de enero de 2009., observando que "git log" es 100 veces más rápido que "svn log" porque este último debe contactar un servidor remoto.
  40. ^ "Confianza". Conceptos de Git . Manual del usuario de Git. 18 de octubre de 2006. Archivado desde el original el 22 de febrero de 2017.
  41. ^ Torvalds, Linus. "Re: Tabla de comparación de VCS". git (Lista de correo) . Consultado el 10 de abril de 2009 ., que describe el diseño orientado a scripts de Git
  42. ^ iabervon (22 de diciembre de 2005). "Git rocks!". Archivado desde el original el 14 de septiembre de 2016., elogiando la capacidad de creación de scripts de Git.
  43. ^ "Git – Wiki de Git SCM". git.wiki.kernel.org . Consultado el 25 de octubre de 2020 .
  44. ^ Chacón y Straub 2014.
  45. ^ "Manual del usuario de Git". 10 de marzo de 2020. Archivado desde el original el 10 de mayo de 2020.
  46. ^ Chacon y Straub 2014, pág. 499.
  47. ^ Chacon y Straub 2014, págs. 33–34.
  48. ^ ab "Git – Archivos de paquetes". Git .
  49. ^ Chacon y Straub 2014, pág. 568.
  50. ^ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de Git". linux-kernel (Lista de correo).
  51. ^ Haible, Bruno (11 de febrero de 2007). "¿Cómo acelerar 'git log'?". git (Lista de correo).
  52. ^ Torvalds, Linus (1 de marzo de 2006). "Re: cambios de nombre impuros / seguimiento del historial". git (lista de correo).
  53. ^ Hamano, Junio ​​C. (24 de marzo de 2006). "Re: Errores al gitificar GCC y Binutils". git (Lista de correo).
  54. ^ Hamano, Junio ​​C. (23 de marzo de 2006). "Re: Errores al gitificar GCC y Binutils". git (Lista de correo).
  55. ^ Torvalds, Linus (28 de noviembre de 2006). "Re: git y bzr". git (Lista de correo)., sobre el uso git-blamepara mostrar el código movido entre archivos fuente.
  56. ^ Torvalds, Linus (18 de julio de 2007). «git-merge(1)». Archivado desde el original el 16 de julio de 2016.
  57. ^ Torvalds, Linus (18 de julio de 2007). «CrissCrossMerge». Archivado desde el original el 13 de enero de 2006.
  58. ^ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de Git..." linux-kernel (Lista de correo).
  59. ^ Torvalds, Linus (23 de marzo de 2006). "Re: Errores al gitificar GCC y Binutils". git (Lista de correo). Archivado desde el original el 22 de marzo de 2021 . Consultado el 3 de febrero de 2017 .
  60. ^ "Git – Objetos Git". Git .
  61. ^ ab Chacon & Straub 2014, págs. 81–83.
  62. ^ Chacon y Straub 2014, págs. 485–488.
  63. ^ Chacon y Straub 2014, págs. 488–490.
  64. ^ Chacon y Straub 2014, págs. 495–496.
  65. ^ Chacon y Straub 2014, págs. 497–501.
  66. ^ "Git – Referencias de Git". Git .
  67. ^ "Hoja de trucos de Git" (PDF) . education.github.com . Consultado el 10 de junio de 2024 .
  68. ^ "Tutorial de Git" (PDF) . web.stanford.edu . Consultado el 10 de junio de 2024 .
  69. ^ "Introducción rápida a Git" (PDF) . data-skills.github.io . Consultado el 10 de junio de 2024 .
  70. ^ Ba Tran, Andrew. "Mejores prácticas para subir material a GitHub" (PDF) . journalismcourses.org . Consultado el 10 de junio de 2024 .
  71. ^ "Formato de archivo de configuración del proyecto". Gerrit Code Review . Archivado desde el original el 3 de diciembre de 2020. Consultado el 2 de febrero de 2020 .
  72. ^ "Descargas". Archivado desde el original el 8 de mayo de 2012 . Consultado el 14 de mayo de 2012 .
  73. ^ "versiones de paquetes git – Repology". Archivado desde el original el 19 de enero de 2022 . Consultado el 30 de noviembre de 2021 .
  74. ^ "msysGit". GitHub . Archivado desde el original el 10 de octubre de 2016 . Consultado el 20 de septiembre de 2016 .
  75. ^ "Git – Descargando paquete". Git .(código fuente)
  76. ^ "JGit". Archivado desde el original el 31 de agosto de 2012 . Consultado el 24 de agosto de 2012 .
  77. ^ "Git – go-git". Git . Consultado el 19 de abril de 2019 .
  78. ^ "Interfaz SQL para repositorios Git, escrita en Go.", github.com , consultado el 19 de abril de 2019
  79. ^ "Keybase lanza Git encriptado". keybase.io . Consultado el 19 de abril de 2019 .
  80. ^ "Repositorio de GitHub de Dulwich README.md". GitHub . Archivado desde el original el 29 de abril de 2024 . Consultado el 29 de abril de 2024 .
  81. ^ "libgit2". GitHub . Archivado desde el original el 11 de abril de 2016 . Consultado el 24 de agosto de 2012 .
  82. ^ "rugged". GitHub . Archivado desde el original el 24 de julio de 2013 . Consultado el 24 de agosto de 2012 .
  83. ^ "pygit2". GitHub . Archivado desde el original el 5 de agosto de 2015 . Consultado el 24 de agosto de 2012 .
  84. ^ "hlibgit2". Archivado desde el original el 25 de mayo de 2013. Consultado el 30 de abril de 2013 .
  85. ^ "js-git: una implementación de Git en JavaScript". GitHub . Archivado desde el original el 7 de agosto de 2013 . Consultado el 13 de agosto de 2013 .
  86. ^ "Juego de árboles". gameoftrees.org . Consultado el 10 de marzo de 2024 .
  87. ^ Chacon y Straub 2014, págs. 138-139.
  88. ^ "Git – Git Daemon". Git . Consultado el 10 de julio de 2019 .
  89. ^ 4.4 Git en el servidor: configuración del servidor Archivado el 22 de octubre de 2014 en Wayback Machine , Pro Git.
  90. ^ "1.4 Primeros pasos: instalación de Git". Git. Archivado desde el original el 2 de noviembre de 2013. Consultado el 1 de noviembre de 2013 .
  91. ^ Chacon, Scott; Straub, Ben (2014). "Git en el servidor: configuración del servidor". Pro Git (2.ª ed.). Apress. ISBN 978-1484200773.
  92. ^ Guía del usuario de Diffusion: alojamiento de repositorios Archivado el 20 de septiembre de 2020 en Wayback Machine .
  93. ^ "Gitolite: alojamiento de repositorios Git".
  94. ^ "Gogs: un servicio Git autohospedado y sin complicaciones".
  95. ^ "Lo más destacado de Git 2.26". El blog de GitHub . 22 de marzo de 2020. Archivado del original el 22 de marzo de 2021 . Consultado el 25 de noviembre de 2020 . Es posible que recuerdes cuando Git presentó una nueva versión de su protocolo de búsqueda de red en 2018. Ese protocolo ahora se usa de forma predeterminada en 2.26, así que refresquemos nuestros conocimientos sobre lo que eso significa. El mayor problema con el protocolo anterior es que el servidor enumeraba inmediatamente todas las ramas, etiquetas y otras referencias en el repositorio antes de que el cliente tuviera la oportunidad de enviar algo. Para algunos repositorios, esto podría significar enviar megabytes de datos adicionales, cuando el cliente realmente solo quería saber sobre la rama maestra. El nuevo protocolo comienza con la solicitud del cliente y proporciona una forma para que el cliente le diga al servidor en qué referencias está interesado. Obtener una sola rama solo preguntará sobre esa rama, mientras que la mayoría de los clones solo preguntarán sobre ramas y etiquetas. Esto puede parecer todo, pero los repositorios de servidores pueden almacenar otras referencias (como el encabezado de cada solicitud de extracción abierta en el repositorio desde su creación). Ahora, las recuperaciones de repositorios grandes mejoran en velocidad, especialmente cuando la recuperación en sí es pequeña, lo que hace que el costo del anuncio de referencia inicial sea más caro en términos relativos. ¡Y la mejor parte es que no necesitará hacer nada! Debido a un diseño inteligente, cualquier cliente que hable el nuevo protocolo puede funcionar sin problemas con servidores antiguos y nuevos, volviendo al protocolo original si el servidor no lo admite. La única razón para la demora entre la introducción del protocolo y su conversión en predeterminado fue permitir que los primeros usuarios descubrieran cualquier error.
  96. ^ "Git - Documentación de git-gui". Git . Consultado el 1 de julio de 2024 .
  97. ^ "Git - Clientes GUI". Git . Consultado el 1 de julio de 2024 .
  98. ^ "Resultados de la encuesta sobre la comunidad Eclipse 2014 | Ian Skerrett". Ianskerrett.wordpress.com. 23 de junio de 2014. Archivado desde el original el 25 de junio de 2014 . Consultado el 23 de junio de 2014 .
  99. ^ "Resultados de la encuesta comunitaria Eclipse 2012". eclipse.org. Archivado desde el original el 11 de abril de 2016.
  100. ^ "Comparación de repositorios – Open Hub". Archivado desde el original el 7 de septiembre de 2014.
  101. ^ "Encuesta anual para desarrolladores de Stack Overflow". Stack Exchange, Inc. Consultado el 9 de enero de 2020. La encuesta anual para desarrolladores de Stack Overflow es la encuesta más grande y completa de personas que programan en todo el mundo. Cada año, realizamos una encuesta que abarca todo, desde las tecnologías favoritas de los desarrolladores hasta sus preferencias laborales. Este año es el noveno año en que publicamos los resultados de nuestra encuesta anual para desarrolladores, y casi 90 000 desarrolladores respondieron la encuesta de 20 minutos a principios de este año.
  102. ^ "Encuesta para desarrolladores de Stack Overflow 2015". Stack Overflow. Archivado desde el original el 4 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  103. ^ "Encuesta para desarrolladores de Stack Overflow 2017". Stack Overflow. Archivado desde el original el 29 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  104. ^ "Encuesta para desarrolladores de Stack Overflow 2018". Stack Overflow. Archivado desde el original el 30 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  105. ^ "Puestos de trabajo en Git (software), salario medio para los profesionales que trabajan en sistemas de control de versiones distribuidos de Git". Itjobswatch.co.uk. Archivado desde el original el 8 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  106. ^ "Puestos de trabajo en Team Foundation Server, salario medio para las habilidades de Microsoft Team Foundation Server (TFS)". Itjobswatch.co.uk. Archivado desde el original el 29 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  107. ^ "Puestos de trabajo en Subversion, salario medio para las habilidades de Apache Subversion (SVN)". Itjobswatch.co.uk. Archivado desde el original el 25 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  108. ^ "Mercurial Jobs, Average Salary for Mercurial Skills". Itjobswatch.co.uk. Archivado desde el original el 23 de septiembre de 2016. Consultado el 30 de septiembre de 2016 .
  109. ^ "Puestos de trabajo en VSS/SourceSafe, salario medio para las habilidades en Microsoft Visual SourceSafe (VSS)". Itjobswatch.co.uk. Archivado desde el original el 29 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  110. ^ "El cambio de Windows a Git está casi completo: 8500 confirmaciones y 1760 compilaciones cada día". Ars Technica . 24 de mayo de 2017. Archivado desde el original el 24 de mayo de 2017 . Consultado el 24 de mayo de 2017 .
  111. ^ "git-init". Git . Archivado desde el original el 15 de marzo de 2022.
  112. ^ "Git – Branches in a Nutshell". Git . Archivado del original el 20 de diciembre de 2020 . Consultado el 15 de junio de 2020 . La rama "master" en Git no es una rama especial. Es exactamente como cualquier otra rama. La única razón por la que casi todos los repositorios tienen una es que el comando git init la crea de forma predeterminada y la mayoría de las personas no se molestan en cambiarla.
  113. ^ Chacon y Straub 2014, págs. 103–109.
  114. ^ github/renaming, GitHub, 4 de diciembre de 2020 , consultado el 4 de diciembre de 2020
  115. ^ El nombre de la rama predeterminada para los nuevos repositorios ahora es principal, GitLab, 22 de junio de 2021 , consultado el 22 de junio de 2021
  116. ^ "Git Revert | Tutorial de Git de Atlassian". Atlassian . Revertir tiene dos ventajas importantes sobre restablecer. Primero, no cambia el historial del proyecto, lo que lo convierte en una operación "segura" para las confirmaciones que ya se han publicado en un repositorio compartido.
  117. ^ "Flujo de trabajo de Gitflow | Tutorial de Git de Atlassian". Atlassian . Consultado el 15 de junio de 2020 .
  118. ^ Chacon y Straub 2014, págs. 170–174.
  119. ^ "Flujo de trabajo de bifurcación | Tutorial de Git de Atlassian". Atlassian . Consultado el 15 de junio de 2020 .
  120. ^ "Control de acceso al repositorio Git". Archivado desde el original el 14 de septiembre de 2016 . Consultado el 6 de septiembre de 2016 .
  121. ^ Pettersen, Tim (20 de diciembre de 2014). "Securing your Git server against CVE-2014-9390". Archivado desde el original el 24 de diciembre de 2014 . Consultado el 22 de diciembre de 2014 .
  122. ^ Hamano, JC (18 de diciembre de 2014). «[Anuncio] Git v2.2.1 (y actualizaciones de las líneas de mantenimiento anteriores)». Grupo de noticias : gmane.linux.kernel. Archivado desde el original el 19 de diciembre de 2014. Consultado el 22 de diciembre de 2014 .
  123. ^ «CVE-2015-7545». 15 de diciembre de 2015. Archivado desde el original el 26 de diciembre de 2015. Consultado el 26 de diciembre de 2015 .
  124. ^ "Git 2.6.1". GitHub . 29 de septiembre de 2015. Archivado desde el original el 11 de abril de 2016 . Consultado el 26 de diciembre de 2015 .
  125. ^ abc Blake Burkhart; et al. (5 de octubre de 2015). «Re: Solicitud CVE: git». Archivado desde el original el 27 de diciembre de 2015 . Consultado el 26 de diciembre de 2015 .
  126. ^ "hash – ¿Qué tan seguras son las etiquetas git firmadas? ¿Solo tan seguras como SHA-1 o de alguna manera más seguras?". Stack Exchange de seguridad de la información. 22 de septiembre de 2014. Archivado desde el original el 24 de junio de 2016.
  127. ^ "¿Por qué Git utiliza una función hash criptográfica?". Stack Overflow. 1 de marzo de 2015. Archivado desde el original el 1 de julio de 2016.
  128. ^ "Git – Documentación de transición de función hash". Git .

Enlaces externos