Git ( / ɡ ɪ t / ) [7] es un software para rastrear cambios en cualquier conjunto de archivos , generalmente utilizado para coordinar el trabajo entre programadores que desarrollan código fuente en colaboración durante el desarrollo del software . Sus objetivos incluyen la velocidad, la integridad de los datos y la compatibilidad con flujos de trabajo distribuidos y no lineales (miles de ramas paralelas que se ejecutan en diferentes sistemas). [8] [9] [10]
Autor (es) original (es) | Linus Torvalds [1] |
---|---|
Desarrollador (es) | Junio Hamano y otros [2] |
Versión inicial | 7 de abril de 2005 |
Lanzamiento estable | 2.32.0 [3] / 6 de junio de 2021 |
Repositorio | |
Escrito en | C , Shell , Perl , Tcl [4] |
Sistema operativo | POSIX ( Linux , macOS , Solaris , AIX ), Windows |
Disponible en | inglés |
Tipo | Control de versiones |
Licencia | GPLv2 , [5] LGPLv2.1 , [6] y otros |
Sitio web | git-scm |
Git fue creado por Linus Torvalds en 2005 para el desarrollo del kernel de Linux , con otros desarrolladores de kernel contribuyendo a su desarrollo inicial. [11] Desde 2005, Junio Hamano ha sido el mantenedor principal. Como con la mayoría de los otros sistemas de control de versiones distribuidos , ya diferencia de la mayoría de los sistemas cliente-servidor , cada directorio Git en cada computadora es un repositorio completo con historial completo y capacidades de seguimiento de versiones completas, independientemente del acceso a la red o un servidor central. [12] Git es un software gratuito y de código abierto distribuido bajo la Licencia Pública General GNU Versión 2 .
Historia
El desarrollo de Git comenzó en abril de 2005, después de que muchos desarrolladores del kernel de Linux renunciaran al acceso a BitKeeper , un sistema propietario de gestión de control de fuente (SCM) que habían estado utilizando para mantener el proyecto desde 2002. [13] [14] Los derechos de autor El titular de BitKeeper, Larry McVoy , había retirado el uso gratuito del producto después de afirmar que Andrew Tridgell había creado SourcePuller mediante ingeniería inversa de los protocolos de BitKeeper. [15] El mismo incidente también estimuló la creación de otro sistema de control de versiones, Mercurial .
Linus Torvalds quería un sistema distribuido que pudiera usar como BitKeeper, pero ninguno de los sistemas gratuitos disponibles satisfacía sus necesidades. Torvalds citó un ejemplo de un sistema de gestión de control de fuente que necesita 30 segundos para aplicar un parche y actualizar todos los metadatos asociados, y señaló que esto no se adaptaría a las necesidades del desarrollo del kernel de Linux, donde la sincronización con otros mantenedores podría requerir 250 acciones de este tipo en una vez. Para su criterio de diseño, especificó que el parcheo no debería tomar más de tres segundos, y agregó tres puntos más: [8]
- Tome el sistema de versiones concurrentes (CVS) como ejemplo de lo que no se debe hacer; en caso de duda, tome la decisión exactamente opuesta. [10]
- Admite un flujo de trabajo distribuido similar a BitKeeper . [10]
- Incluya salvaguardias muy sólidas contra la corrupción, ya sea accidental o malintencionada. [9]
Estos criterios eliminaron todos los sistemas de control de versiones en uso en ese momento, por lo que inmediatamente después del lanzamiento de desarrollo del kernel de Linux 2.6.12-rc2, Torvalds se propuso escribir el suyo propio. [10]
El desarrollo de Git comenzó el 3 de abril de 2005. [16] Torvalds anunció el proyecto el 6 de abril y se convirtió en autohospedado al día siguiente. [17] [16] La primera fusión de múltiples sucursales tuvo lugar el 18 de abril. [18] Torvalds logró sus objetivos de rendimiento; el 29 de abril, se realizó una evaluación comparativa del Git naciente grabando parches en el árbol del kernel de Linux a una velocidad de 6.7 parches por segundo. [19] El 16 de junio, Git administró la versión 2.6.12 del kernel. [20]
Torvalds entregó el mantenimiento el 26 de julio de 2005 a Junio Hamano, uno de los principales contribuyentes al proyecto. [21] Hamano fue responsable de la versión 1.0 el 21 de diciembre de 2005 y sigue siendo el responsable principal del proyecto. [22]
Nombrar
Torvalds bromeó sarcásticamente sobre el nombre git (que significa "persona desagradable" en la jerga del inglés británico ): "Soy un bastardo egoísta, y nombro todos mis proyectos como yo mismo. Primero ' Linux ', ahora 'git'". [23] [24] La página de manual describe a Git como "el rastreador de contenido estúpido". [25] El archivo read-me del código fuente se elabora con más detalle: [26]
"git" puede significar cualquier cosa, dependiendo de tu estado de ánimo.
- Combinación aleatoria de tres letras que se puede pronunciar y que no se utiliza en ningún comando común de UNIX. El hecho de que sea una mala pronunciación de "get" puede ser relevante o no.
- Estúpido. Despreciable y despreciable. Sencillo. Elige del diccionario de jerga.
- "Rastreador de información global": estás de buen humor y realmente funciona para ti. Los ángeles cantan y una luz llena de repente la habitación.
- "Maldito camión de mierda idiota": cuando se rompe.
Lanzamientos
Lista de lanzamientos de Git: [27]
Versión | Fecha de lanzamiento original | Última versión (parche) | Fecha de lanzamiento (del parche) | Cambios notables |
---|---|---|---|---|
0,99 | 2005-07-11 | 0,99,9 n | 2005-12-15 | |
1.0 | 2005-12-21 | 1.0.13 | 2006-01-27 | |
1.1 | 2006-01-08 | 1.1.6 | 2006-01-30 | |
1.2 | 2006-02-12 | 1.2.6 | 2006-04-08 | |
1.3 | 2006-04-18 | 1.3.3 | 2006-05-16 | |
1.4 | 2006-06-10 | 1.4.4.5 | 2008-07-16 | |
1,5 | 2007-02-14 | 1.5.6.6 | 2008-12-17 | |
1,6 | 2008-08-17 | 1.6.6.3 | 2010-12-15 | |
1,7 | 2010-02-13 | 1.7.12.4 | 2012-10-17 | |
1.8 | 2012-10-21 | 1.8.5.6 | 2014-12-17 | |
1,9 | 2014-02-14 | 1.9.5 | 2014-12-17 | |
2.0 | 2014-05-28 | 2.0.5 | 2014-12-17 | |
2.1 | 2014-08-16 | 2.1.4 | 2014-12-17 | |
2.2 | 2014-11-26 | 2.2.3 | 2015-09-04 | |
2.3 | 2015-02-05 | 2.3.10 | 2015-09-29 | |
2.4 | 2015-04-30 | 2.4.12 | 2017-05-05 | |
2.5 | 2015-07-27 | 2.5.6 | 2017-05-05 | |
2.6 | 2015-09-28 | 2.6.7 | 2017-05-05 | |
2,7 | 2015-10-04 | 2.7.6 | 2017-07-30 | |
2.8 | 2016-03-28 | 2.8.6 | 2017-07-30 | |
2.9 | 2016-06-13 | 2.9.5 | 2017-07-30 | |
2.10 | 2016-09-02 | 2.10.5 | 2017-09-22 | |
2.11 | 2016-11-29 | 2.11.4 | 2017-09-22 | |
2.12 | 2017-02-24 | 2.12.5 | 2017-09-22 | |
2.13 | 2017-05-10 | 2.13.7 | 2018-05-22 | |
2.14 | 2017-08-04 | 2.14.6 | 2019-12-07 | |
2.15 | 2017-10-30 | 2.15.4 | 2019-12-07 | |
2.16 | 2018-01-17 | 2.16.6 | 2019-12-07 | |
2.17 | 2018-04-02 | 2.17.6 | 2021-03-09 | |
2.18 | 2018-06-21 | 2.18.5 | 2021-03-09 | |
2.19 | 2018-09-10 | 2.19.6 | 2021-03-09 | |
2,20 | 2018-12-09 | 2.20.5 | 2021-03-09 | |
2.21 | 2019-02-24 | 2.21.4 | 2021-03-09 | |
2.22 | 2019-06-07 | 2.22.5 | 2021-03-09 | |
2.23 | 2019-08-16 | 2.23.4 | 2021-03-09 | |
2,24 | 2019-11-04 | 2.24.4 | 2021-03-09 | |
2,25 | 2020-01-13 | 2.25.5 | 2021-03-09 | La gestión de la tramitación de la compra simplificada es sencilla [28] |
2,26 | 2020-03-22 | 2.26.3 | 2021-03-09 |
[29] |
2,27 | 2020-06-01 | 2.27.1 | 2021-03-09 | |
2,28 | 27 de julio de 2020 | 2.28.1 | 2021-03-09 |
[30] |
2,29 | 2020-10-19 | 2.29.3 | 2021-03-09 |
[31] |
2.30 | 2020-12-27 | 2.30.2 | 2021-03-09 |
[32] |
2,31 | 15/03/2021 | 2.31.1 | 2021-04-02 |
[33] |
Leyenda: Versión antigua Versión anterior, aún mantenida Ultima versión Última versión de vista previa | ||||
Fuentes: [34] [35] |
Diseño
El diseño de Git se inspiró en BitKeeper y Monotone . [36] [37] Git fue diseñado originalmente como un motor de sistema de control de versiones de bajo nivel, sobre el cual otros podían escribir interfaces , como Cogito o StGIT . [37] El proyecto central de Git se ha convertido desde entonces en un completo sistema de control de versiones que se puede usar directamente. [38] Aunque fuertemente influenciado por BitKeeper, Torvalds evitó deliberadamente los enfoques convencionales, lo que llevó a un diseño único. [39]
Caracteristicas
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 del mismo proyecto y la urgente necesidad de producir un sistema que funcione en poco tiempo. Estas influencias llevaron a las siguientes opciones de implementación: [40]
- Fuerte apoyo para el desarrollo no lineal
- Git admite la ramificación y la fusión rápidas e incluye herramientas específicas para visualizar y navegar por un historial de desarrollo no lineal. En Git, una suposición fundamental es que un cambio se fusionará con más frecuencia de lo que se escribe, ya que se pasa a varios revisores. En Git, las ramas son muy ligeras: una rama es solo una referencia a una confirmación. Con sus confirmaciones parentales, se puede construir la estructura de rama completa. [ síntesis incorrecta? ]
- Desarrollo distribuido
- Al igual que Darcs , BitKeeper , Mercurial , Bazaar y Monotone , Git le da 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 combinar de la misma manera que una rama desarrollada localmente. [41]
- Compatibilidad con sistemas y protocolos existentes.
- Los repositorios se pueden publicar mediante 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 de Git. Los repositorios de Subversion se pueden usar directamente con git-svn. [42]
- Manejo eficiente de grandes proyectos
- Torvalds ha descrito a Git como muy rápido y escalable, [43] y las pruebas de rendimiento realizadas por Mozilla [44] mostraron que era un orden de magnitud más rápido que algunos sistemas de control de versiones; recuperar el historial de versiones de un repositorio almacenado localmente puede ser cien veces más rápido que recuperarlo del servidor remoto. [45]
- Autenticación criptográfica del historial
- El historial de Git se almacena de tal manera que el ID de una versión en particular (una confirmación en términos de Git) depende del historial de desarrollo completo que lleva a esa confirmación. Una vez publicado, no es posible cambiar las versiones antiguas sin que se note. La estructura es similar a un árbol Merkle , pero con datos agregados en los nodos y hojas. [46] ( Mercurial y Monotone también tienen esta propiedad).
- Diseño basado en 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. [47] Aunque la mayoría de esos scripts se han reescrito desde entonces en C para mayor velocidad y portabilidad, el diseño permanece y es fácil encadenar los componentes juntos. [48]
- Estrategias de fusión conectables
- Como parte del diseño de su kit de herramientas, Git tiene un modelo bien definido de una combinación incompleta y tiene múltiples algoritmos para completarlo, que culminan con decirle al usuario que no puede completar la combinación automáticamente y que se necesita una edición manual. [49]
- La basura se acumula hasta que se recoge
- Abortar operaciones o deshacer cambios dejará objetos inútiles colgando en la base de datos. Por lo general, se trata de una pequeña fracción de la historia en continuo crecimiento de los objetos buscados. 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
. [50] - Embalaje de objetos explícito periódico
- Git almacena cada objeto recién creado como un archivo separado. Aunque se comprime individualmente, ocupa mucho espacio y es ineficaz. Esto se resuelve mediante el uso de paquetes que almacenan una gran cantidad de objetos comprimidos en delta entre ellos en un archivo (o flujo de bytes de red) llamado archivo de paquete . Los paquetes se comprimen utilizando la heurística de que los archivos con el mismo nombre probablemente sean similares, sin depender de esto para que sean correctos. Se crea un archivo de índice correspondiente para cada archivo de paquete, indicando el desplazamiento de cada objeto en el archivo de paquete. 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 resultar muy costoso desde el punto de vista computacional. Al permitir que los objetos existan en el repositorio en un formato suelto pero generado rápidamente, Git permite diferir la costosa operación del paquete hasta más tarde, cuando el tiempo importa menos, por ejemplo, el final de un día de trabajo. Git realiza el reempaquetado periódico de forma automática, pero el reempaquetado manual también es posible con el
git gc
comando. Para la integridad de los datos, tanto el archivo de paquete como su índice tienen una suma de verificación SHA-1 dentro, y el nombre de archivo del archivo de paquete también contiene una suma de verificación SHA-1. Para verificar la integridad de un repositorio, ejecute elgit fsck
comando. [51]
Otra propiedad de Git es que toma instantáneas de árboles de directorios de archivos. Los primeros sistemas para rastrear versiones de código fuente, Source Code Control System (SCCS) y Revision Control System (RCS), trabajaron en archivos individuales y enfatizaron el ahorro de espacio que se puede obtener de los deltas intercalados (SCCS) o la codificación delta (RCS). Versiones (en su mayoría similares). Los sistemas de control de revisiones posteriores mantuvieron esta noción de un archivo que tiene una identidad a través de múltiples revisiones de un proyecto. Sin embargo, Torvalds rechazó este concepto. [52] En consecuencia, Git no registra explícitamente las relaciones de revisión de archivos en ningún nivel por debajo del árbol del código fuente.
Estas relaciones de revisión implícitas tienen algunas consecuencias importantes:
- Es un poco más costoso examinar el historial de cambios de un archivo que todo el proyecto. [53] 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 examinar el historial permite que Git produzca con la misma eficiencia un historial único que muestre los cambios en un conjunto arbitrario de archivos. Por ejemplo, un subdirectorio del árbol de origen 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 revisión, por lo que no es posible mover o cambiar el nombre de un archivo sin interrumpir su historial o renombrar el historial 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 considera una ventaja. [54] [55] Los archivos de código fuente a veces se dividen o combinan, o simplemente se renombran, [56] y registrar esto como un simple cambio de nombre congelaría una descripción inexacta de lo que sucedió en el historial (inmutable). Git soluciona el problema detectando cambios de nombre mientras explora el historial de instantáneas en lugar de grabarlo al hacer la instantánea. [57] (Brevemente, 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 existía solo en la revisión N - 1 y es muy similar al nuevo archivo.) Sin embargo, requiere más trabajo 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 lee como una eliminación del archivo anterior y la creación de un nuevo archivo. Los desarrolladores pueden solucionar esta limitación confirmando el cambio de nombre y los cambios por separado.
Git implementa varias estrategias de fusión; se puede seleccionar una estrategia no predeterminada en el momento de la fusión: [58]
- 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 hay más de un ancestro común que se puede usar para una combinación de tres vías, crea un árbol combinado de los ancestros comunes y lo usa como árbol de referencia para la combinación de tres vías. Se ha informado que esto da como resultado menos conflictos de fusión sin causar fusiones incorrectas mediante pruebas realizadas en confirmaciones de fusión anteriores tomadas del historial de desarrollo del kernel de Linux 2.6. Además, esto puede detectar y manejar fusiones que implican cambios de nombre.
- Linus Torvalds [59] - pulpo : este es el valor predeterminado cuando se combinan 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: [60]
En muchos sentidos, puede ver a git como un sistema de archivos: es direccionable por contenido y tiene una noción de control de versiones, pero realmente lo diseñé desde el punto de vista del problema desde el punto de vista de una persona del sistema de archivos (hey, kernels es lo que hago) y, de hecho, 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 que se esperan de un SCM tradicional, [38] con características que en su mayoría se crean según sea necesario, luego se refinan y amplían con el tiempo.
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 a confirmar; y una base de datos inmutable de objetos de solo anexión .
El índice sirve como punto de conexión entre la base de datos de objetos y el árbol de trabajo.
La base de datos de objetos contiene cinco tipos de objetos: [61] [51]
- Un blob ( objeto binario grande ) es el contenido de un archivo . Los blobs no tienen un nombre de archivo, marcas de tiempo u otros metadatos adecuados (el nombre de un blob es internamente un hash de su contenido). En git, cada blob es una versión de un archivo, contiene los datos del archivo.
- Un objeto de árbol es el equivalente a un directorio. Contiene una lista de nombres de archivos, cada uno con algunos bits de tipo y una referencia a un objeto blob o árbol que es ese archivo, enlace simbólico o contenido del directorio. Estos objetos son una instantánea del árbol de origen. (En total, esto comprende un árbol Merkle , lo que significa que solo un solo hash para el árbol raíz es suficiente y realmente se usa en confirmaciones para identificar con precisión el estado exacto de las estructuras del árbol completo de cualquier número de subdirectorios y archivos).
- Un objeto de confirmación vincula los objetos del árbol en el historial. Contiene el nombre de un objeto de árbol (del directorio de origen de nivel superior), una marca de tiempo, un mensaje de registro y los nombres de cero o más objetos de confirmación principales.
- Un objeto de etiqueta es un contenedor que contiene una referencia a otro objeto y puede contener metadatos agregados relacionados con otro objeto. Más comúnmente, se usa para almacenar una firma digital de un objeto de confirmación correspondiente a una versión particular de los datos que Git rastrea.
- Un objeto de archivo de paquete es una versión zlib comprimida de varios otros objetos para compacidad y facilidad de transporte a través de protocolos de red.
Cada objeto se identifica por un SHA-1 de hash de su contenido. Git calcula el hash y usa 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, almacenando blobs a medida que cambian 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: [62]
- Cabezas (ramas) : referencias con nombre que avanzan automáticamente a la nueva confirmación cuando se realiza una confirmación sobre ellas.
- HEAD : un encabezado reservado que se comparará con el árbol de trabajo para crear una confirmación.
- Etiquetas : como referencias de rama pero fijadas a una confirmación en particular. Se utiliza para etiquetar puntos importantes de la historia.
Referencias
Cada objeto en la base de datos de Git al que no se hace referencia puede limpiarse usando un comando de recolección de basura o automáticamente. Un objeto puede ser referenciado por otro objeto o una referencia explícita. Git conoce diferentes tipos de referencias. Los comandos para crear, mover y eliminar referencias varían. "git show-ref" enumera 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,
- alijo : se refiere a un objeto aún no comprometido,
- meta : por ejemplo, una configuración en un repositorio simple, derechos de usuario; el espacio de nombres refs / meta / config se introdujo retrospectivamente, es utilizado por Gerrit , [63]
- etiquetas : ver arriba.
Implementaciones
Git (la implementación principal en C) se desarrolla principalmente en Linux , aunque también es compatible con la mayoría de los principales sistemas operativos, incluidos BSD , Solaris , macOS y Windows . [64]
El primer puerto de Windows de Git fue principalmente un marco de emulación de Linux que aloja 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 el puerto Mingw-w64 de GNU Compiler Collection , 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 o emulaciones de Windows de utilidades y bibliotecas de Linux. Actualmente, las compilaciones nativas de Windows de Git se distribuyen como instaladores de 32 y 64 bits. [65] El sitio web oficial de git actualmente mantiene una compilación de Git para Windows, todavía usando el entorno MSYS2. [66]
La implementación JGit de Git es una biblioteca de software Java pura , 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 de Git para Eclipse IDE. [67]
Go-git es una implementación de código abierto de Git escrita en Go puro . [68] Actualmente se utiliza para respaldar proyectos como una interfaz SQL para repositorios de código Git [69] y proporciona cifrado para Git. [70]
La implementación de Dulwich de Git es un componente de software de Python puro para Python 2.7, 3.4 y 3.5. [71]
La implementación libgit2 de Git es una biblioteca de software ANSI C sin otras dependencias, que se puede construir en múltiples plataformas, incluidas Windows, Linux, macOS y BSD. [72] Tiene enlaces para muchos lenguajes de programación, incluidos Ruby , Python y Haskell . [73] [74] [75]
JS-Git es una implementación de JavaScript de un subconjunto de Git. [76]
GUI de Git
Servidor de Git
Como Git es un sistema de control de versiones distribuido, podría usarse como servidor listo para usar. Se envía con un comando integrado git daemon
que inicia un servidor TCP simple que se ejecuta en el protocolo GIT. [77] Los servidores HTTP dedicados de Git ayudan (entre otras características) al agregar control de acceso, mostrar el contenido de un repositorio de Git a través de las interfaces web y administrar múltiples repositorios. Los repositorios de Git ya existentes se pueden clonar y compartir para que otros los utilicen como un repositorio centralizado. También se puede acceder a él a través de un shell remoto simplemente instalando el software Git y permitiendo que un usuario inicie sesión. [78] Los servidores Git generalmente escuchan en el puerto TCP 9418. [79]
Fuente abierta
- Alojar el servidor Git usando Git Binary. [80]
- Gerrit , un servidor git configurable para admitir revisiones de código y proporcionar acceso a través de ssh, un Apache MINA u OpenSSH integrado, o un servidor web Jetty integrado . Gerrit proporciona integración para LDAP, Active Directory, OpenID, OAuth, Kerberos / GSSAPI, certificados de cliente https X509. Con Gerrit 3.0, todas las configuraciones se almacenarán como repositorios git, no se requiere una base de datos para ejecutarse. Gerrit tiene una función de solicitud de extracción implementada en su núcleo, pero carece de una GUI para ella.
- Phabricator , un derivado de Facebook. Como Facebook usa principalmente Mercurial , el soporte de git no es tan prominente. [81]
- RhodeCode Community Edition (CE), compatible con git, Mercurial y Subversion con una licencia AGPLv3 .
- Kallithea , compatible con git y Mercurial , desarrollado en Python con licencia GPL .
- Proyectos externos como gitolite, [82] que proporcionan scripts sobre el software git para proporcionar un control de acceso detallado.
- Hay varias otras soluciones FLOSS para autohospedaje , incluidas Gogs [83] y Gitea , una bifurcación de Gogs, ambas desarrolladas en lenguaje Go con licencia MIT .
Servidor Git como servicio
Hay muchas ofertas de repositorios de Git como servicio. Los más populares son GitHub , SourceForge , Bitbucket y GitLab . [84] [85] [86] [87] [88]
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 los desarrolladores de software profesionales que informan que utilizan Git como su principal sistema de control de fuentes [89]. en comparación con el 36,3% en 2013, 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. [90] El directorio de código abierto Black Duck Open Hub informa una aceptación similar entre los proyectos de código abierto. [91]
Stack Overflow ha incluido el control de versiones en su encuesta anual para desarrolladores [92] en 2015 (16.694 respuestas), [93] 2017 (30.730 respuestas) [94] y 2018 (74.298 respuestas). [95] Git fue el favorito abrumador de los desarrolladores que respondieron a estas encuestas, informando hasta un 87,2% en 2018.
Sistemas de control de versiones utilizados por los desarrolladores que respondieron:
Nombre | 2015 | 2017 | 2018 |
---|---|---|---|
Git | 69,3% | 69,2% | 87,2% |
Subversión | 36,9% | 9,1% | 16,1% |
TFVC | 12,2% | 7,3% | 10,9% |
Mercurial | 7,9% | 1,9% | 3,6% |
CVS | 4,2% | [I] | [I] |
Forzosamente | 3,3% | [I] | [I] |
VSS | [I] | 0,6% | [I] |
ClearCase | [I] | 0,4% | [I] |
Copias de seguridad de archivos zip | [I] | 2,0% | 7,9% |
Compartir red sin procesar | [I] | 1,7% | 7,9% |
Otro | 5,8% | 3,0% | [I] |
Ninguno | 9,3% | 4,8% | 4,8% |
El sitio web de trabajos de TI del Reino Unido itjobswatch.co.uk informa que, a finales de septiembre de 2016, el 29,27% de las vacantes de trabajo de desarrollo de software permanentes del Reino Unido han citado a Git, [96] por delante del 12,17% para Microsoft Team Foundation Server , [97] 10,60% para Subversion , [98] 1,30% para Mercurial , [99] y 0,48% para Visual SourceSafe . [100]
Extensiones
Hay 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 se puede fusionar 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 una herramienta para automatizar operaciones de rebase / merge / pull / push
Microsoft desarrolló la extensión Virtual File System para Git (VFS para 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 para Git permite que los repositorios clonados utilicen marcadores de posición cuyos contenidos se descargan solo una vez que se accede a un archivo. [101]
Convenciones
Git no impone muchas restricciones sobre cómo debe usarse, pero se adoptan algunas convenciones para organizar las historias, especialmente aquellas que requieren la cooperación de muchos colaboradores.
- La rama maestra se crea de forma predeterminada con git init y a menudo se usa como la rama en la que se fusionan otros cambios. [102] En consecuencia, el nombre predeterminado del control remoto ascendente es origen y, por lo tanto, el nombre de la rama remota predeterminada es origen / maestro . Algunos usuarios prefieren nombres de sucursales predeterminados alternativos. [103] A partir de 2020, los nuevos repositorios de GitHub nombran la rama principal predeterminada . [104]
- Commit Empujado por lo general no se deben sobrescribir, sino más bien deben ser revert ed [105] (una confirmación se hace en la parte superior que revierte los cambios a un cometer antes). Esto evita que las nuevas confirmaciones compartidas basadas en confirmaciones compartidas no sean válidas porque la confirmación en la que se basan no existe en el control 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 de git-flow [106] y las convenciones de nomenclatura a menudo se adoptan para distinguir historias inestables específicas de características (característica / *), historias compartidas inestables (desarrollo), historias listas para producción (maestro) y parches de emergencia para productos lanzados (revisión).
- Las solicitudes de extracción no son una característica de git, pero generalmente las proporcionan los servicios en la nube de git. Una solicitud de extracción es una solicitud de un usuario para fusionar una rama de su bifurcación de repositorio en otro repositorio que comparte el mismo historial (llamado control remoto ascendente ). [107] La función subyacente de una solicitud de extracción no es diferente a la de un administrador de un repositorio que extrae cambios de otro remoto (el repositorio que es la fuente de la solicitud de extracción). Sin embargo, la solicitud de extracción en sí es un ticket administrado por el servidor de alojamiento que inicia scripts para realizar 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 que se especializan en el control de acceso. [108]
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 realizar la ejecución de código arbitrario en una computadora de destino con Git instalado creando un árbol (directorio) de Git malicioso llamado .git (un directorio en los repositorios de 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 creado por el atacante o en un repositorio que el atacante pueda modificar. Si un usuario de Windows o Mac extrae (descarga) una versión del repositorio con el directorio malicioso, luego cambia a ese directorio, el directorio .git se sobrescribirá (debido al rasgo que no distingue entre mayúsculas y minúsculas de los sistemas de archivos de Windows y Mac) y el Se pueden ejecutar archivos ejecutables maliciosos en .git / hooks , lo que resulta 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 de Git maliciosos (alias para comandos de Git o comandos externos) o modificar los 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. [109] [110]
La versión 2.6.1 de Git, lanzada el 29 de septiembre de 2015, contenía un parche para una vulnerabilidad de seguridad ( CVE - 2015-7545 ) [111] que permitía la ejecución de código arbitrario. [112] La vulnerabilidad era explotable si un atacante podía convencer a una víctima de que clonara una URL específica, ya que los comandos arbitrarios estaban incrustados en la propia URL. [113] Un atacante podría usar el exploit a través de un ataque man-in-the-middle si la conexión no estuviera encriptada, [113] ya que podrí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. [113]
Git usa hash 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 fue solo un efecto secundario accidental, y la seguridad principal fue firmar en otro lugar. [114] [115] Desde una demostración del ataque SHAtter contra git en 2017, git se modificó para usar una variante SHA-1 resistente a este ataque. Se está redactando un plan para la transición de la función hash desde febrero de 2020. [116]
Marca comercial
"Git" es una marca comercial registrada de Software Freedom Conservancy bajo US500000085961336 desde 2015-02-03.
Ver también
- Comparación de software de control de versiones
- Comparación de las instalaciones de alojamiento de código fuente
- Lista de software de control de versiones
Notas
- ^ a b c d e f g h i j k No aparece como una opción en esta encuesta
Referencias
- ^ "Revisión inicial de" git ", el administrador 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 .
- ^ "Gráfico de compromiso" . GitHub . 8 de junio de 2016. Archivado desde el original el 20 de enero de 2016 . Consultado el 19 de diciembre de 2015 .
- ^ "[ANUNCIO] Git v2.32.0" . Consultado el 6 de junio de 2021 .
- ^ "Espejo de código fuente de Git" . Archivado desde el original el 8 de febrero de 2017 . Consultado el 1 de enero de 2017 .
- ^ "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 .
- ^ "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 .
- ^ "Charla técnica: Linus Torvalds en git (a las 00:01:30)" . Archivado desde el original el 20 de diciembre de 2015 . Consultado el 20 de julio de 2014 , a través de YouTube.
- ^ a b Torvalds, Linus (7 de abril de 2005). "Re: Saga Kernel SCM". linux-kernel (lista de correo). Archivado desde el original el 1 de julio de 2019 . Consultado el 3 de febrero de 2017 . "Así que estoy escribiendo algunos guiones para intentar rastrear las cosas mucho más rápido".
- ^ a b Torvalds, Linus (10 de junio de 2007). "Re: fatal: inconsistencia grave inflar" . git (lista de correo).
- ^ a b c d Linus Torvalds (3 de mayo de 2007). Charla sobre tecnología de Google: Linus Torvalds en 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 .
- ^ "Una breve historia de Git" . Pro Git (2ª ed.). Presione. 2014. Archivado desde el original el 25 de diciembre de 2015 . Consultado el 26 de diciembre de 2015 .
- ^ Chacon, Scott (24 de diciembre de 2014). Pro Git (2ª ed.). Nueva York, NY: Apress . págs. 29-30. ISBN 978-1-4842-0077-3. Archivado desde el original el 25 de diciembre de 2015.
- ^ Brown, Zack (27 de julio de 2018). "Error de BitKeeper de Linus Torvalds" . InfoWorld . LinuxJournal. Archivado desde el original el 13 de abril de 2020 . Consultado el 28 de mayo de 2020 .
- ^ BitKeeper y Linux: ¿el final del camino? | linux.com Archivado el 8 de junio de 2017 en Wayback Machine.
- ^ McAllister, Neil (2 de mayo de 2005). "Error de BitKeeper de Linus Torvalds" . InfoWorld . Archivado desde el original el 26 de agosto de 2015 . Consultado el 8 de septiembre de 2015 .
- ^ a b Torvalds, Linus (27 de febrero de 2007). "Re: Trivia: ¿Cuándo se hospedó git self?" . git (lista de correo).
- ^ Torvalds, Linus (6 de abril de 2005). "Saga Kernel SCM". linux-kernel (lista de correo).
- ^ Torvalds, Linus (17 de abril de 2005). "¡Primera fusión de git de kernel real!" . git (lista de correo).
- ^ Mackall, Matt (29 de abril de 2005). "Mercurial 0.4b vs punto de referencia de patchbomb de git" . git (lista de correo).
- ^ Torvalds, Linus (17 de junio de 2005). "Linux 2.6.12" . git-commits-head (lista de correo).
- ^ Torvalds, Linus (27 de julio de 2005). "Conoce al nuevo mantenedor ..." git (lista de correo).
- ^ Hamano, Junio C. (21 de diciembre de 2005). "Anunciar: Git 1.0.0" . git (lista de correo).
- ^ "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 .
- ^ "Después de la controversia, Torvalds comienza 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 controvertida. Cuando se le preguntó por qué llamó al nuevo software, 'git', jerga británica que significa 'una persona podrida', dijo. Soy un bastardo egoísta, así que nombro todos mis proyectos como yo mismo. Primero Linux, ahora git '.
- ^ "Página del manual de git (1)" . Archivado desde el original el 21 de junio de 2012 . Consultado el 21 de julio de 2012 .
- ^ "Revisión inicial de 'git', el administrador 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 .
- ^ "Lanzamientos · git / Git" . Archivado desde el original el 20 de septiembre de 2017 . Consultado el 26 de marzo de 2017 .
- ^ "Aspectos destacados de Git 2.25" . El blog de GitHub . 13 de enero de 2020. Archivado desde el original el 22 de marzo de 2021 . Consultado el 27 de noviembre de 2020 .
Una comprobación dispersa no es más que una lista de patrones de ruta de archivo que Git debería intentar rellenar en su copia de trabajo cuando revise el contenido de su repositorio. Efectivamente, funciona como un .gitignore, excepto que actúa sobre el contenido de su copia de trabajo, en lugar de su índice.
- ^ "Aspectos destacados de Git 2.26" . El blog de GitHub . 22 de marzo de 2020. Archivado desde el original el 22 de marzo de 2021 . Consultado el 25 de noviembre de 2020 .
Es posible que recuerde cuando Git introdujo 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 actualicémosnos sobre lo que eso significa. El mayor problema con el protocolo antiguo es que el servidor listaría 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 el envío de 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 qué referencias le interesan. 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 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 búsquedas de grandes repositorios mejoran en velocidad, especialmente cuando la búsqueda 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 tendrás que hacer nada! Debido a un diseño inteligente, cualquier cliente que habla el nuevo protocolo puede trabajar sin problemas con servidores nuevos y antiguos, recurriendo al protocolo original si el servidor no lo admite. La única razón del retraso entre la introducción del protocolo y su configuración predeterminada fue permitir que los primeros usuarios descubrieran cualquier error.
- ^ "Aspectos destacados de Git 2.28" . El blog de GitHub . 27 de julio de 2020. Archivado desde el original el 22 de marzo de 2021 . Consultado el 25 de noviembre de 2020 .
- ^ "Aspectos destacados de Git 2.29" . El blog de GitHub . 19 de octubre de 2020. Archivado desde el original el 22 de marzo de 2021 . Consultado el 25 de noviembre de 2020 .
- ^ "Notas de la versión de Git 2.30" . Descargas de Git . 27 de diciembre de 2020. Archivado desde el original el 22 de marzo de 2021 . Consultado el 27 de diciembre de 2020 .
- ^ "Notas de la versión Git 2.31" . Descargas de Git . 3 de abril de 2021 . Consultado el 3 de abril de 2021 .
- ^ "git / git" . GitHub . Archivado desde el original el 8 de febrero de 2017 . Consultado el 1 de diciembre de 2011 .
- ^ Hamano, Junio (21 de noviembre de 2007). "Cómo mantener Git" . GitHub . Archivado desde el original el 22 de marzo de 2021 . Consultado el 1 de agosto de 2020 .
- ^ Torvalds, Linus (5 de mayo de 2006). "Re: [ANUNCIO] Wiki de Git" . linux-kernel (lista de correo). "Algunos antecedentes históricos" sobre los predecesores de Git
- ^ a b Torvalds, Linus (8 de abril de 2005). "Re: Saga Kernel SCM" . linux-kernel (lista de correo). Archivado desde el original el 22 de marzo de 2021 . Consultado el 20 de febrero de 2008 .
- ^ a b Torvalds, Linus (23 de marzo de 2006). "Re: Errores GITtifying GCC y Binutils" . git (lista de correo). Archivado desde el original el 22 de marzo de 2021 . Consultado el 3 de febrero de 2017 .
- ^ Torvalds, Linus (20 de octubre de 2006). "Re: tabla de comparación de VCS" . git (lista de correo). Archivado desde el original el 22 de marzo de 2021 . Consultado el 3 de febrero de 2017 . Una discusión de Git vs. BitKeeper.
- ^ "Git - Una breve historia de Git" . git-scm.com . Archivado desde el original el 22 de marzo de 2021 . Consultado el 15 de junio de 2020 .
- ^ "Git - Flujos de trabajo distribuidos" . git-scm.com . Archivado desde el original el 22 de octubre de 2014 . Consultado el 15 de junio de 2020 .
- ^ Gunjal, Siddhesh (19 de julio de 2019). "¿Qué es la herramienta de control de versiones? Explore Git y GitHub" . Medio . Consultado el 25 de octubre de 2020 .
- ^ Torvalds, Linus (19 de octubre de 2006). "Re: tabla de comparación de VCS" . git (lista de correo).
- ^ 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 .
- ^ Dreier, Roland (13 de noviembre de 2006). "Oh, qué alivio es" . 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 a un servidor remoto.
- ^ "Confianza" . Conceptos de Git . Manual del usuario de Git. 18 de octubre de 2006. Archivado desde el original el 22 de febrero de 2017.
- ^ 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
- ^ iabervon (22 de diciembre de 2005). "¡Git rocas!" . Archivado desde el original el 14 de septiembre de 2016., alabando la capacidad de escritura de Git.
- ^ "Git - Git SCM Wiki" . git.wiki.kernel.org . Consultado el 25 de octubre de 2020 .
- ^ "Manual del usuario de Git" . 10 de marzo de 2020. Archivado desde el original el 10 de mayo de 2020.
- ^ a b "Git - Packfiles" . git-scm.com .
- ^ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de git". linux-kernel (lista de correo).
- ^ Haible, Bruno (11 de febrero de 2007). "¿Cómo acelerar 'git log'?" . git (lista de correo).
- ^ Torvalds, Linus (1 de marzo de 2006). "Re: cambios de nombre impuros / seguimiento del historial" . git (lista de correo).
- ^ Hamano, Junio C. (24 de marzo de 2006). "Re: Errores GITtifying GCC y Binutils" . git (lista de correo).
- ^ Hamano, Junio C. (23 de marzo de 2006). "Re: Errores GITtifying GCC y Binutils" . git (lista de correo).
- ^ Torvalds, Linus (28 de noviembre de 2006). "Re: git y bzr" . git (lista de correo)., al usar
git-blame
para mostrar el código movido entre archivos fuente. - ^ Torvalds, Linus (18 de julio de 2007). "git-merge (1)" . Archivado desde el original el 16 de julio de 2016.
- ^ Torvalds, Linus (18 de julio de 2007). "CrissCrossMerge" . Archivado desde el original el 13 de enero de 2006.
- ^ Torvalds, Linus (10 de abril de 2005). "Re: más actualizaciones de git ..." linux-kernel (lista de correo).
- ^ "Git - Objetos de Git" . git-scm.com .
- ^ "Git - Referencias de Git" . git-scm.com .
- ^ "Formato del archivo de configuración del proyecto" . Revisión del código Gerrit . Archivado desde el original el 3 de diciembre de 2020 . Consultado el 2 de febrero de 2020 .
- ^ "descargas" . Archivado desde el original el 8 de mayo de 2012 . Consultado el 14 de mayo de 2012 .
- ^ "msysGit" . Archivado desde el original el 10 de octubre de 2016 . Consultado el 20 de septiembre de 2016 .
- ^ "Git - Paquete de descarga" . git-scm.com .( código fuente )
- ^ "JGit" . Archivado desde el original el 31 de agosto de 2012 . Consultado el 24 de agosto de 2012 .
- ^ "Git - go-git" . git-scm.com . Consultado el 19 de abril de 2019 .
- ^ "Interfaz SQL para repositorios de Git, escrita en Go". , github.com , consultado el 19 de abril de 2019
- ^ "Keybase lanza git cifrado" . keybase.io . Consultado el 19 de abril de 2019 .
- ^ "Dulwich" . Archivado desde el original el 29 de mayo de 2012 . Consultado el 27 de agosto de 2012 .
- ^ "libgit2" . Archivado desde el original el 11 de abril de 2016 . Consultado el 24 de agosto de 2012 .
- ^ "rugoso" . Archivado desde el original el 24 de julio de 2013 . Consultado el 24 de agosto de 2012 .
- ^ "pygit2" . Archivado desde el original el 5 de agosto de 2015 . Consultado el 24 de agosto de 2012 .
- ^ "hlibgit2" . Archivado desde el original el 25 de mayo de 2013 . Consultado el 30 de abril de 2013 .
- ^ "js-git: una implementación de JavaScript de Git" . Archivado desde el original el 7 de agosto de 2013 . Consultado el 13 de agosto de 2013 .
- ^ "Git - Git Daemon" . git-scm.com . Consultado el 10 de julio de 2019 .
- ^ 4.4 Git en el servidor: configuración del servidor Archivado el 22 de octubre de 2014 en Wayback Machine , Pro Git.
- ^ "1.4 Introducción: instalación de Git" . git-scm.com. Archivado desde el original el 2 de noviembre de 2013 . Consultado el 1 de noviembre de 2013 .
- ^ Chacón, Scott; Straub, Ben (2014). "Git en el servidor - Configuración del servidor" . Pro Git (2ª ed.). Presione. ISBN 978-1484200773.
- ^ Guía del usuario de Diffusion: Repository Hosting Archivado el 20 de septiembre de 2020 en Wayback Machine .
- ^ "Gitolite: Hosting Git Repositories" .
- ^ "Gogs: un servicio de Git autohospedado indoloro" .
- ^ Krill, Paul (28 de septiembre de 2016). "Guerras de repositorios empresariales: GitHub frente a GitLab frente a Bitbucket" . InfoWorld . Consultado el 2 de febrero de 2020 .
- ^ "github.com Análisis competitivo, marketing mix y tráfico" . Alexa . Consultado el 2 de febrero de 2020 .
- ^ "Análisis competitivo de sourceforge.net, marketing mix y tráfico" . Alexa . Archivado desde el original el 20 de octubre de 2020 . Consultado el 2 de febrero de 2020 .
- ^ "Análisis competitivo de bitbucket.org, mezcla de marketing y tráfico" . Alexa . Consultado el 2 de febrero de 2020 .
- ^ "gitlab.com Análisis competitivo, marketing mix y tráfico" . Alexa . Archivado desde el original el 30 de noviembre de 2017 . Consultado el 2 de febrero de 2020 .
- ^ "Resultados de la encuesta comunitaria 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 .
- ^ "Resultados de la encuesta comunitaria de Eclipse 2012" . eclipse.org. Archivado desde el original el 11 de abril de 2016.
- ^ "Comparar repositorios - Open Hub" . Archivado desde el original el 7 de septiembre de 2014.
- ^ "Encuesta anual para desarrolladores de Stack Overflow" . Cambio de pila, 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 codifican en todo el mundo. Cada año, realizamos una encuesta que cubre todo, desde las tecnologías favoritas de los desarrolladores hasta sus preferencias laborales. Este año marca 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.
- ^ "Encuesta de desarrolladores de desbordamiento de pila 2015" . Desbordamiento de pila. Archivado desde el original el 4 de mayo de 2019 . Consultado el 29 de mayo de 2019 .
- ^ "Encuesta de desarrolladores de desbordamiento de pila 2017" . Desbordamiento de pila. Archivado desde el original el 29 de mayo de 2019 . Consultado el 29 de mayo de 2019 .
- ^ "Encuesta de desarrolladores de desbordamiento de pila 2018" . Desbordamiento de pila. Archivado desde el original el 30 de mayo de 2019 . Consultado el 29 de mayo de 2019 .
- ^ "Trabajos de Git (software), salario promedio para las habilidades del sistema de control de versiones distribuidas de Git" . Itjobswatch.co.uk. Archivado desde el original el 8 de octubre de 2016 . Consultado el 30 de septiembre de 2016 .
- ^ "Trabajos de 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 .
- ^ "Trabajos de Subversion, salario promedio 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 .
- ^ "Trabajos mercuriales, salario promedio para habilidades mercuriales" . Itjobswatch.co.uk. Archivado desde el original el 23 de septiembre de 2016 . Consultado el 30 de septiembre de 2016 .
- ^ "Trabajos de VSS / SourceSafe, salario medio para las habilidades de Microsoft Visual SourceSafe (VSS)" . Itjobswatch.co.uk. Archivado desde el original el 29 de octubre de 2016 . Consultado el 30 de septiembre de 2016 .
- ^ "Windows cambia a Git casi completo: 8.500 confirmaciones y 1.760 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 .
- ^ "Git - Ramas en pocas palabras" . git-scm.com . Archivado desde el original el 20 de diciembre de 2020 . Consultado el 15 de junio de 2020 .
La rama "maestra" 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 uno es que el comando git init lo crea de forma predeterminada y la mayoría de las personas no se molestan en cambiarlo.
- ^ "Respecto a la denominación de ramas y Git" . Conservación de la libertad de software . Consultado el 4 de diciembre de 2020 .
- ^ github / renaming , GitHub, 4 de diciembre de 2020 , consultado el 4 de diciembre de 2020
- ^ "Git Revert | Tutorial de Atlassian Git" . Atlassian .
Revertir tiene dos ventajas importantes sobre el reinicio. 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.
- ^ "Flujo de trabajo de Gitflow | Tutorial de Atlassian Git" . Atlassian . Consultado el 15 de junio de 2020 .
- ^ "Flujo de trabajo de bifurcación | Tutorial de Atlassian Git" . Atlassian . Consultado el 15 de junio de 2020 .
- ^ "Control de acceso al repositorio de Git" . Archivado desde el original el 14 de septiembre de 2016 . Consultado el 6 de septiembre de 2016 .
- ^ Pettersen, Tim (20 de diciembre de 2014). "Asegurar su servidor Git contra CVE-2014-9390" . Archivado desde el original el 24 de diciembre de 2014 . Consultado el 22 de diciembre de 2014 .
- ^ Hamano, JC (18 de diciembre de 2014). "[Anuncio] Git v2.2.1 (y actualizaciones de pistas de mantenimiento más antiguas)" . Grupo de noticias : gmane.linux.kernel . Archivado desde el original el 19 de diciembre de 2014 . Consultado el 22 de diciembre de 2014 .
- ^ "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 .
- ^ "Git 2.6.1" . 29 de septiembre de 2015. Archivado desde el original el 11 de abril de 2016 . Consultado el 26 de diciembre de 2015 .
- ^ a b c 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 .
- ^ "hash - ¿Qué tan seguras son las etiquetas git firmadas? ¿Solo tan seguras como SHA-1 o de alguna manera más seguras?" . Intercambio de pilas de seguridad de la información. 22 de septiembre de 2014. Archivado desde el original el 24 de junio de 2016.
- ^ "¿Por qué Git usa una función hash criptográfica?" . Desbordamiento de pila. 1 de marzo de 2015. Archivado desde el original el 1 de julio de 2016.
- ^ "Git - Documentación de transición de función hash" . git-scm.com .
enlaces externos
- Página web oficial
- Git en Open Hub