Herramienta

control de
versiones Git

13 MARCH

UMET
Creado por: Jairo Pasuy

1
GIT

Terminología general o estructura de repositorios.

Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la

eficiencia, la confiabilidad y compatibilidad del mantenimiento de versiones de aplicaciones

cuando estas tienen un gran número de archivos de código fuente. Su propósito es llevar

registro de los cambios en archivos de computadora incluyendo coordinar el trabajo que

varias personas realizan sobre archivos compartidos en un repositorio de código.

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. 3Sin embargo, Git se ha convertido

desde entonces en un sistema de control de versiones con funcionalidad plena. 4Hay algunos

proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del

núcleo Linux. (Torvalds, 2006)

El mantenimiento del software Git está actualmente (2009) supervisado por Junio Hamano,

quien recibe contribuciones al código de alrededor de 280 programadores. En cuanto a

derechos de autor Git es un software libre distribuible bajo los términos de la versión 2 de la

Licencia Pública General de GNU.

2
Características y uso

La principal diferencia entre Git y cualquier otro VCS (incluyendo Subversion y sus amigos)

es la forma en la que manejan sus datos. Conceptualmente, la mayoría de los otros sistemas

almacenan la información como una lista de cambios en los archivos. Estos sistemas (CVS,

Subversion, Perforce, Bazaar, etc.) manejan la información que almacenan como un conjunto

de archivos y las modificaciones hechas a cada uno de ellos a través del tiempo. (Candil,

2018)

Ventajas

 Sistema distribuido, sin un punto central de fallo, que permite el trabajo incluso sin

conexión.

 Superrápido y ligero, optimizado para hacer operaciones de control muy rápidas.

 Crear ramas y mezclarlas es rápido y poco propenso a problemas, al contrario que en

otros sistemas tradicionales.

 La integridad de la información está asegurada gracias a su modelo de

almacenamiento, que permite predecir este tipo de problemas. En sistemas

tradicionales este era un problema grave.

 Permite flujos de trabajo muy flexibles.

 El concepto de área de preparación o staging permite versionar los cambios como nos

convenga, no todo o nada.

 ¡Es gratis! y de código abierto.

3
Desventajas

 Es más complejo que los sistemas centralizados tradicionales porque entran en juego

más repositorios, más operaciones y más posibilidades para trabajar en equipo, que

hay que decidir.

 La curva de aprendizaje es empinada. Lo básico lo aprendes enseguida, pero la

realidad te demuestra que no es suficiente "tocar de oído" con él. La documentación es

tan compleja que muchas veces no resulta de ayuda.

 Los comandos y algunos conceptos que usa pueden llegar a ser confusos, al igual que

algunos mensajes que muestra.

 Por defecto, se lleva mal con archivos binarios muy grandes, como vídeos o

documentos gráficos muy pesados. Por suerte existen soluciones para ello (Git LFS).

Instalación de Git

1. La instalación que se ve a llevar a cabo es en sistema operativo de 64 bits

2. Una vez descargado el instalador escogemos el lugar en donde se va a instalar

3.

4. Escogemos los componentes a utilizar

4
5.

6.

7. Escogemos el editor de preferencia, puede ser visual code, sublime text, etc.

8.

9. Escogemos que Git utilice los certificados propios de ssl

5
 10.

11.

12.

13. Git en funcionamiento luego de terminar la instalación

14.

Sistemas Operativos que soportan

6
  Windows

 Linux

 MacOs

Flujos de trabajo de Git

El flujo de GitHub es un flujo de trabajo ligero basado en ramas que soporta equipos y

proyectos que despliegan frecuentemente.

Puedes adoptar el método de flujo de GitHub para estandarizar como funciona tu equipo y

como colabora con GitHub.

Git-Flow

Creado en 2010 por Vincent Driessen.11 Es el flujo de trabajo más conocido. Está pensado

para aquellos proyectos que tienen entregables y ciclos de desarrollo bien definidos.9Está

basado en dos grandes ramas con infinito tiempo de vida (ramas master y develop) y varias

ramas de apoyo, unas orientadas al desarrollo de nuevas funcionalidades (ramas feature-*),

otras al arreglo de errores (hotfix-*) y otras orientadas a la preparación de nuevas versiones de

producción (ramas release-*). La herramienta gitflow [1] facilita la automatización de las

tareas implicadas en este flujo de trabajo11

Master

Es la rama principal. Contiene el repositorio que se encuentra publicado en producción, por lo

que debe estar siempre estable.

Development

7
Es una rama sacada de Master. Es la rama de integración, todas las nuevas funcionalidades se

deben integrar en esta rama. Luego que se realice la integración y se corrijan los errores (en

caso de haber alguno), es decir que la rama se encuentre estable, se puede hacer un merge de

development sobre la rama Master.

Features

Cada nueva funcionalidad se debe realizar en una rama nueva, específica para esa

funcionalidad. Estas se deben sacar de Development. Una vez que la funcionalidad esté

desarrollada, se hace un merge de la rama sobre Development, donde se integrará con las

demás funcionalidades.

Hotfix

Son errores de software que surgen en producción, por lo que se deben arreglar y publicar de

forma urgente. Es por ello, que son ramas sacadas de Master. Una vez corregido el error, se

debe hacer una unificación de la rama sobre Master. Al final, para que no quede

desactualizada, se debe realizar la unificación de Master sobre Development.

Release

Las ramas de release apoyan la preparación de nuevas versiones de producción. Para ellos se

