EL

Guía introductoria de Git con Interfaz

Visual
24 Apr 2019
34 min para leer
2 Comentarios
PDF 🡓

Versión Original -

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
EL
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
Areas en Git
Stage vs Commit
Repositorios remotos
Branches
Software adicional
Fork de un repositorio
1. Encontrar el repositorio original
2. Realizar el Fork
Clonar un repositorio
1. Crear un repositorio
1 (Alternativa). Crear un repositorio
 2. Completar la información necesaria
EL
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
1. Ventana de Open
1 (Alternativa 1). Ventana de Open
1 (Alternativa 2). Ventana de Open
2. Seleccionar el repositorio
3. Seleccionar la carpeta
Elementos de la interfaz
Interfaz básica
Arbol de Commits y Branches
Añadir Cambios
Sincronización con repositorios remotos
Descargar los cambios del repositorio remoto
Subir los cambios al repositorio remoto
Ejemplo de Fetch y Pull
Trabajo en múltiples branches
Crear Branch
Unir Branches (Merge)
Borrar Branch
Pull Requests
Características Adicionales

Introducción a Git
 Git es una tecnología de sistema de control de versiones (VCS), surge como alternativa
EL
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:

1. Working Area: Son los archivos con los que uno está actualmente trabajando.
2. Staging Area: Son los próximos cambios que serán guardados en el repositorio.
3. 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
EL
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.
ELRepositorios 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
EL
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
EL
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.
EL2. 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
EL

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
ELClonar 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

EL

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.
EL

3. Obtener URL del Repositorio

Para poder clonar el repositorio desde GitKraken pueden utilizarse dos perspectivas:

1. Vincular la cuenta de GitHub con la de Gitkraken

2. 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.
EL

4. Abrimos la ventana de Clone dentro del GitKraken

En el menú File, Seleccionar la opción "Clone Repo"

EL

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

EL

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í.
EL

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
EL
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

EL1 (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).
EL

Elementos de la interfaz

Interfaz básica

Al abrir un repositorio nos encontraremos con la interfaz básica

ELArbol 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
EL
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.
EL

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
EL

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
EL
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:
EL

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.
ELSincronizació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:
EL

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:
EL

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
EL
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
EL

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.
ELUnir 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.
EL
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:
EL

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
EL

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:
EL

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
EL
este caso). Son posibles hacerlas desde GitKraken también.

Sólo con fines ilustrativos se muestra el procedimiento:


1. Se hace clic derecho en la rama desde la cual se quiere hacer la Pull Request
2. Se selecciona la opción de la Pull Request
3. Se completan los campos solicitados
EL

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.
EL
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.

¿Encontraste un bug o un error tipográfico? ¿Tienes alguna sugerencia?

¡Cambia el documento y envíalo! 

¿Te ha gustado este artículo? Compártelo con tus amigos!

 Facebook 

 Twitter 

Recibe un email cuando se publique un nuevo artículo ¡Suscribete al Newsletter!

 What do you think?
EL 6 Responses

Good Amazing! Surprised Bad

Waste of time 

2 Comments Ezequiel Castaño Personal Website 

1 Login

 Recommend t Tweet f Share Sort by Best

Join the discussion…

LOG IN WITH
OR SIGN UP WITH DISQUS ?

Name

Ezequiel Porta • 9 months ago

Felicitaciones Ezequiel, gracias por compartir el material, esta muy
bueno !
△ ▽ • Reply • Share ›

Alber Fer • 9 months ago

Excelente post! Estaré esperando una introducción a VUE.js

Sobre mí
Proyectos
Categorías
Etiquetas
 Archivos
EL FAQ

© Ezequiel Leonardo Castaño

Atom feed  