Usuario:Alvarosparks/pruebas

Git
Información general
Tipo de programa	Control de versiones
Autor	Linus Torvalds
Desarrollador	Junio Hamano, Linus Torvalds
Licencia	GNU GPL v2
Información técnica
Programado en	C, Bourne Shell, Perl
Versiones
Última versión estable	1.7.10.2 (info) ( 11 de mayo de 2012 (12 años y 22 días))
Enlaces
	Sitio web oficial

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. ^[2] Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. ^[3] Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux.

El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hamano, quien recibe contribuciones al código de alrededor de 280 programadores.

Es un software libre distribuido bajo la licencia GNU General Public License versión 2.

Historia[editar]

El desarrollo de Git empezó después de que varios desarrolladores del núcleo de Linux decidieran dejar de dar soporte a BitKeeper, un software propietario que previamente había sido usado para mantener el proyecto. El propietario de los derechos de autor de BitKeeper, Larry McVoy, había retirado el uso gratuito del producto después de darse cuenta de que Andrew Tridge poseía la ingeniería inversa de los protocolos de BitKeeper

Torvalds quería un sistema distribuido que pudiera usar como BitKeeper, pero ninguno de los sistemas libres que había en el mercado se adecuaba a sus necesidades. Para afirmar esto se baso en el ejemplo de que para aplicar un parche o una actualización, estos sistemas tardaban en torno a 30 segundos en completar esta acción. Esto era inviable para el proyecto del núcleo de Linux donde varios desarrolladores podían estar realizando 250 acciones al mismo tiempo. Su meta fue la de construir un sistema capaz de aplicar estos parches en tres segundos.

Torvalds ha bromeado mucho acerca del nombre de “Git”, que en ingles británico significa estúpido. El dijo:

“Soy un bastardo egocéntrico así que pongo mi nombre a todos mis proyectos. Primero Linux y ahora Git ”.

El desarrollo de Git empezó el 3 de Abril del 2005. El proyecto fue anunciado el 6 de Abril y paso a ser autosuficiente al día siguiente.

La primera fusión de ramas fue completada el 18 de Abril. Torvalds alcanzó su objetivo de rendimiento el 29 de Abril cuando consiguió aplicar parches en el núcleo de Linux a razón de 6,7 por segundo.

El 16 de Junio, la versión 2.6.12 del kernel ya estaba gestionada en tu totalidad por Git.

El 26 de Julio, Torvals cedió el mantenimiento de Git a Junio Hamano, el mayor contribuyente del proyecto y quien sigue a cargo actualmente.

Características[editar]

El diseño de Git se basó en BitKeeper y en Monotone. ^[4] ^[5]

Este resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.

Entre las características más relevantes se encuentran:

Fuerte apoyo al desarrollo no-lineal, por ende rapidez en la gestión de ramas y mezclado de diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de desarrollo no-lineal. Una presunción fundamental en Git es que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores que lo revisan.
Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados en la misma manera que se hace con la rama local.
Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y módulos IDE para CVS pre-existentes en el acceso de repositorios Git.
Los repositorios Subversion y svk se pueden usar directamente con git-svn.
Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos, entre otras mejoras de optimización de velocidad de ejecución.
Todas las versiones previas a un cambio determinado, implican la notificación de un cambio posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial). Esto existía en Monotone.
Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el trabajo frente a CVS, que trabaja con base en cambios de fichero, pero mejora el trabajo con afectaciones de código que concurren en operaciones similares en varios archivos.
Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente desastrosas, coincidencias de ficheros diferentes en un único nombre.
Realmacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en diferencias) no ocurre cada cierto tiempo.

Estructuras de datos[editar]

Las primitivas de Git no son inherentes a un sistema de gestión de código, Torvalds explica:

Git puede ser visto de muchas maneras como un sistema de archivos, con contenido direccionable y cierta noción de control de versiones. Pero la verdad es que fue diseñado para ver el problema desde el punto de vista de un sistema de archivos personal y con ninguna intención de ser un sistema de gestión de código tradicional.