arreglan muchos errores menores y se preparan adecuadamente los metadatos. Se suelen

originar de la rama develop y deben fusionarse en las ramas master y develop.11

GitHub-Flow

Creado en 2011 por GitHub11 y es la forma de trabajo sugerida por las funcionalidades

propias de GitHub. Está centrado en un modelo de desarrollo iterativo y de despliegue

constante. Está basado en cuatro principios:911

8
Todo lo que está en la rama master está listo para ser puesto en producción

Para trabajar en algo nuevo, debes crear una nueva rama a partir de la rama master con un

nombre descriptivo. El trabajo se irá integrando sobre esa rama en local y regularmente

también a esa rama en el servidor

Cuando se necesite ayuda o información o cuando creemos que la rama está lista para

integrarla en la rama master, se debe abrir una pull request (solicitud de integración de

cambios).

Alguien debe revisar y visar los cambios para fusionarlos con la rama master

Los cambios integrados se pueden poner en producción.

GitHub intenta simplificar la gestión de ramas, trabajando directamente sobre la rama master

y generando integrando las distintas features directamente a esta rama12

GitLab Flow

Creado en 2014 por Gitlab.11Es una especie de extensión de GitHub Flow acompañado de un

conjunto de pautas y mejores prácticas que apuntan a estandarizar aún más el proceso. Al

igual que GitHub Flow propone el uso de ramas de funcionalidad (feature) que se originan a

partir de la rama master y que al finalizarse se mezclan con la rama master. Además introduce

otros tres tipos de ramas:13

Ramas de entorno. Por ejemplo pre-production production. Se crean a partir de la rama master

cuando estamos listos para implementar nuestra aplicación. Si hay un error crítico lo podemos

arreglar en un rama y luego mezclarla en la rama de entorno.

9
Ramas de versión. Por ejemplo 1.5-stable 1.6-stable. El flujo puede incluir ramas de versión

en caso de que el software requiera lanzamientos frecuentes.

One Flow

Creado en 2015 por Adam Ruka. En él cada nueva versión de producción está basada en la

versión previa de producción. La mayor diferencia entre One Flow y Git Flow es que One

Flow no tiene rama de desarrollo.11

La empresa dueña del programa Git es Freelancer (Torvalds, 2006)

Software que los usa como base

Git se ha usado como software base sobre el que se han desarrollado otros proyectos

Gerrit. Aplicación web que permite la revisión de código en equipo para la aprobación o

rechazo de modificaciones. Consiste de un repositorio Git que actúa como intermediario entre

los gits de los desarrolladores y el repositorio Git que usa la integración continua. Los

desarrolladores en lugar de enviar el código al sistema de integración continua lo envían al

repositorio Gerrit donde se han establecido político.14

Las plataformas de forja son plataformas web que ofrecen servicios que permiten el desarrollo

colaborativo de software. Uno de los servicios básicos ofrecidos es crear poder crear

repositorio de software en un sistema de control de versiones concreto. El sistema de control

de versiones más utilizado es Git. Ejemplos de estos servicios son GitLab, Bitbucket y

GitHub. Se han desarrollado varias soluciones que permiten crear automáticamente forjas

software como por ejemplo Gogs, Gitea, RhodeCode Community Edition o las versiones de

plataformas ofrecidas por GitHub (GitHub Enterprise), Gitlab (GitLab CE y GitLab EE) y

Bitbucket.1516

10
SparkleShare. Es un cliente de código abierto que permite usar repositorios Git como

servicios de alojamiento de archivos, permitiendo la sincronización de archivos y

colaboración en la nube de forma similar a Dropbox. Los repositorios Git pueden estar en una

máquina

Linux, generalmente creados con la aplicación Dazzle o en repositorios git alojados en la nube

usando servicios como GitLab, GitHub, Bitbucket o NotABug .1718

git-crypt. Herramienta de git que permite hacer cifrado de forma completamente transparente.

Cuando se hace un git push los ficheros marcados para cifrar se cifren automáticamenteno.

Análogamente se hará cuando se hace un git pull. De esta forma podemos tener un

repositorio que tenga parte de sus archivos cifrados y otra parte sin cifrar. El cifrado se puede

realizar con claves de cifrado simétrico (con GPG) o asimétrico.19

Herramientas, como gitflow , que facilitan la automatización de las tareas implicadas en

cierto/s flujo/s de trabajo.

Versión

La última versión estable es 2.35.1

Tipo de licenciamiento

Creamos choosealicense.com, para ayudarte a entender cómo generar una licencia para tu

código. Una licencia de software les informa a las demás personas lo que pueden y no pueden

hacer con tu código fuente; por lo tanto, es importante tomar una decisión informada.

11
No tienes la obligación de elegir una licencia. Sin embargo, sin una licencia, se aplican las

leyes de derecho de autor predeterminadas, lo que implica que conservas todos los derechos

de tu código fuente, y nadie puede reproducir, distribuir o crear trabajos a partir de tu trabajo.

Si estás creando un proyecto de código abierto, te alentamos fuertemente a que incluyas una

licencia de código abierto. La Guía de código abierto brinda más orientación para elegir la

licencia correcta para tu proyecto.

Idiomas soportados

El idioma es Ingles

Precio

Gratis

Descargas

El sitio de descargas es el sitio oficial:

https://git-scm.com/downloads

Bibliografía
Candil, A. G. (18 de 06 de 2018).
Torvalds, L. (23 de 03 de 2006). Obtenido de https://marc.info/?
l=git&m=114314642000462

12