Guía introductoria de Git con Interfaz Visual
Siendo estudiante de ingeniería en sistemas, en sucesivas oportunidades me encontré con sistemas de control de versiones, algunas veces desde materias relacionadas con la programación y otras en materias relacionadas con la ingeniería de software.
Recordando que cuando yo tuve que aprender todos estos conceptos (especialmente como funciona Git), pasé por varias dificultades, decidí hacer una guía introductoria con conceptos básicos de Git y cómo utilizarlo mediante un software con interfaz visual.
Personalmente, pienso que para empezar, utilizar una interfaz visual puede ser útil y didáctico, sin embargo, comparto la idea de que entender como funciona la herramienta desde la consola es fundamental para una comprensión profunda de los conceptos.
En este tutorial se verán de manera resumida las características principales de un software particular que personalmente pienso que es el mejor, llamado GitKraken. Esta guía no pretende en ninguna medida ser exhaustiva ni detallada en todas las funciones de GitKraken, sino dar al usuario el conocimiento básico para que pueda usar la herramienta y poco a poco pueda ir explorando las demás características por su cuenta.
Al final del documento se detallan algunas de las funcionalidades avanzadas para que el usuario pueda conocer que otras características tiene Git.
A continuación dejo el índice de contenidos en caso de que se desee saltear a alguna sección determinada
- Introducción a Git
- Fork de un repositorio
- Clonar un repositorio
- 1. Crear un repositorio
- 1 (Alternativa). Crear un repositorio
- 2. Completar la información necesaria
- 3. Obtener URL del Repositorio
- 4. Abrimos la ventana de Clone dentro del GitKraken
- 4 (Alternativa 1). Abrimos la ventana de Clone dentro del GitKraken
- 4 (Alternativa 2). Abrimos la ventana de Clone dentro del GitKraken
- 5. Pegamos la URL
- 5. Notificación de Éxito
- Abrir un repositorio
- Elementos de la interfaz
- Añadir Cambios
- Sincronización con repositorios remotos
- Trabajo en múltiples branches
- Pull Requests
- Características Adicionales
Introducción a Git
Git es una tecnología de sistema de control de versiones (VCS), surge como alternativa a SVN, Hg y TFS y su propósito original fue controlar las versiones del kernel de Linux.
Antes de comenzar con el vocabulario específico es necesario explicar por qué se debe usar git u otro VCS.
Problema: Al estar trabajando en un proyecto, los archivos sufren múltiples transformaciones, esto es especialmente notorio en proyectos de diseño gráfico y de desarrollo de software. Con el avance del tiempo, es normal que se detecten errores y se desee volver a una instancia anterior, muchas veces lo que hace en este caso es hacer copias de respaldo, sin embargo, este enfoque es poco práctico en entornos con cambios constantes y al aumentar la cantidad de archivos y crece de manera sustancial cuando se trabaja en equipos grandes.
Solución de los VCS: Cada sistema propone una solución distinta, en el caso de Git siempre se hablan de cambios a nivel de línea, es decir, un archivo cambia cuando una de sus líneas cambias y si se realizan varios cambios en una misma línea, cuenta como un único cambio. Asimismo, si se realiza un cambio en varias líneas en un mismo archivo, cuentan como varios cambios, tantos como líneas se hayan modificado. Siempre que se hable de cambios se hará con este sentido, cambios en líneas. Esto hace que Git sea sumamente útil para archivos de texto con múltiples líneas (como los archivos fuente de un lenguaje de programación) y poco aplicable a archivos que no siguen este formato (como por ejemplo, los ejecutables, imágenes, etc.)
Areas en Git
Git trabaja principalmente separando los cambios en 3 áreas:
- Working Area: Son los archivos con los que uno está actualmente trabajando.
- Staging Area: Son los próximos cambios que serán guardados en el repositorio.
- Repository: Son los archivos guardados, generalmente local y en internet.
Así mismo, para pasar de un área a otro, existen distintas transiciones. Para pasar del Working Area al Staging Area se realiza un "Stage" y para pasar del Staging Area al repository se realiza un “Commit”
Stage vs Commit
En un proceso, un usuario trabaja con sus archivos en el Working Area, una vez que haya terminado los cambios deseados, puede seleccionar exactamente que cambios desea agregar al repositorio, estos cambios son elegidos y se "mueven" a la Staging Area (el término mover en este caso es engañoso ya que en el sistema local los archivos no sufren ninguna modificación). Una vez que todos los cambios hayan sido movidos al Staging Area se puede realizar un “Commit”, el commit consiste básicamente en “empaquetar todo lo que esté en el Staging Area, asociarle un título y una descripción y subirlo al repositorio”.
Al principio esta forma de trabajo podría dar la impresión de que la Staging Area no cumple ninguna función, sin embargo cobra relevancia especialmente cuando uno quiere realizar un commit con un subconjunto de todos los cambios hechos, por ejemplo, se realizaron cambios en la interfaz gráfica y en la base de datos y uno quiere que cada "paquete de cambios" esté en un commit distinto, para eso, primero movería al Staging Area los cambios de la base de datos, haría el commit y luego repetiría el proceso con los cambios de la interfaz gráfica.
El usuario no está obligado a realizar un commit con todos los cambios. OJO: Uno podría mover al Staging Area sólo un subconjunto de las líneas modificadas en un archivo, es por eso que es importante recordar que el término "cambio" hace referencia a líneas y no a archivos.
Una vez realizado el commit, los cambios quedan definitivamente guardados en el repositorio, el repositorio siempre existe en un nivel local en la máquina del usuario y adicionalmente suele utilizarse una copia de manera remota en algún proveedor que lo permita, los más comunes son GitHub, Gitlab y Bitbucket.
Repositorios remotos
Cuando uno trabaja con un repositorio remoto, surgen tres términos importantes: Pull (Tirar), Push (Empujar) y Clone (Clonar). Como sugieren los nombres, Pull trae los cambios del repositorio remoto y los aplica en el repositorio local, Push sube los cambios del repositorio local al repositorio remoto. Clone, por otro lado, copia el repositorio remoto y crea uno local, esta operación sólo se realiza una vez (No confundir con Fork).
Fork vs Clone: Un Fork es una copia independiente de un repositorio. Cuando uno realiza un Clone, se tiene la intención de trabajar en ese repositorio, cuando uno realiza un Fork se tiene la intención de realizar una variante e independizarse (hasta cierto punto) del repositorio original. Hacer un Fork reemplaza el proceso de creación del repositorio y para hacerlo uno debe ir al repositorio original
NOTA: Siempre y cuando los cambios no se solapen (es decir que dos usuarios no hayan modificado la misma línea), el mismo sistema Git se encarga de combinarlos. Cuando dos o más usuarios modifican la misma línea del mismo archivo es necesaria una "Resolución de conflictos". Es un tema avanzado sin embargo puede requerirse a diario en entornos con múltiples programadores, aquellos que utilicen git como únicos usuarios no deberían preocuparse por este aspecto.
Branches
El último concepto importante son las "branches", esta es la clave de la utilidad de Git, dentro de un repositorio uno puede tener múltiples branches (ramas en español), cada branch permite tener una Working Area independiente, esto se hace para mantener los cambios aislados, si bien el proceso de Stage-Commit es el mismo que el mencionado anteriormente, uno puede desear experimentar una nueva característica pero sin riesgos que se pierda o mezcle con el código que ya funciona correctamente, para eso se hace un nuevo branch y en el caso de éxito, se puede unir (merge en inglés) a la branch principal. Existen múltiples criterios para la creación de branches, algunas organizaciones utilizan una branch por características, otras una branch por desarrollador, etc. A la forma de utilizar las branches se la suele llamar “Git Strategy” o “Git Workflow”, siendo considerada una buena práctica tener un esquema simplificado con las siguientes branches:
- Master: Donde se tiene el código de la última versión estable
- Release: Donde se concentran todos los cambios que estarán en la próxima versión y se realizan las pruebas finales
- Develop: Donde se tiene el código experimental y que aún está siendo probado
- Hot Fix: Donde se reparan errores detectados a posteriori (fuera de las pruebas)
- Features: Una rama independiente por cada característica que se le quiera agregar al software.
Lo anterior puede visualizarse mucho mejor en una imagen. Cada flecha indica una operación de unión (merge)
Software adicional
Git es una aplicación de consola, sin embargo, existen múltiples softwares con interfaz gráfica construidos sobre la aplicación de consola base. En este caso vamos a detallar el uso típico de uno de los más populares: GitKraken
Por cuestiones de simplicidad, se asume que el usuario tiene correctamente instalado el software Gitkraken y que está listo para usarse, por lo tanto no se detallan pasos de instalación y configuración inicial.
Fork de un repositorio
Como se mencionó, un fork es una copia independiente de un repositorio. El repositorio ya tiene su propio creador e historial de branches y commits pero uno desea hacer una copia independiente. Este procedimiento puede variar de un proveedor de repositorios remoto a otro, a continuación se muestra el procedimiento para hacer esto en Github
1. Encontrar el repositorio original
Primero buscamos en Github el repositorio del cual queremos hacer un Fork, en este caso se utilizará el repositorio de Manim, el motor de animaciones creado por 3Blue1Brown
Como se puede ver en la imagen, el creador del repositorio es 3b1b y el usuario logeado actualmente es ELC por lo que el repositorio no es propio.
2. Realizar el Fork
Para hacer un fork, basta con hacer clic en el botón Fork en la parte superior
Inmediatamente después, GitHub nos redireccionará a una pantalla que nos indica que se está creando el Fork
Una vez finalizado el proceso, se creará un repositorio homónimo en la cuenta logeada
Como se puede ver en la imagen anterior, ahora el repositorio pertenece a ELC, con una pequeña leyenda debajo que indica que el repositorio es un Fork. Una muestra de que este repositorio es independiente y pertenece a la cuenta logeada es que aparece una nueva sección "Settings" que de otra forma no aparecería
NOTA: Esta sección podría aparecer si uno fuera colaborador del repositorio, sin embargo esa característica puede variar de proveedor en proveedor y no se detallará en esta guía.
Una última confirmación podría ser el conteo de Forks que es un número común para todos los Forks.
A partir de ahora el avance de este nuevo repositorio puede ser completamente independiente del original.
IMPORTANTE: ¿Cúal es la diferencia entre hacer un fork y crear un repositorio idéntico con los mismos archivos? Al realizar un Fork uno tiene una historia de commits compartida con el repositorio original, de forma tal que es posible combinar cambios nuevos del original a cualquiera de los Forks (merge) y de los Forks de nuevo al original (Pull Request).
El procedimiento alternativo de crear un repositorio desde cero así como clonarno desde GitKraken se detalla en la siguiente sección
Clonar un repositorio
El enfoque más tradicional es crear primeramente el repositorio en el servidor remoto (Github o similar) y luego clonarlo. En este caso vamos a crear un repositorio llamado "gitkraken-tutorial" en Github.
1. Crear un repositorio
Esto puede hacerse desde la página principal de Github
1 (Alternativa). Crear un repositorio
O desde la sección de repositorios
2. Completar la información necesaria
IMPORTANTE: Para poder clonar nuestro repositorio debe estar "Inicializado" por lo tanto, es indispensable tildar la opción “Initialize this repository with a README”. Las opciones de gitignore permiten a git ignorar ciertos archivos (archivos temporales, caches, etc.) y la licencia permite elegir una licencia estándar entre un listado.
3. Obtener URL del Repositorio
Para poder clonar el repositorio desde GitKraken pueden utilizarse dos perspectivas:
- Vincular la cuenta de GitHub con la de Gitkraken
- Utilizar la URL del repositorio
Todos los servicios de repositorios tienen una URL pública así que se tomará este enfoque por ser el más universal. Una vez seguido los pasos en las imágenes, la URL quedará copiada en el portapapeles.
4. Abrimos la ventana de Clone dentro del GitKraken
En el menú File, Seleccionar la opción "Clone Repo"
4 (Alternativa 1). Abrimos la ventana de Clone dentro del GitKraken
En todo momento, se puede utilizar el botón que se encuentra en la esquina superior izquierda
A continuación, se deberá escoger la opción Clone
4 (Alternativa 2). Abrimos la ventana de Clone dentro del GitKraken
En caso de no tener ningún repositorio abierto, puede accederse al menú directamente desde la pantalla de inicio
5. Pegamos la URL
Adicionalmente se puede detallar la ruta donde se clonará el repositorio y así como cambiar el nombre de la carpeta destino. Es recomendable tener una carpeta "Repositories" y clonar todos los repositorios allí.
5. Notificación de Éxito
Una vez clonado el repositorio deberá aparecer en la parte superior una notificación que detalla que la operación fue exitosa. Uno puede utilizar el botón "Open Now" para abrir el repositorio inmediatamente. En este caso no se hará para ilustrar como se abre un repositorio desde cero.
Abrir un repositorio
Una vez clonado el repositorio es necesario abrirlo para empezar a trabajar.
NOTA: El repositorio podría haber sido inicializado en lugar de clonado pero este escenario es poco probable ya que luego se debería realizar una vinculación con el repositorio remoto. Por lo que por lo general se utiliza el enfoque planteado al principio, la inicialización de repositorios queda fuera del alcance de esta guía.
1. Ventana de Open
En el menú File, seleccionar la opción "Open Repo"
1 (Alternativa 1). Ventana de Open
Adicionalmente puede utilizarse el ícono de la esquina superior izquierda
1 (Alternativa 2). Ventana de Open
En caso de no tener ningún repositorio abierto, puede utilizarse el botón de la pantalla de inicio.
2. Seleccionar el repositorio
Se seleccionar "Open a Repository"
3. Seleccionar la carpeta
Navegar hasta la carpeta donde se encuentra el repositorio, una manera fácil de identificarla es que debería verse una carpeta llamada ".git" (Esta carpeta puede no aparecer si uno no tiene habilitados los archivos ocultos de Windows).
Elementos de la interfaz
Interfaz básica
Al abrir un repositorio nos encontraremos con la interfaz básica
Arbol de Commits y Branches
Al tener varios commits y branches, en la parte central, es posible ver las bifurcaciones y las uniones, en la siguiente imagen se muestra un proyecto con varios branches (Sólo a modo de ejemplo).
Añadir Cambios
Las herramientas de git pueden separarse en dos categorías:
- Integradas con los IDE
- Desacopladas
Muchos IDE vienen con su propia integración con Git, algunos ejemplos de esto son Eclipse, Visual Studio, PyCharm. Sin embargo, es posible utilizar aplicaciones completamente desacopladas como Gitkraken, Github Desktop o el mismo git de consola.
Las primeras tienen la ventaja de que el usuario no tiene que salir de la aplicación en la que desarrolla el código y las pruebas, pero tiene la desventaja de que puede confundir fácilmente cual es su branch actual y si el sistema está en un estado consistente, además, cada IDE tendrá su interfaz especial, y los IDE suelen cambiar si se cambia el lenguaje de programación. Por otro lado, las herramientas desacopladas como Gitkraken permiten que el desarrollador utilice el IDE sólo para lo que fue diseñado, la programación, la depuración y las pruebas, abstrayéndose totalmente del sistema de control de versiones, este enfoque tiene como ventaja que el usuario sólo debe preocuparse por el control de versiones al comenzar a trabajar y al momento de hacer los Stage-Commit y que se utiliza la misma interfaz independientemente de que IDE se haya utilizado, pero trae como desventaja que debe contarse con otro software adicional instalado.
Gracias a que Gitkraken tiene este enfoque es posible trabajar como se suele hacer habitualmente en el IDE tradicional y cuando se deseen añadir cambios al repositorio lo que aparecerá será algo como lo siguiente:
La sigla WIP (Work in Progress) hace referencia al Working Area. Al hacer clic en este recuadro se podrá ver en la parte derecha los cambios realizados separados por archivos y también una clara división entre la Working Area y la Staging Area.
Asimismo, es importante aclarar la función de tres botones:
- Cesto de basura en la esquina superior derecha: BORRA todos los cambios del Working Area, usar sólo si se sabe lo que se está haciendo
- Tree: Permite visualizar los archivos en forma de árbol de directorios, dependiendo de la configuración puede no estar seleccionado por defecto, se recomienda utilizarlo
- Stage Files/changes to commit: Genera un commit con el título y la descripción dados de todos los cambios que están en el Staging Area
Si uno hace clic sobre alguno de los archivos ya sea dentro del Working como del Staging Area, puede ver un detalle de los cambios:
Cada línea sombreada con rojo implica que esa línea estaba en la última versión y será eliminada, las sombreadas con verde indican que no estaban en la última versión y serán añadidas. En Git no existe el concepto de modificar una línea por lo tanto si se hace una modificación, se borrará la línea de la versión anterior y se añadirá una idéntica pero con los cambios realizados.
Si uno posiciona el mouse sobre una de esas líneas aparecerá un botón con un signo más (+) que nos permitirá mover líneas individuales al Staging Area:
Gitkraken, a su vez, identifica cambios por secciones en archivos y permite agregar varias secciones al Staging Area
Por último, si uno desea añadir todos los cambios de un archivo al Staging Area, puede posicionar el cursor sobre ese archivo y utilizar el botón "Stage File" que aparecerá. También es posible pasar TODOS los archivos del Working Area al Staging Area con el botón “Stage all Changes”:
El proceso para quitar cambios del Staging Area y pasarlos al Working Area es idéntico, sólo se debe seleccionar primeramente el archivo correspondiente desde el Staging Area, en este caso los botones son de color rojo y el botón con el más (+) pasa a ser un menos (-):
Una vez movidos los cambios deseados al Staging Area, se puede crear el commit deseado, para ello hace falta asignarle un título, también se puede detallar una descripción opcional:
Una vez hecho el commit, aparecerá en la pantalla principal con el nombre que se le haya asignado:
Es importante descatar que esto genera el commit en el repositorio LOCAL y que estos cambios no impactaron aún en el repositorio remoto, Gitkraken nos muestra esto utilizando una computadora para el repositorio Local y el logo del usuario de Github para representar el repositorio remoto. En la siguiente sección se verá como sincronizar ambos repositorios.
Sincronización con repositorios remotos
Como se mencionó antes, para mantener dos repositorios actualizados hace falta utilizar las acciones de Pull y Push
Descargar los cambios del repositorio remoto
Es considerado una buena práctica, siempre antes de subir los cambios, hacer un Pull para traer cualquier cambio que no pudiéramos tener en nuestro equipo local. En esta oportunidad tendremos que distinguir entre la acción Pull y la acción Fetch.
- Fetch: Revisa si hay cambios en el repositorio remoto y nos muestra cual es el estado del remoto con respecto al local
- Pull: Hace Fetch y aplica esos cambios en el repositorio local.
Fetch es por lo tanto una acción completamente segura, mientras que Pull puede traer cambios que generen colisiones con los nuestros, a pesar de que lo anterior no sea frecuente y sólo sea posible en entornos con múltiples usuarios, es considerado una buena práctica que el usuario resuelva los conflictos en su computadora local y que luego pueda subir los cambios. De no ser así, el repositorio remoto podría quedar en un estado inconsistente, deteniendo el avance de los demás miembros del equipo.
En la barra de acciones del Gitkraken tenemos la acción de Fetch:
Para acceder a la acción Pull debemos elegir la flecha que está junto a Fetch:
En el caso del repositorio de ejemplo el Pull debería ser exitoso ya que no hubo cambios en el repositorio remoto
Subir los cambios al repositorio remoto
Para subir los cambios es necesario primero realizar un Pull para resolver los conflictos (si los hubiera) una vez resueltos, se puede realizar un Push utilizando el botón asociado en la barra de acciones:
Una vez realizado, la forma más fácil de verificar que fue exitoso se ver el árbol de commits
En esta oportunidad tanto el logo de usuario de Github como la computadora se encuentran juntos, mostrando así que el contenido se encuentra sincronizado.
Ejemplo de Fetch y Pull
Para ilustrar como se vería una situación inversa (se hicieron cambios en el repositorio remoto y queremos descargarlos). Primeramente hacemos Fetch y veremos algo como lo siguiente:
Como se puede ver, el branch master está "adelantado" y tiene un commit llamado “Update README.md” que sólo está en el repositorio remoto (evidenciado por el logo de la cuenta de Github). Y nuestra versión local está “detrás”. En esta situación debemos evaluar los cambios y si existen conflictos (incluyendo los archivos del Working Area). Es recomendable no tener nada en el Working Area al momento de hacer Pull, es decir, que todos los cambios ya estén dentro de commits, esto simplifica el proceso y disminuye la probabilidad de hallar conflictos.
NOTA: Existen situaciones avanzadas donde uno puede guardar temporalmente los cambios del Working Area en un Stash pero esta característica se encuentra fuera del alcance de esta guía.
En caso de no existir conflictos, se puede realizar un Pull sin problemas:
El resultado es el esperado, tanto el repositorio local como el remoto se encuentran sincronizados.
Trabajo en múltiples branches
Una vez que se pueda trabajar eficientemente en una rama, es sumamente recomendable seleccionar una Git Strategy y utilizar múltiples ramas.
Crear Branch
Para crear rama primero debemos posicionarnos en una rama base, esta es la rama de la cual se bifurcará el nuevo branch
NOTA: Existe el concepto de ramas huérfanas, que son ramas que no se derivan de ninguna otra rama. Sin embargo su uso suele ser muy particular y específico y por ende están fuera del alcance de esta guía.
En este caso vamos a crear una rama de master, le agregaremos dos commits, la uniremos y luego la borraremos.
En primer lugar nos posicionamos en master, para ello bastan con hacer doble clic en "master"
Luego utilizamos el botón "Branch" de la barra de acciones
Luego escribimos el nombre de la rama y presionamos enter:
Gitkraken nos permite ver en varios lugares que la rama fue creada con éxito
Sin embargo, es posible observar que en el árbol de commits no aparece la rama master, esto se debe a que se encuentra oculta en el ícono +1:
Al pasar el cursor por arriba podemos ver que la rama es visible nuevamente:
Esta simplificación de la intefaz se debe a que el contenido de ambas ramas es idéntico (todavía no realizamos cambios) y si bien puede ser un poco confusos para los principiantes es sumamente útil cuando se tienen múltiples ramas. Por otro lado, la ayuda visual de GitKraken nos permite observar que el branch "add-license" sólo existe en el contexto local y que aún no existe en el repositorio remoto.
Unir Branches (Merge)
Para poder unir dos branches es necesario que éstas sean diferentes, para ello se añaden algunos commits a la rama "add-license". Luego de añadir los commits, se obtiene algo como lo siguiente:
Si bien la rama sigue existiendo sólo en el contexto local, es importante ver como se encuentra "adelantada" a la rama master. Si bien en el esquema presentado al principio las ramas se disponen de forma paralela una a la otra, Gitkraken sólo las dispone de esa forma cuando existen varias “líneas de cambios”, es decir, sólo cuando la rama master se haya modificado y que esa modificación no sea alguno de los commits de la rama con la que está alineada (add-license) en este caso. Para ilustrar este ejemplo se añadirá un cambio a la rama master directamente (no en la rama add-license).
Esta forma de visualizar las ramas es más similar a la vista con anterioridad, la vista cambió porque se agregó el commit "Add Contribution Guide" directamente en master.
Antes de unir las ramas vamos a realizar un Push, en este caso, como la rama no existe en el repositorio remoto, nos preguntará si la queremos vincular con alguna rama del repositorio remoto ya existente, en caso de dejar el espacio en blanco y clickear en "Submit", creará una rama homónima en el repositorio remoto.
Ahora ambas ramas están sincronizadas con el repositorio remoto:
Si bien no era necesario hacer un Push de la rama antes de unirla, es considerado una buena práctica para que quede público el historial de cambios y que los demás usuarios puedan visualizar quien, y como hizo los cambios.
Para unir las ramas (merge) Uno debe hacer clic en el nombre de la rama origen y arrastrar y soltar en el nombre de la rama destino, esto desplegará el siguiente menú, donde seleccionamos la opción de Merge.
Una vez elegida la opción, el árbol de commits y branches se verá similar al siguiente:
Como puede verse el merge fue exitoso, sin embargo aún no se verá reflejado en el repositorio remoto, por lo tanto, es necesario activar el repositorio master (haciendo doble click en el nombre) y luego hacer un Push.
Una vez hecho el Push, tanto las ramas como la operación de Merge se encuentran sincronizadas en el repositorio remoto y local
Borrar Branch
A lo largo de la vida de un proyecto de desarrollo pueden crearse infinidad de ramas, por lo tanto, para mantener la interfaz limpia, es una buena práctica eliminar las ramas luego de que se unieron (merge) a master (o a la rama que corresponda según el Git Workflow establecido)
Para eliminar una rama basta con hacer clic derecho sobre el nombre y seleccionamos la opción que la elimina tanto del repositorio local como del remoto
GitKraken nos advertirá que esta es una operación destructiva y que no puede deshacerse, seleccionamos Delete
Una vez que la rama se haya eliminado exitosamente el árbol de commits y branches se verá similar al siguiente:
Como puede verse, ya no existe la rama borrada ni en el repositorio local ni en el remoto, sin embargo, y es en esto donde está la utilidad, puede verse como claramente alguna vez existió y consistió en dos commits que luego fueron unidos al master. La ventaja de esta funcionalidad es que uno puede eliminar las ramas y no perder la historia de lo que se hizo, teniendo una separación en los commits que permite fácilmente rastrear quien hizo que cambios y como fueron hechos. Esto no sería posible (o mejor dicho, sería muchísimo más complejo) si sólo se trabajara con la rama master.
Pull Requests
En un entorno de desarrollo, es poco común que los desarrolladores realicen merge a master directamente, es por eso que se utiliza un mecanismo de aprobación y revisión antes de que se puedan realizar los merge en las ramas críticas. Cada proveedor llama a ese proceso de manera distinta, en el más popular (Github) ese proceso se llama Pull Request.
Una Pull Request es básicamente decir lo siguiente: Tengo cambios hechos y quisiera unirlos a esta rama. Es una práctica común en las ramas más críticas dentro de proyectos de desarrollo, donde a la persona encargada de esas revisiones y aprobaciones se la suele llamar Release Manager y también es sumamente popular en los proyectos Open Source, donde se tiene el repositorio principal y las personas que quieran contribuir, al no tener permisos de editar el repositorio directamente, pueden realizar Pull Requests. El creador del repositorio podrá, luego, aceptarlas o rechazarlas.
Si bien las Pull Requests suelen hacerse mediante la interfaz del proveedor (Github en este caso). Son posibles hacerlas desde GitKraken también.
Sólo con fines ilustrativos se muestra el procedimiento:
- Se hace clic derecho en la rama desde la cual se quiere hacer la Pull Request
- Se selecciona la opción de la Pull Request
- Se completan los campos solicitados
NOTA: Las Pull Requests generalmente se deben realizar de una manera específica que se detalla en el mismo repositorio del software al que uno quiere contribuir por lo que el ejemplo mostrado es trivial, sólo para tener una noción de cómo sería el procedimiento.
Características Adicionales
Aparte de todo lo mencionado en esta guía, queda aún mucho terreno para explorar tanto en lo que permite Git como en lo que se puede hacer con GitKraken, a continuación se listan algunas de estas posibilidades para que el lector pueda indagar en mayor detalle si lo desea
- Tener repositorios dentro de repositorios. Buscar: Submodules y Subtree
- Aplicar sólo un commit de una rama a otra y no hacer una unión de historial. Buscar: Cherry Pick Commit
- Tener ramas completamente independientes de otras: Buscar: Orphan Branch
- Unificar ramas olvidando la historia. Buscar: Rebase
- Agregar contenidos a un commit anterior. Buscar: Amend
- Deshacer varios commits conservando los cambios. Buscar: Soft Reset
- Forzar cambios en el repositorio remoto. Buscar: Push Force
- Es posible revertir cambios de un commit específico. Buscar: Revert
- Guardar en un espacio temporal los cambios del Working Area. Buscar: Stash
- Crear etiquetas para identificar versiones específicas de todo el repositorio cuando se encuentra en un estado consistente (linea base). Buscar: Tags
Algunas de las características mencionadas sólo pueden realizarse desde la consola, es decir, no son soportadas completamente en GitKraken
Recursos Adicionales
- Página web oficial de GitKraken
- Página web oficial de Git
- Git Console Sandbox: Permite experimentar con varios comandos de la consola git en un entorno Sandbox dentro del navegador.
- Awesome Git: Una lista compilada de increíbles herramientas de Git y recursos.