Hispanopedia Wiki
Articulo de referencia

Git

{{cite web\n | url = https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290\n | date = 8 April 2005\n | title = Initial revision of \"git\", the information ...

Hispanopedia WikiContenido en espanolLectura gratuita

Git ( / ɡ ɪ t /ⓘ [ 8 ] ) es unsistema de softwarede control de versiones distribuido [ 9 ] capaz degestionar versionesde código fuente o datos. Se utiliza frecuentemente para controlarel código fuenteporprogramadoresquedesarrollansoftwarede forma colaborativa. Fue creado originalmente porLinus Torvaldspara el control de versiones en el desarrollo delnúcleo Linux. [ 10 ]

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 ejecutándose en diferentes computadoras. [ 11 ] [ 12 ] [ 13 ]

Al igual que la mayoría de los demás 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 historial y capacidades de seguimiento de versiones, independientemente del acceso a la red o de un servidor central . Un repositorio se almacena en cada computadora en un directorio estándar con archivos adicionales ocultos para proporcionar capacidades de control de versiones. [ 14 ] Git proporciona funciones para sincronizar cambios entre repositorios que comparten historial; para la colaboración asíncrona, esto se extiende a 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 que contenga una copia integrada.

Hoy en día, Git es el sistema de control de versiones más utilizado por los desarrolladores de software. Es el sistema de control de versiones distribuido más popular, [ 15 ] [ 16 ] con casi el 95% de los desarrolladores reportándolo como su sistema de control de versiones principal a partir de 2022. [ 17 ] Es la herramienta de gestión de código fuente más utilizada entre los desarrolladores profesionales. Varias plataformas de software ofrecen servicios de repositorio Git, incluyendo GitHub , SourceForge , Bitbucket y GitLab . [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ]

Git es un software libre y de código abierto que se comparte bajo la licencia GPL-2.0 únicamente .

La marca comercial "Git" está registrada por Software Freedom Conservancy .

Historia

Torvalds comenzó a desarrollar Git en abril de 2005 después de que se revocara la licencia gratuita de BitKeeper , el sistema propietario de gestión de control de versiones (SCM) utilizado para el desarrollo del kernel de Linux desde 2002. [ 23 ] [ 24 ] 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 . [ 25 ] El mismo incidente también impulsó la creación de Mercurial , otro sistema de control de versiones.

Torvalds quería un sistema distribuido que pudiera usar como BitKeeper, pero ninguno de los sistemas gratuitos disponibles satisfacía sus necesidades. Citó el ejemplo de un sistema de gestión de control de versiones que necesitaba 30 segundos para aplicar un parche y actualizar todos los metadatos asociados, y señaló que esto no sería escalable para las necesidades del desarrollo del kernel de 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 de parches no debería tardar más de tres segundos, y añadió tres objetivos más: [ 11 ]

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

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

Torvalds cedió el mantenimiento el 26 de julio de 2005 a Junio ​​Hamano, un importante colaborador del proyecto. [ 31 ] Hamano fue responsable del lanzamiento de la versión 1.0 el 21 de diciembre de 2005. [ 32 ]

Nomenclatura

Torvalds bromeó sobre el nombre git (que es jerga británica para referirse a una persona desagradable o tonta): "Soy un bastardo egocéntrico y nombro todos mis proyectos con mi propio nombre. Primero ' Linux ', ahora 'git'". [ 33 ] [ 34 ] La página man describe a Git como "el estúpido rastreador de contenido". [ 35 ]

El archivo readme del código fuente explica con más detalle: [ 36 ]

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

  • Combinación aleatoria de tres letras que se puede pronunciar, pero que no se utiliza en ningún comando común de UNIX. El hecho de que sea una pronunciación incorrecta de "get" puede o no ser relevante.
  • Estúpido. Despreciable y despreciable. Así de simple. Elige el que quieras del diccionario de jerga.
  • "Rastreador de información global": estás de buen humor y, de hecho, funciona. Los ángeles cantan y una luz ilumina repentinamente la habitación.
  • "Maldito camión de mierda idiota": cuando se rompe.

El código fuente de Git se refiere al programa como "el gestor de información del infierno". [ 37 ] [ 38 ]

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 decisiones de implementación: [ 10 ]

Fuerte apoyo al desarrollo no lineal
Git admite la creación y fusión rápida de ramas, e incluye herramientas específicas para visualizar y navegar por un historial de desarrollo no lineal. En Git, se parte de la premisa fundamental de que un cambio se fusionará con más frecuencia de la que se escribe, ya que pasa por varios revisores. En Git, las ramas son muy ligeras: una rama es solo una referencia a una única confirmación.
desarrollo distribuido
Al igual que Darcs , BitKeeper , Mercurial , Bazaar y Monotone , Git proporciona a cada desarrollador una copia local del historial completo de desarrollo, y los cambios se copian de un repositorio a otro. Estos cambios se importan como ramas de desarrollo añadidas y se pueden fusionar de la misma manera que una rama desarrollada localmente. [ 39 ]
Compatibilidad con sistemas y protocolos existentes
Los repositorios se pueden publicar mediante el 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 cuenta con una emulación de servidor CVS, que permite el uso de clientes CVS y complementos IDE existentes para acceder a los repositorios Git. Los repositorios Subversion se pueden usar directamente con git-svn. [ 40 ]
Gestión eficiente de grandes proyectos
Torvalds ha descrito Git como muy rápido y escalable, [ 41 ] y las pruebas de rendimiento realizadas por Mozilla [ 42 ] demostraron que era un orden de magnitud más rápido comparando grandes repositorios que Mercurial y GNU Bazaar ; obtener el historial de versiones de un repositorio almacenado localmente puede ser cien veces más rápido que obtenerlo del servidor remoto. [ 43 ]
Autenticación criptográfica de la historia
El historial de Git se almacena de tal forma que el ID de una versión específica (un commit en términos de Git) depende del historial de desarrollo completo previo a dicho commit. Una vez publicado, no es posible modificar las versiones anteriores sin que se detecte. La estructura es similar a un árbol Merkle , pero con datos adicionales en los nodos y las hojas. [ 44 ] ( Mercurial y Monotone también poseen esta propiedad).
Diseño basado en un conjunto de herramientas
Git fue diseñado como un conjunto de programas escritos en C y varios scripts de shell que proporcionan interfaces para esos programas. [ 45 ] Aunque la mayoría de esos scripts se han reescrito en C para mayor velocidad y portabilidad, el diseño se mantiene y es fácil encadenar los componentes. [ 46 ]
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 cuenta con múltiples algoritmos para completarla, culminando en informar al usuario que no puede completar la fusión automáticamente y que se requiere edición manual. [ 47 ]
La basura se acumula hasta que se recoge.
Abortar operaciones o revertir cambios dejará objetos huérfanos inútiles en la base de datos. Estos generalmente representan una pequeña fracción del historial en constante crecimiento de objetos deseados. 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. [ 48 ] [ 49 ]
Empaquetamiento explícito periódico de objetos
Git almacena cada objeto recién creado como un archivo separado. Aunque se comprimen individualmente, esto ocupa mucho espacio y es ineficiente. Esto se resuelve mediante el uso de packs que almacenan una gran cantidad de objetos comprimidos delta entre sí en un solo archivo (o flujo de bytes de red) llamado packfile . Los packs se comprimen utilizando la heurística de que los archivos con el mismo nombre probablemente sean similares, sin depender de esto para la corrección. Se crea un archivo de índice correspondiente para cada packfile, registrando el desplazamiento de cada objeto en el packfile. Los objetos recién creados (con el historial recién agregado) todavía se almacenan como objetos individuales, y se necesita un reempaquetado periódico para mantener la eficiencia del espacio. El proceso de empaquetar el repositorio puede ser muy costoso computacionalmente. Al permitir que los objetos existan en el repositorio en un formato flexible 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 automáticamente, pero el reempaquetado manual también es posible con el git gccomando. [ 50 ] Para garantizar la integridad de los datos, tanto el archivo de paquete como su índice contienen una suma de verificación SHA-1 [ 51 ] , y el nombre del archivo de paquete también incluye una suma de verificación SHA-1. Para comprobar la integridad de un repositorio, ejecute el git fsckcomando. [ 52 ] [ 53 ]

Otra propiedad de Git es que crea instantáneas de los árboles de directorios de los archivos. Los primeros sistemas para el seguimiento de versiones de código fuente, el Sistema de Control de Código Fuente (SCCS) y el Sistema de Control de Revisiones (RCS), trabajaban con archivos individuales y enfatizaban el ahorro de espacio que se obtenía mediante deltas intercalados (SCCS) o la codificación delta (RCS) de las versiones (en su mayoría similares). Los sistemas de control de revisiones posteriores mantuvieron esta noción de que un archivo tiene una identidad a través de múltiples revisiones de un proyecto. Sin embargo, Torvalds rechazó este concepto. [ 54 ] 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 significativas:

  • Es ligeramente más costoso examinar el historial de cambios de un archivo que el de todo el proyecto. [ 55 ] Para obtener un historial de cambios que afectan a un archivo determinado, Git debe recorrer el historial global y luego determinar si cada cambio modificó ese archivo. Sin embargo, este método de examen del historial permite que Git genere con la misma eficiencia un único historial que muestre los cambios en un conjunto arbitrario de archivos. Por ejemplo, un subdirectorio del árbol de código fuente más un archivo de encabezado global asociado es un caso muy común.
  • Los cambios de nombre se manejan implícitamente en lugar de explícitamente. Una queja común con CVS es que usa el nombre de un archivo para identificar su historial de revisiones, por lo que mover o renombrar un archivo no es posible sin interrumpir su historial o renombrarlo y, por lo tanto, hacer que el historial sea inexacto. La mayoría de los sistemas de control de revisiones posteriores a CVS resuelven esto dando a un archivo un nombre único de larga duración (análogo a un número de inodo ) que sobrevive al cambio de nombre. Git no registra dicho identificador, y esto se afirma como una ventaja. [ 56 ] [ 57 ] Los archivos de código fuente a veces se dividen o fusionan, o simplemente se renombran, [ 58 ] y registrar esto como un simple cambio de nombre congelaría una descripción inexacta de lo que sucedió en el historial (inmutable). Git aborda el problema detectando los cambios de nombre mientras explora el historial de instantáneas en lugar de registrarlo al crear la instantánea. [ 59 ] (En resumen, dado un archivo en la revisión N , un archivo con el mismo nombre en la revisión N  −  1 es su antecesor predeterminado. Sin embargo, cuando no hay un archivo con el mismo nombre en la revisión N  −  1, Git busca un archivo que existió solo en la revisión N  −  1 y que es muy similar al nuevo archivo). Sin embargo, requiere un trabajo más intensivo de CPU cada vez que se revisa el historial, y hay varias opciones disponibles para ajustar la heurística. Este mecanismo no siempre funciona; a veces, un archivo que se renombra con cambios en la misma confirmación se interpreta como una eliminación del archivo antiguo y la creación de un archivo nuevo. Los desarrolladores pueden solucionar esta limitación confirmando el cambio de nombre y los cambios por separado.

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: [ 60 ]

  • resolver : el algoritmo tradicional de fusión de tres vías .
  • recursivo : Este es el valor predeterminado al extraer o fusionar una rama, y ​​es una variante del algoritmo de fusión de tres vías.

    Cuando existen varios ancestros comunes que pueden utilizarse para una fusión triple, se crea un árbol fusionado de dichos ancestros y se utiliza como árbol de referencia para la fusión triple. Se ha comprobado que esto reduce los conflictos de fusión sin provocar fusiones incorrectas, según pruebas realizadas con confirmaciones de fusión anteriores del historial de desarrollo del kernel de Linux 2.6. Además, permite detectar y gestionar fusiones que implican cambios de nombre.

    — Linus Torvalds [ 61 ]

  • pulpo : Esta es la opción predeterminada cuando se fusionan más de dos cabezas.

Estructuras de datos

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

En muchos sentidos, se puede ver Git simplemente como un sistema de archivos: es direccionable por contenido y tiene una noción de versionado, pero realmente lo diseñé abordando el problema desde el punto de vista de alguien que trabaja con sistemas de archivos (bueno, los kernels son a lo que me dedico), y en realidad no tengo 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, [ 63 ] con características que en su mayoría se crean según sea necesario, y luego se refinan y extienden con el tiempo.

Algunos flujos de datos y niveles de almacenamiento en el sistema de control de versiones 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. [ 64 ]

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

El almacén de objetos contiene cinco tipos de objetos: [ 65 ] [ 52 ]

  • Un blob es el contenido de un archivo . Los blobs no tienen un nombre de archivo propio, marcas de tiempo ni otros metadatos (el nombre de un blob es internamente un hash de su contenido). En Git, cada blob es una versión de un archivo, que contiene los datos del archivo. [ 66 ]
  • Un objeto de árbol es el equivalente a un directorio. Contiene una lista de nombres de archivo, [ 67 ] cada uno con ciertos bits de tipo y una referencia a un objeto blob o de árbol que representa el contenido de ese archivo, enlace simbólico o directorio. Estos objetos son una instantánea del árbol de origen. (En conjunto, esto constituye un árbol Merkle , lo que significa que basta con un único hash para el árbol raíz, que se utiliza en las confirmaciones para determinar con precisión el estado exacto de estructuras de árbol completas de cualquier número de subdirectorios y archivos).
  • Un objeto de confirmación enlaza objetos de árbol entre sí en el historial. Contiene el nombre de un objeto de árbol (del directorio fuente de nivel superior), una marca de tiempo, un mensaje de registro y los nombres de cero o más objetos de confirmación principales. [ 68 ]
  • Un objeto de etiqueta es un contenedor que contiene una referencia a otro objeto y puede almacenar metadatos adicionales relacionados con este último. Generalmente, se utiliza para almacenar una firma digital de un objeto de confirmación correspondiente a una versión específica de los datos que Git está rastreando. [ 69 ]
  • Un objeto packfile recopila varios otros objetos en un paquete comprimido con zlib para mayor compacidad y facilidad de transporte a través de protocolos de red. [ 70 ]

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 dicho 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 compresión zlib. Esto puede consumir rápidamente una gran cantidad de espacio en disco, por lo que los objetos se pueden combinar en paquetes , que utilizan compresión delta para ahorrar espacio, almacenando los blobs como sus cambios relativos a otros blobs.

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

  • Ramas (Heads) : Referencias con nombre que se actualizan automáticamente al nuevo commit cuando se realiza un commit sobre ellas.
  • HEAD : Un encabezado reservado que se comparará con el árbol de trabajo para crear una confirmación.
  • Etiquetas : Similares a las referencias de rama, pero vinculadas a una confirmación específica. Se utilizan para etiquetar puntos importantes del historial.

Comandos

Los comandos más utilizados para la interfaz de línea de comandos de Git incluyen: [ 72 ] [ 73 ]

  • git init, que se utiliza para crear un repositorio git.
  • git clone [URL], que clona o duplica un repositorio git desde una URL externa.
  • git add [file], que agrega un archivo al directorio de trabajo de git (archivos que están a punto de ser confirmados).
  • git commit -m [commit message], lo que confirma los archivos del directorio de trabajo actual (por lo que ahora forman parte del historial del repositorio).

Se puede crear un archivo .gitignore en un repositorio Git como un archivo de texto plano . Los archivos listados en el archivo .gitignore no serán rastreados por Git. [ 74 ] : 3–4 Esta función se puede usar para ignorar archivos con claves o contraseñas, varios archivos extraños y archivos grandes (que GitHub se negará a cargar). [ 75 ]

Referencias de Git

Cada objeto en la base de datos de Git que no se referencia puede limpiarse mediante un comando de recolección de basura o automáticamente. 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:

  • cabezas : se refiere a un objeto localmente,
  • remotos : se refiere a un objeto que existe en un repositorio remoto,
  • stash : se refiere a un objeto que aún no ha sido confirmado,
  • meta : p. ej. , una configuración en un repositorio vacío, derechos de usuario; el espacio de nombres refs/meta/config se introdujo retrospectivamente, lo usa Gerrit , [ 76 ]
  • Etiquetas : ver arriba.

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 . [ 77 ] [ 78 ]

La primera versión de Git para Windows era principalmente un entorno de emulación de Linux que alojaba la versión de Linux. La instalación de Git en Windows crea un directorio de Archivos de programa con un nombre similar que contiene la versión Mingw-w64 de la Colección de Compiladores GNU , Perl 5, MSYS2 (que a su vez es una bifurcación de Cygwin , un entorno de emulación similar a Unix para Windows) y varias otras versiones o emulaciones de utilidades y bibliotecas de Linux para Windows. Actualmente, las compilaciones nativas de Git para Windows se distribuyen como instaladores de 32 y 64 bits. [ 79 ] El sitio web oficial de Git mantiene actualmente una compilación de Git para Windows, que todavía utiliza el entorno MSYS2. [ 80 ]

La implementación de Git en JGit es una biblioteca de software puramente Java , diseñada para integrarse 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 . [ 81 ]

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

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

La implementación libgit2 de Git es una biblioteca de software ANSI C sin otras dependencias, que se puede compilar en múltiples plataformas, incluyendo Windows, Linux, macOS y BSD. [ 86 ] Tiene enlaces para muchos lenguajes de programación, incluyendo Ruby , Python y Haskell . [ 87 ] [ 88 ] [ 89 ]

Otras implementaciones de Git incluyen JS-Git (una implementación en JavaScript de un subconjunto de Git), [ 90 ] Game of Trees (una implementación de código abierto de Git para el proyecto OpenBSD ), [ 91 ] git9 (una implementación independiente de Git para Plan 9 que utiliza las abstracciones nativas del sistema), [ 92 ] [ 93 ] y gitoxide (una implementación de Git escrita en Rust puro ). [ 94 ]

Servidor Git

Captura de pantalla de la interfaz web de Git que muestra una diferencia de confirmación.

Como Git es un sistema de control de versiones distribuido, puede usarse como servidor directamente. Incluye un comando integrado git daemonque inicia un servidor TCP simple que se ejecuta en el protocolo Git. [ 95 ] [ 96 ] Los servidores HTTP dedicados de Git ayudan (entre otras características) al agregar control de acceso, mostrar el contenido de un repositorio Git a través de interfaces web y administrar múltiples repositorios. Los repositorios Git ya existentes pueden clonarse y compartirse para que otros los usen como un repositorio centralizado. También se puede acceder a él a través de una consola remota simplemente teniendo el software Git instalado y permitiendo que un usuario inicie sesión. [ 97 ] Los servidores Git normalmente escuchan en el puerto TCP 9418. [ 98 ]

Para la exploración de repositorios basada en web, Git también incluye gitweb, una interfaz basada en CGI para visualizar el contenido de los repositorios a través de HTTP. [ 99 ]

Código abierto

  • Alojar el servidor Git usando el binario de Git. [ 100 ]
  • Gerrit es un servidor Git configurable para admitir revisiones de código y proporcionar acceso mediante SSH, Apache MINA u OpenSSH integrados, o un servidor web Jetty integrado . Gerrit ofrece integración con LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI y certificados de cliente HTTPS X509. Con Gerrit 3.0, todas las configuraciones se almacenarán como repositorios Git y no se requiere una base de datos para su funcionamiento. Gerrit incluye una función de solicitud de extracción (pull request) integrada, pero carece de una interfaz gráfica de usuario (GUI).
  • Phabricator , un producto derivado de Facebook. Dado que Facebook utiliza principalmente Mercurial , el soporte para Git no es tan prominente. [ 101 ]
  • RhodeCode Community Edition (CE), compatible con Git, Mercurial y Subversion con licencia AGPLv3 .
  • Kallithea , compatible con Git y Mercurial , fue desarrollado en Python bajo licencia GPL .
  • Proyectos externos como gitolite, [ 102 ] que proporcionan scripts sobre el software Git para proporcionar un control de acceso granular.
  • Existen varias otras soluciones FLOSS para el autoalojamiento, incluyendo Gogs, [ 103 ] Gitea , una bifurcación de Gogs, así como Forgejo , que a su vez es una bifurcación de Gitea. Gogs, al igual que sus dos derivados mencionados, se desarrolla utilizando el lenguaje Go . Las tres soluciones están disponibles bajo la licencia MIT .

Servidor Git como servicio

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

Interfaces gráficas

Los clientes GUI de Git ofrecen una interfaz gráfica de usuario (GUI) para simplificar la interacción con los repositorios de Git.

Estas interfaces gráficas de usuario (GUI) proporcionan representaciones visuales del historial del proyecto, incluyendo ramas, confirmaciones y cambios en los archivos. También agilizan acciones como la preparación de cambios, la creación de confirmaciones y la gestión de ramas. Las herramientas de comparación visual ayudan a resolver conflictos de fusión derivados del desarrollo concurrente.

Git viene con una interfaz gráfica de usuario (GUI) en Tcl/Tk , que permite a los usuarios realizar acciones como crear y modificar commits, crear y fusionar ramas e interactuar con repositorios remotos. [ 105 ]

Además de la GUI oficial, existen muchas interfaces de terceros que proporcionan características similares a la GUI oficial distribuida con Git. [ 106 ]

Los clientes con interfaz gráfica de usuario (GUI) facilitan el aprendizaje y el uso de Git, mejorando la eficiencia del flujo de trabajo y reduciendo los errores.

Adopción

La Fundación Eclipse informó en su encuesta comunitaria anual que a partir de mayo de 2014 Git fue la herramienta de gestión de código fuente más utilizada, con un 42,9 % de desarrolladores de software profesionales que informaron que usan Git como su sistema principal de control de versiones [ 107 ] en comparación con el 36,3 % en 2013 y el 32 % en 2012; o para las respuestas de Git que excluyen el uso de GitHub : 33,3 % en 2014, 30,3 % en 2013, 27,6 % en 2012 y 12,8 % en 2011. [ 108 ] El directorio de código abierto OpenHub informó una adopción similar entre los proyectos de código abierto. [ 109 ]

Stack Overflow ha incluido el control de versiones en su encuesta anual para desarrolladores [ 110 ] en 2015 (16.694 respuestas), [ 111 ] 2017 (30.730 respuestas), [ 112 ] 2018 (74.298 respuestas) [ 113 ] y 2022 (71.379 respuestas). [ 17 ] Git fue el favorito indiscutible de los desarrolladores que respondieron en estas encuestas, reportando hasta 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 finales de septiembre de 2016, el 29,27% de las ofertas de empleo permanentes de desarrollo de software en el Reino Unido citaban Git, [ 114 ] por delante del 12,17% para Microsoft Team Foundation Server , [ 115 ] el 10,60% para Subversion , [ 116 ] el 1,30% para Mercurial , [ 117 ] y el 0,48% para Visual SourceSafe . [ 118 ]

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, una extensión de uso generalizado podría integrarse con Git.

Otras extensiones de Git de código abierto incluyen:

  • git-annex , un sistema de sincronización de archivos distribuido basado en Git
  • git-flow , un conjunto de extensiones de Git para proporcionar operaciones de repositorio de alto nivel para el modelo de ramificación de Vincent Driessen.
  • git-machete, un organizador de repositorios y herramienta para automatizar operaciones de rebase/merge/pull/push.

Microsoft desarrolló la extensión Sistema de archivos virtual para Git (VFS para Git; anteriormente Sistema de archivos virtual de Git 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 para Git permite que los repositorios clonados utilicen marcadores de posición cuyo contenido se descarga solo una vez que se accede a un archivo. [ 119 ]

Convenciones

Git se puede utilizar de diversas maneras, pero existen algunas convenciones que se suelen adoptar.

  • El comando para crear un repositorio local, git init , crea una rama llamada master . [ 66 ] [ 120 ] A menudo se utiliza como rama de integración para fusionar cambios. [ 121 ] Algunas herramientas, como GitHub [ 122 ] y GitLab, [ 123 ] crean una rama predeterminada llamada main en su lugar; Git comenzará a usar main a partir de la versión 3.0, prevista para finales de 2026. [ 124 ] Dado que el remoto upstream predeterminado se llama origin , [ 125 ] la rama remota predeterminada es origin/master . Además, los usuarios pueden agregar y eliminar ramas y elegir cualquier rama para la integración.
  • Por lo general, las confirmaciones enviadas no se sobrescriben, sino que se revierten [ 126 ] al confirmar otro cambio que revierte una confirmación anterior. Esto evita que las confirmaciones compartidas sean inválidas porque la confirmación en la que se basan no existe en el repositorio remoto. Si las confirmaciones contienen información confidencial, deben eliminarse, lo que implica un procedimiento más complejo para reescribir el historial.
  • El flujo de trabajo y las convenciones de nomenclatura de git-flow [ 127 ] se adoptan a menudo para distinguir los historiales inestables específicos de las características (feature/*), los historiales compartidos inestables (develop), los historiales listos para la producción (main) y los parches de emergencia para los productos publicados (hotfix).
  • Una solicitud de extracción , también conocida como solicitud de fusión , es una solicitud de un usuario para fusionar una rama con otra. [ 128 ] [ 129 ] Git no admite solicitudes de extracción, pero es una característica común de los servicios en la nube de Git. La función subyacente de una solicitud de extracción no difiere de la de un administrador de un repositorio que extrae cambios de otro repositorio remoto (el repositorio que es la fuente de la solicitud de extracción). Sin embargo, la solicitud de extracción es un ticket administrado por el servidor de alojamiento, que realiza estas acciones; no es una característica de Git SCM.

Seguridad

Git no proporciona mecanismos de control de acceso, pero fue diseñado para funcionar con otras herramientas especializadas en control de acceso. [ 130 ]

El 17 de diciembre de 2014 se descubrió una vulnerabilidad que afectaba a las versiones de Windows y macOS del cliente Git. Un atacante podía ejecutar código arbitrario en un ordenador con Git instalado creando un árbol (directorio) Git malicioso llamado .git (un directorio en los repositorios Git que almacena todos los datos del repositorio) con una capitalización diferente (como .GIT o .Git, necesaria porque Git no permite crear manualmente la versión en minúsculas de .git ) con archivos maliciosos en el subdirectorio .git/hooks (una carpeta con archivos ejecutables que Git ejecuta) en un repositorio creado por el atacante o en un repositorio que el atacante pudiera 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 que los sistemas de archivos de Windows y Mac no distinguen entre mayúsculas y minúsculas) y los archivos ejecutables maliciosos en .git/hooks podrían ejecutarse, lo que resultaría en la ejecución de 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 al ejecutarse. La vulnerabilidad se corrigió en la versión 2.2.1 de Git, publicada el 17 de diciembre de 2014, y se anunció al día siguiente. [ 131 ] [ 132 ]

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

Git utiliza internamente funciones hash SHA-1 . Linus Torvalds respondió que el hash servía principalmente para protegerse contra la corrupción accidental, y que la seguridad que proporciona un hash criptográficamente seguro era solo un efecto secundario accidental, siendo la principal seguridad la firma en otro lugar. [ 136 ] [ 137 ] Tras una demostración del ataque SHAttered contra Git en 2017, Git se modificó para utilizar una variante de SHA-1 resistente a este ataque. Desde febrero de 2020 se está elaborando un plan para la transición a la función hash. [ 138 ]

Marca

"Git" es una marca registrada de Software Freedom Conservancy , registrada en la Oficina de Patentes y Marcas de los Estados Unidos con el número de registro 4680534 desde el 3 de febrero de 2015.

Véase también

Notas

  1. ↑ GPL-2.0-only desde el 11/04/2005. Algunas partes bajo licencias compatibles como LGPLv2.1 . [ 6 ]
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 No aparece como opción en esta encuesta

Referencias

  1. ↑ "Revisión inicial de "git", el gestor de información del infierno" . GitHub . 8 de abril de 2005. Archivado del original el 16 de noviembre de 2015. Consultado el 20 de diciembre de 2015 .
  2. ↑ "Commit Graph" . GitHub . 8 de junio de 2016. Archivado del original el 20 de enero de 2016. Consultado el 19 de diciembre de 2015 .
  3. ↑ Junio ​​C Hamano (29 de junio de 2026). " [ ANUNCIO ] Git v2.55.0" . Consultado el 1 de julio de 2026 .
  4. ↑ "Sitio web de Git" . Archivado del original el 9 de junio de 2022. Consultado el 9 de junio de 2022 .
  5. ↑ "Git Source Code Mirror" . GitHub . Archivado del 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 del 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 del original el 11 de abril de 2016. Consultado el 12 de octubre de 2014 .
  8. ↑ Charla técnica: Linus Torvalds sobre git . 14 de mayo de 2007. El evento ocurre a las 00:01:30. Archivado del original el 20 de diciembre de 2015. Recuperado el 20 de julio de 2014 a través de YouTube .
  9. ↑ Chacon y Straub 2014 , págs. 29–31.
  10. 1 2 "Una breve historia de Git" . Pro Git (2.ª ed.). Apress. 2014. Archivado del original el 25 de diciembre de 2015. Recuperado el 26 de diciembre de 2015 . 
  11. 1 2 Torvalds, Linus (7 de abril de 2005). "Re: Saga del SCM del kernel..." linux-kernel (Lista de correo). Archivado del original el 1 de julio de 2019. Recuperado el 3 de febrero de 2017 ."Así que estoy escribiendo algunos scripts para intentar rastrear las cosas mucho más rápido."
  12. 1 2 Torvalds, Linus (10 de junio de 2007). "Re: fatal: grave inconsistencia de inflate" . git (Lista de correo). Archivado del original el 28 de diciembre de 2022. Recuperado el 3 de febrero de 2017 .
  13. 1 2 3 4 Linus Torvalds (3 de mayo de 2007). Charla técnica de Google: Linus Torvalds sobre git . El evento ocurre a las 02:30. Archivado del original el 28 de mayo de 2007. Recuperado el 16 de mayo de 2007 .
  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 del original el 25 de diciembre de 2015 .
  15. ↑ Shirey, Russell G. (1 de marzo de 2015). "Git como un sistema de control de versiones distribuido y cifrado" (PDF) . Centro de Información Técnica de Defensa . pág. 38. Recuperado el 13 de julio de 2025 . 
  16. ↑ Knüpfer, Andreas; Callow, Timothy J. (2025). "Gestión de versiones de datos y reproducibilidad procesable por máquina para HPC basada en git y DataLad". arXiv : 2505.06558 [ cs.DC ].
  17. 1 2 "Encuesta para desarrolladores de Stack Overflow 2022" . Stack Overflow . Archivado del original el 27 de junio de 2022. Consultado el 4 de agosto de 2022 .
  18. ↑ Krill, Paul (28 de septiembre de 2016). "Guerra de repositorios empresariales: GitHub vs. GitLab vs. Bitbucket" . InfoWorld . Archivado del original el 2 de febrero de 2020. Recuperado el 2 de febrero de 2020 .
  19. 1 2 "Análisis competitivo, marketing mix y tráfico de github.com" . Alexa . Archivado del original el 31 de marzo de 2013. Recuperado el 2 de febrero de 2020 .
  20. 1 2 "sourceforge.net Análisis competitivo, mezcla de marketing y tráfico" . Alexa . Archivado del original el 20 de octubre de 2020. Recuperado el 2 de febrero de 2020 .
  21. 1 2 "Análisis competitivo, marketing mix y tráfico de bitbucket.org" . Alexa . Archivado del original el 23 de junio de 2017. Consultado el 2 de febrero de 2020 .
  22. 1 2 "Análisis competitivo, marketing mix y tráfico de gitlab.com" . Alexa . Archivado del original el 30 de noviembre de 2017. Consultado el 2 de febrero de 2020 .
  23. ↑ Brown, Zack (27 de julio de 2018). "Una historia sobre el origen de Git" . Linux Journal . Linux Journal. Archivado del original el 13 de abril de 2020. Recuperado el 28 de mayo de 2020 .
  24. ↑ "BitKeeper y Linux: ¿El final del camino?" . Linux.com . 11 de abril de 2005 . Consultado el 18 de mayo de 2023 .
  25. ↑ McAllister, Neil (2 de mayo de 2005). "El error de Linus Torvalds con BitKeeper" . InfoWorld . Archivado del original el 26 de agosto de 2015. Recuperado el 8 de septiembre de 2015 .
  26. 1 2 Torvalds, Linus (27 de febrero de 2007). "Re: Trivia: ¿Cuándo se autoalojó git?" . git (Lista de correo). Archivado del original el 8 de abril de 2023. Recuperado el 3 de febrero de 2017 .
  27. ↑ Torvalds, Linus (6 de abril de 2005). "La saga del SCM del kernel". linux-kernel (Lista de correo). Archivado del original el 8 de junio de 2023. Recuperado el 3 de febrero de 2017 .
  28. ↑ Torvalds, Linus (17 de abril de 2005). "¡Primera fusión real de git en el kernel!" . git (Lista de correo). Archivado del original el 15 de agosto de 2021. Recuperado el 3 de febrero de 2017 .
  29. ↑ Mackall, Matt (29 de abril de 2005). "Comparativa de rendimiento entre Mercurial 0.4b y git patchbomb" . git (Lista de correo). Archivado del original el 15 de agosto de 2021. Recuperado el 3 de febrero de 2017 .
  30. ↑ Torvalds, Linus (17 de junio de 2005). "Linux 2.6.12" . git-commits-head (Lista de correo).
  31. ↑ Torvalds, Linus (27 de julio de 2005). "Conozcan al nuevo mantenedor." git (Lista de correo). Archivado del original el 15 de agosto de 2021. Recuperado el 3 de febrero de 2017 .
  32. ^ Hamano, Junio ​​C. (21 de diciembre de 2005). "Anuncio: Git 1.0.0" . git (lista de correo). Archivado desde el original el 16 de agosto de 2021 . Consultado el 3 de febrero de 2017 .
  33. ↑ "GitFaq: ¿Por qué el nombre 'Git'?" . Git.or.cz. Archivado del original el 23 de julio de 2012. Recuperado el 14 de julio de 2012 .
  34. ↑ "Tras la polémica, Torvalds comienza a trabajar en 'git'"PC World . 14 de julio de 2012. Archivado del original el 1 de febrero de 2011. Torvalds parecía consciente de que su decisión de abandonar BitKeeper también sería controvertida. Cuando se le preguntó por qué llamó al nuevo software «git», jerga británica que significa «una persona podrida», respondió: «Soy un cabrón egocéntrico, así que les pongo mi nombre a todos mis proyectos. Primero Linux, ahora git».
  35. ↑ "Página del manual de git(1)" . Archivado del original el 21 de junio de 2012. Consultado el 21 de julio de 2012 .
  36. ↑ "Revisión inicial de 'git', el gestor de información del infierno · git/git@e83c516" . GitHub . Archivado del original el 8 de octubre de 2017. Recuperado el 21 de enero de 2016 .
  37. ↑ "git/usage.c en master · git/git" . GitHub . Archivado del original el 26 de febrero de 2025. Consultado el 11 de julio de 2025 .
  38. ↑ Torvalds, Linus (7 de abril de 2005). "Revisión inicial de "git", el gestor de información del infierno · git/git@e83c516" . GitHub . Archivado del original el 16 de noviembre de 2015. Recuperado el 11 de julio de 2025 .
  39. ↑ "Git – Flujos de trabajo distribuidos" . Git . Archivado del original el 22 de octubre de 2014. Consultado el 15 de junio de 2020 .
  40. ↑ Gunjal, Siddhesh (19 de julio de 2019). "¿Qué es una herramienta de control de versiones? Explora Git y GitHub" . Medium . Archivado del original el 17 de abril de 2025. Recuperado el 25 de octubre de 2020 .
  41. ↑ Torvalds, Linus (19 de octubre de 2006). "Re: Tabla comparativa de VCS" . git (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  42. ↑ Blog de Jst en Mozillazine "rendimiento de bzr/hg/git" . Archivado del original el 29 de mayo de 2010. Consultado el 12 de febrero de 2015 .
  43. ↑ Dreier, Roland (13 de noviembre de 2006). «¡Oh, qué alivio!» . Archivado del 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 con un servidor remoto.
  44. ↑ "Confianza" . Conceptos de Git . Manual del usuario de Git. 18 de octubre de 2006. Archivado del original el 22 de febrero de 2017.
  45. ↑ Torvalds, Linus. "Re: Tabla comparativa de VCS" . git (Lista de correo). Archivado del original el 11 de abril de 2016. Recuperado el 10 de abril de 2009 ., describiendo el diseño orientado a scripts de Git
  46. ↑ iabervon (22 de diciembre de 2005). "¡Git mola!" . Archivado del original el 14 de septiembre de 2016., elogiando la capacidad de Git para programar scripts.
  47. ↑ "Git – Git SCM Wiki" . git.wiki.kernel.org . Archivado del original el 6 de febrero de 2010. Consultado el 25 de octubre de 2020 .
  48. ↑ Chacon y Straub 2014 .
  49. ↑ "Manual de usuario de Git" . 10 de marzo de 2020. Archivado del original el 10 de mayo de 2020.
  50. ↑ Chacon y Straub 2014 , pág. 499.
  51. ↑ Chacon y Straub 2014 , págs. 33–34.
  52. 1 2 "Git – Packfiles" . Git . Archivado del original el 26 de julio de 2025. Recuperado el 25 de agosto de 2025 .
  53. ↑ Chacon & Straub 2014 , pág. 568.
  54. ↑ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de git." linux-kernel (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  55. ↑ Haible, Bruno (11 de febrero de 2007). "¿Cómo acelerar 'git log'?" . git (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  56. ↑ Torvalds, Linus (1 de marzo de 2006). "Re: cambios de nombre impuros / seguimiento del historial" . git (Lista de correo). Archivado del original el 3 de mayo de 2017. Recuperado el 3 de febrero de 2017 .
  57. ↑ Hamano, Junio ​​C. (24 de marzo de 2006). "Re: Errores al gitificar GCC y Binutils" . git (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  58. ↑ Hamano, Junio ​​C. (23 de marzo de 2006). "Re: Errores al gitificar GCC y Binutils" . git (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  59. ↑ Torvalds, Linus (28 de noviembre de 2006). "Re: git y bzr" . git (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 ., sobre su uso git-blamepara mostrar el código movido entre archivos fuente.
  60. ↑ Torvalds, Linus (18 de julio de 2007). "git-merge(1)" . Archivado del original el 16 de julio de 2016.
  61. ↑ Torvalds, Linus (18 de julio de 2007). "CrissCrossMerge" . Archivado del original el 13 de enero de 2006.
  62. ↑ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de git..." linux-kernel (Lista de correo). Archivado del original el 18 de junio de 2017. Recuperado el 3 de febrero de 2017 .
  63. ↑ Torvalds, Linus (23 de marzo de 2006). "Re: Errores al integrar GCT en GCC y Binutils" . git (Lista de correo). Archivado del original el 22 de marzo de 2021. Recuperado el 3 de febrero de 2017 .
  64. 1 2 "Git - Objetos Git" . git-scm.com . Consultado el 1 de abril de 2026 .
  65. ↑ "Git – Objetos Git" . Git . Archivado del original el 29 de julio de 2025. Consultado el 25 de agosto de 2025 .
  66. 1 2 Chacon y Straub 2014 , págs. 81–83.
  67. ↑ Chacon y Straub 2014 , págs. 485–488.
  68. ↑ Chacon y Straub 2014 , págs. 488–490.
  69. ↑ Chacon y Straub 2014 , págs. 495–496.
  70. ↑ Chacon y Straub 2014 , págs. 497–501.
  71. ↑ "Git – Referencias de Git" . Git . Archivado del original el 26 de julio de 2025. Consultado el 25 de agosto de 2025 .
  72. ↑ "Guía rápida de Git" (PDF) . education.github.com . Archivado (PDF) del original el 19 de junio de 2024. Consultado el 10 de junio de 2024 .
  73. ↑ "Tutorial de Git" (PDF) . web.stanford.edu . Archivado (PDF) del original el 10 de junio de 2024. Consultado el 10 de junio de 2024 .
  74. ↑ "Introducción rápida a Git" (PDF) . data-skills.github.io . Archivado (PDF) del original el 23 de junio de 2024. Consultado el 10 de junio de 2024 .
  75. ↑ Ba Tran, Andrew. "Mejores prácticas para subir archivos a GitHub" (PDF) . journalismcourses.org . Archivado (PDF) del original el 10 de septiembre de 2024. Consultado el 10 de junio de 2024 .
  76. ↑ "Formato de archivo de configuración del proyecto" . Gerrit Code Review . Archivado del original el 3 de diciembre de 2020. Consultado el 2 de febrero de 2020 .
  77. ↑ "descargas" . Archivado del original el 8 de mayo de 2012. Consultado el 14 de mayo de 2012 .
  78. ↑ "versiones de paquetes git – Repology" . Archivado del original el 19 de enero de 2022. Recuperado el 30 de noviembre de 2021 .
  79. ↑ "msysGit" . GitHub . Archivado del original el 10 de octubre de 2016. Consultado el 20 de septiembre de 2016 .
  80. ↑ "Git – Descargando paquete" . Git . Archivado del original el 29 de julio de 2025. Consultado el 25 de agosto de 2025 .( Código fuente archivado el 26 de julio de 2025 en Wayback Machine )
  81. ↑ "JGit" . Archivado del original el 31 de agosto de 2012. Consultado el 24 de agosto de 2012 .
  82. ↑ "Git – go-git" . Git . Archivado del original el 22 de abril de 2025. Recuperado el 19 de abril de 2019 .
  83. ↑ "Interfaz SQL para repositorios Git, escrita en Go." , github.com , archivado del original el 22 de junio de 2025 , consultado el 19 de abril de 2019.
  84. ↑ "Keybase lanza git cifrado" . keybase.io . Archivado del original el 16 de mayo de 2018. Consultado el 19 de abril de 2019 .
  85. ↑ "Dulwich GitHub Repository README.md" . GitHub . Archivado del original el 29 de abril de 2024 . Consultado el 29 de abril de 2024 .
  86. ↑ "libgit2" . GitHub . Archivado del original el 11 de abril de 2016. Consultado el 24 de agosto de 2012 .
  87. ↑ "resistente" . GitHub . Archivado del original el 24 de julio de 2013. Consultado el 24 de agosto de 2012 .
  88. ↑ "pygit2" . GitHub . Archivado del original el 5 de agosto de 2015. Consultado el 24 de agosto de 2012 .
  89. ↑ "hlibgit2" . Archivado del original el 25 de mayo de 2013. Consultado el 30 de abril de 2013 .
  90. ↑ "js-git: una implementación de Git en JavaScript" . GitHub . Archivado del original el 7 de agosto de 2013. Consultado el 13 de agosto de 2013 .
  91. ↑ "Juego de árboles" . gameoftrees.org . Archivado del original el 18 de julio de 2025. Consultado el 10 de marzo de 2024 .
  92. ↑ "git webls" . orib.dev . Archivado del original el 10 de febrero de 2025. Consultado el 21 de septiembre de 2025 .
  93. ↑ "selfhosting git9" . orib.dev . Archivado del original el 10 de febrero de 2025. Consultado el 21 de septiembre de 2025 .
  94. ↑ "gitoxide: una implementación de Git en Rust" . GitHub . Consultado el 18 de diciembre de 2025 .{{cite web}}: CS1 mantenimiento: estado de la URL ( enlace )
  95. ↑ Chacon y Straub 2014 , págs. 138–139.
  96. ↑ "Git – Git Daemon" . Git . Archivado del original el 30 de mayo de 2025. Consultado el 10 de julio de 2019 .
  97. ↑ 4.4 Git en el servidor: configuración del servidor Archivado el 22 de octubre de 2014 en Wayback Machine , Pro Git.
  98. ↑ "1.4 Primeros pasos: Instalación de Git" . Git. Archivado del original el 2 de noviembre de 2013. Consultado el 1 de noviembre de 2013 .
  99. ↑ "Git - gitweb Documentation" . git-scm.com . Consultado el 13 de marzo de 2026 .
  100. ↑ Chacon, Scott; Straub, Ben (2014). "Git en el servidor: configuración del servidor" . Pro Git (2.ª ed.). Apress. ISBN  978-1484200773Archivado del original el 30 de julio de 2025. Consultado el 25 de agosto de 2025 .
  101. ↑ Guía del usuario de Diffusion: Alojamiento de repositorios Archivado el 20 de septiembre de 2020 en Wayback Machine .
  102. ↑ "Gitolite: Alojamiento de repositorios Git" . Archivado del original el 13 de junio de 2025. Consultado el 25 de agosto de 2025 .
  103. ↑ "Gogs: Un servicio Git autohospedado sin complicaciones" . Archivado del original el 25 de julio de 2025. Consultado el 25 de agosto de 2025 .
  104. ↑ "Aspectos destacados de Git 2.26" . El blog de GitHub . 22 de marzo de 2020. Archivado del original el 22 de marzo de 2021. Recuperado el 25 de noviembre de 2020. Puede que recuerdes cuando Git introdujo una nueva versión de su protocolo de obtención de red allá por 2018. Ese protocolo ahora se usa por defecto en 2.26, así que recordemos qué significa eso. El mayor problema con el antiguo protocolo era que el servidor listaba 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 podía significar enviar megabytes de datos adicionales, cuando el cliente realmente solo quería saber sobre la rama principal. 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 podría parecerlo todo, pero los repositorios del servidor 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 grandes repositorios mejoran en velocidad, especialmente cuando la recuperación en sí es pequeña, lo que hace que el costo de la publicidad de referencia inicial sea relativamente más caro. ¡Y lo mejor es que no tendrás que hacer nada! Gracias a un diseño inteligente, cualquier cliente que utilice el nuevo protocolo puede funcionar sin problemas tanto con servidores antiguos como nuevos, recurriendo al protocolo original si el servidor no lo admite. La única razón del retraso entre la introducción del protocolo y su conversión en el predeterminado fue permitir que los primeros usuarios detectaran cualquier error.
  105. ↑ "Git - git-gui Documentation" . Git . Archivado del original el 26 de julio de 2025. Consultado el 1 de julio de 2024 .
  106. ↑ "Git - Clientes GUI" . Git . Archivado del original el 28 de julio de 2025. Consultado el 1 de julio de 2024 .
  107. ↑ "Resultados de la encuesta comunitaria de Eclipse 2014 | Ian Skerrett" . Ianskerrett.wordpress.com. 23 de junio de 2014. Archivado del original el 25 de junio de 2014. Consultado el 23 de junio de 2014 .
  108. ↑ "Resultados de la encuesta de la comunidad Eclipse 2012" . eclipse.org. Archivado del original el 11 de abril de 2016.
  109. ↑ "Comparar repositorios – Open Hub" . Archivado del original el 7 de septiembre de 2014.
  110. ↑ "Encuesta anual de desarrolladores de Stack Overflow" . Stack Exchange, Inc. Consultado el 9 de enero de 2020. La encuesta anual de desarrolladores de Stack Overflow es la más grande y completa del mundo sobre programadores. Cada año, realizamos una encuesta que abarca desde las tecnologías favoritas de los desarrolladores hasta sus preferencias laborales. Este año se cumplen nueve años desde que publicamos los resultados de nuestra encuesta anual de desarrolladores, y casi 90 000 desarrolladores participaron en la encuesta de 20 minutos a principios de este año.
  111. ↑ "Encuesta a desarrolladores de Stack Overflow 2015" . Stack Overflow. Archivado del original el 4 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  112. ↑ "Encuesta a desarrolladores de Stack Overflow 2017" . Stack Overflow. Archivado del original el 29 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  113. ↑ "Encuesta para desarrolladores de Stack Overflow 2018" . Stack Overflow. Archivado del original el 30 de mayo de 2019. Consultado el 29 de mayo de 2019 .
  114. ↑ "Empleos en Git (software), salario promedio para profesionales con conocimientos del sistema de control de versiones distribuido Git" . Itjobswatch.co.uk. Archivado del original el 8 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  115. ↑ "Empleos en Team Foundation Server, salario promedio para profesionales con habilidades en Microsoft Team Foundation Server (TFS)" . Itjobswatch.co.uk. Archivado del original el 29 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  116. ↑ "Empleos en Subversion, salario promedio para profesionales con conocimientos de Apache Subversion (SVN)" . Itjobswatch.co.uk. Archivado del original el 25 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  117. ↑ "Empleos volátiles, salario promedio para habilidades volátiles" . Itjobswatch.co.uk. Archivado del original el 23 de septiembre de 2016. Consultado el 30 de septiembre de 2016 .
  118. ↑ "Empleos en VSS/SourceSafe, salario promedio para profesionales con conocimientos de Microsoft Visual SourceSafe (VSS)" . Itjobswatch.co.uk. Archivado del original el 29 de octubre de 2016. Consultado el 30 de septiembre de 2016 .
  119. ↑ "Windows migra a Git casi completa: 8500 confirmaciones y 1760 compilaciones diarias" . Ars Technica . 24 de mayo de 2017. Archivado del original el 24 de mayo de 2017. Consultado el 24 de mayo de 2017 .
  120. ↑ "git-init" . Git . Archivado del original el 15 de marzo de 2022.
  121. ↑ "Git – Ramas en pocas palabras" . Git . Archivado del original el 20 de diciembre de 2020. Recuperado el 15 de junio de 2020. La rama "master" en Git no es una rama especial. Es exactamente igual que cualquier otra rama. La única razón por la que casi todos los repositorios tienen una es que el comando git init la crea por defecto y la mayoría de la gente no se molesta en cambiarla.
  122. ↑ github/renaming , GitHub, 4 de diciembre de 2020, archivado del original el 26 de julio de 2025 , recuperado el 4 de diciembre de 2020
  123. ↑ El nombre de rama predeterminado para los nuevos repositorios ahora es main , GitLab, 22 de junio de 2021, archivado del original el 19 de mayo de 2025 , recuperado el 22 de junio de 2021
  124. ↑ "Git 2.52 lanzado con más preparativos para Git 3.0" . www.phoronix.com . Consultado el 19 de diciembre de 2025 .
  125. ↑ Chacon y Straub 2014 , págs. 103–109.
  126. ↑ "Git Revert | Tutorial de Git de Atlassian" . Atlassian . Archivado del original el 19 de junio de 2025. Recuperado el 25 de agosto de 2025. Revertir tiene dos ventajas importantes sobre restablecer. Primero, no cambia el historial del proyecto, lo que lo convierte en una operación "segura" para confirmaciones que ya se han publicado en un repositorio compartido.
  127. ↑ "Gitflow Workflow | Tutorial de Git de Atlassian" . Atlassian . Consultado el 15 de junio de 2020 .
  128. ↑ Chacon y Straub 2014 , págs. 170–174.
  129. ↑ "Flujo de trabajo de bifurcación | Tutorial de Git de Atlassian" . Atlassian . Archivado del original el 24 de junio de 2020. Consultado el 15 de junio de 2020 .
  130. ↑ "Control de acceso al repositorio Git" . Archivado del original el 14 de septiembre de 2016. Consultado el 6 de septiembre de 2016 .
  131. ↑ Pettersen, Tim (20 de diciembre de 2014). "Protegiendo su servidor Git contra CVE-2014-9390" . Archivado del original el 24 de diciembre de 2014. Recuperado el 22 de diciembre de 2014 .
  132. ↑ Hamano, JC (18 de diciembre de 2014). " [ Anuncio ] Git v2.2.1 (y actualizaciones a versiones anteriores de mantenimiento)" . Grupo de noticias : gmane.linux.kernel . Archivado del original el 19 de diciembre de 2014. Consultado el 22 de diciembre de 2014 . 
  133. ↑ "CVE-2015-7545" . 15 de diciembre de 2015. Archivado del original el 26 de diciembre de 2015. Consultado el 26 de diciembre de 2015 .
  134. ↑ "Git 2.6.1" . GitHub . 29 de septiembre de 2015. Archivado del original el 11 de abril de 2016. Consultado el 26 de diciembre de 2015 .
  135. 1 2 3 Blake Burkhart; et al. (5 de octubre de 2015). "Re: Solicitud CVE: git" . Archivado del original el 27 de diciembre de 2015. Recuperado el 26 de diciembre de 2015 . 
  136. ↑ "hash – ¿Qué tan seguras son las etiquetas git firmadas? ¿Tan seguras como SHA-1 o de alguna manera más seguras?" . Information Security Stack Exchange. 22 de septiembre de 2014. Archivado del original el 24 de junio de 2016.
  137. ↑ "¿Por qué Git usa una función hash criptográfica?" . Stack Overflow. 1 de marzo de 2015. Archivado del original el 1 de julio de 2016.
  138. ↑ "Git – documentación de transición de función hash" . Git .
  • Sitio web oficialEdita esto en Wikidata
Lecturas relacionadas
6 articulos
Software systemSoftware systemA software system is a system of intercommunicating components based on software forming part of a computer system (a combination of hardware and s...Control de versiones distribuidoEn el desarrollo de software , el control de versiones distribuido (también conocido como control de revisión distribuido ) es una forma de control...Control de versionesControl de versionesEl control de versiones (también conocido como control de revisión , control de código fuente y gestión de código fuente ) es la práctica de ingeni...Código fuenteEjemplo de código fuente simple en lenguaje C , un lenguaje de programación procedimental . El programa resultante imprime "hola, mundo" en la pant...ProgramadorProgramadorUn programador , programador de computadoras o codificador es un autor de código fuente de computadora : alguien con habilidades en programación de...Desarrollo de softwareDesarrollo de softwareEl desarrollo de software es el proceso utilizado para crear software. La programación y el mantenimiento del código fuente es el paso central de e...