Git tiene dos estructuras de datos: un mutable “índex” (también llamado “stage o “cache”) que cachea la información del directorio de trabajo y de la siguiente revisión sobre la que se realizara el commit; y un inmutable “object database”.

El “object database” contiene cuatro tipos de objetos:

Un “objeto blob” que es básicamente el contenido de un archivo. No tiene ningún nombre, ni fecha u otros metadatos.

Un “árbol de objetos” que es equivalente a un directorio. Contiene un listado de nombres de archivo, cada uno con una serie de bits de tipo, el nombre de un objeto blob o árbol al cual pertenece ese archivo, enlace simbólico, o el contenido del directorio.

Un objeto “commit” que enlaza arboles de objetos en un historial. Contiene el nombre del “árbol de objetos”, una fecha, un mensaje de log y los nombres de cero o mas “commits” padre.

Un objeto “tag” que contiene la referencia a otro objeto y puede soportar metadatos adicionales relativos al otro objeto. Comúnmente es usado para guarda una huella digital de un “commit” correspondiente a una versión particular.

El índex sirve como punto de unión entre el “object database” y el árbol de trabajo.

Cada objeto se identifica por una función criptográfica hash SHA-1 de su contenido. Git calcula el hash y lo usa para nombrar al objeto. Este se coloca en un directorio que coincida con los dos primeros caracteres del hash y el resto se utiliza como nombre del archivo correspondiente al objeto.

Git guarda cada revisión de un archivo como un objeto “blob” único. Las relaciones entre objetos “blob” se pueden encontrar examinando los “arboles de objetos” y los “commit”. Los objetos creados recientemente son guardados usando la compresión zlib. Esto puede consumir un gran espacio en disco, por ello estos objetos son agrupados en paquetes usando la compresión delta.

Git normalmente trabaja sobre el puerto 9418 tanto en TCP como UDP.

Implementaciones[editar]

Git esta principalmente desarrollado para Linux, aunque esta soportado por la mayoría de los sistemas operativos incluyendo BSD, Solaris, OS X, y Microsoft Windows

La implementación JGit es una librería de Java diseñada para ser embebida en cualquier aplicación Java. JGit se usa en la herramienta de revisión de código Gerrit y en EGit, un cliente para Eclipse.

La implementación Dulwich es un componente desarrollado en Python.

La implementación libgit2 de Git es una librería en ANSI C que puede ser construida en múltiples plataformas incluyendo Windows, Linux, Mac OSX y BSD. Se utiliza como base para las bibliotecas Git para Ruby, Python y los lenguajes de programación Haskell.

El sistema de control de versiones Plastic SCM implementa su propio protocolo Git para permitir a sus usuarios inter operar con repositorios Git.

El sistema Perforce también soporta clientes Git. Perforce puede hacer que su contenido este disponible como repositorios Git utilizando el protocolo git+ssh y estos repositorios pueden ser usados desde cualquier cliente Git.

Instalación[editar]

Si queréis comenzar a utilizar Git podéis seguir los pasos de la guía de instalación que proporciona la página oficial de Git.

En ellos explica como instalar Git desde cero para todos los sistemas operativos principales existentes en el mercado. Vamos a empezar a usar un poco de Git. Lo primero es lo primero: tienes que instalarlo. Puedes obtenerlo de varias maneras; las dos principales son instalarlo desde código fuente, o instalar un paquete existente para tu plataforma.

Instalando Git por primera vez

Configurando Git por primera vez[editar]

Para configurar Git por primera vez también podéis acudir a la página principal donde encontraréis una guía paso a paso bien explicada.

Configurando Git por primera vez

Adopción[editar]

La fundación Eclipse informó en su encuesta anual que en Mayo del 2012 mas del 27% de los desarrolladores profesionales usan Git como su sistema de control de versiones, un incremento del 12,8% respecto al 2011.

El portal de búsqueda de trabajo del Reino Unido itjobswatch.co.uk informó que en Diciembre del 2012, aproximadamente el 10% de las ofertas de trabajo como desarrollador software requerían de conocimientos de Git

Las siguientes webs proporcionan código fuente libre para el alojamiento de repositorios Git: