FORMACIÓN GIT

Guía de Formación de GIT

Bienvenido a la formación en Git, una herramienta esencial para el control de versiones en el
desarrollo de software. Durante este curso, aprenderás los conceptos básicos que te permitirán
gestionar eficientemente tus proyectos. Esta guía te indicará los documentos que debes leer en cada
etapa de la formación para comprender y practicar los conceptos clave de Git.

A medida que avances, encontrarás instrucciones para realizar prácticas específicas, gestionar
ramas, revertir cambios, y trabajar con repositorios remotos. Te recomendamos que sigas esta guía en
el orden propuesto para garantizar un aprendizaje progresivo y sólido. ¡Empecemos!

1. ¿Qué es Git?
➔ Documento a leer: ‘1. GIT - Control de Versiones’

Este documento te ofrece una visión general de Git, su importancia en el control de versiones, y
cómo se utiliza en el desarrollo de software. Es el primer paso crucial para entender cómo y por qué
usar Git.

2. Practicando con Git

➔ Documento a leer: ‘2. Practicando con Git’

Este documento te guiará en los primeros pasos con Git, incluyendo la configuración inicial y los
comandos básicos.

3. Revirtiendo Cambios
➔ Documento a leer: ‘3. Revirtiendo Cambios’

Aquí aprenderás cómo deshacer cambios en Git, tanto a nivel de archivo como de commit.

4. Controlando el contenido de nuestro repositorio

➔ Documento a leer: ‘4. Gitignore’

Este documento explica cómo usar un archivo .gitignore para controlar qué archivos y directorios
deben ser ignorados por Git.

1|3
FORMACIÓN GIT

5. Repositorio Remoto
➔ Documento a leer: ‘5.Repositorio Remoto’

Con el aprenderas a trabajar con repositorios remotos, incluyendo cómo conectarlos y

sincronizarlos con tus repositorios locales.

6. Ramas
➔ Documento a leer: ‘6. Ramas’

Este documento te enseñará a manejar ramas en Git.

7. Conflictos
➔ Documento a leer: ‘7. Conflictos’

Este documento te enseñará a manejar y resolver conflictos entre ramas en Git.

IMPORTANTE: Si nunca has trabajado con un IDE(Integrated Development Environment), es

recomendable que leas antes algunas de las guías de uso de los mismos. En función de la formación
específica que vayas a realizar, deberás leer ‘7.1 Guía rápida del uso de Git en el IDE - VSCode’ o ‘7.1.
Guía rápida del uso de Git en el IDE - Intellij’.

8. Práctica Bot
➔ Documento a leer: ‘8. Práctica de conflictos con el bot de git’

En este documento, aplicarás los conocimientos adquiridos en un proyecto práctico.

2|3
FORMACIÓN GIT

9. Contenido Extra.
Si deseas seguir practicando y aprendiendo sobre Git, aquí tienes algunas referencias muy
interesantes:

1. Git Interactivo

Learn GIT Branching

2. Libro Git y Cheat Sheets.

Nota: Estos documentos podrás encontrarlos en ‘Recursos extra’.

Pro-Git

CheatSheet GIT (1)

CheatSheet GIT (2)

3. Tutorial.

TUTORIAL DE GIT de MAKIGAS

3|3
FORMACIÓN GIT

GIT | Control de Versiones

Contenido
1. Introducción 2
2. Componentes de un controlador de versiones 3
3. Áreas de Trabajo de GIT. 4
4. Instalando Git en Windows 5

1|5
FORMACIÓN GIT

1. Introducción

Cuando desarrollamos software, el código cambia constantemente, es por ello por lo que vamos a
necesitar alguna manera de controlarlo. Git es un sistema de control de versiones distribuido que te
ayuda a realizar un seguimiento de los cambios en tu código y a colaborar con otros.

Los proyectos de la vida real generalmente tienen múltiples desarrolladores trabajando en

paralelo, así que necesitan un sistema de control de versiones como Git para asegurarse de que no hay
conflictos de código entre ellos.

¿Por qué GIT?

Por la sencillez que nos genera para gestionar los cambios. Pensemos en lo siguiente: ¿Cómo
gestionarías las versiones de tu código sin esta herramienta?

Pues si te ha tocado en algún momento, de seguro sabes que se suele hacer, lo que
comúnmente se denomina “definitivo definitivo 100% definitivo”, la siguiente imagen lo ilustra
perfectamente:

Tenemos, además de GIT, otros controladores como CVS o Subversion.

Ventajas
● Facilita al equipo de desarrollo su labor, permitiendo que varios desarrolladores trabajen sobre
el mismo proyecto de forma simultánea y controlando que no “se pisen los pies”.
● Proveen un sitio central donde almacenan el código fuente de la aplicación, así como el
historial de cambios realizados a lo largo del desarrollo.
● Nos permite, en el caso de necesitarlo, volver a una versión anterior y estable en la etapa del
desarrollo.

2|5
FORMACIÓN GIT

2. Componentes de un controlador de versiones

● Repositorio:
Un repositorio es un proyecto que contiene múltiples archivos que está siendo controlado por
GIT y que cuenta con un historial en el que se están registrando los cambios

● Ramas:
Son nuevos caminos que toma el proyecto. La rama principal se llama “master” o “main” y es
donde está el proyecto que sale a producción. Cada vez que se quiere crear una nueva característica o
corregir una existente se crea una rama, de esta forma podemos trabajar en un ambiente aislado.

Esta contiene una copia exacta del proyecto, pero separada. De este modo trabajamos en un
entorno, que en el caso de que fallara, no tendríamos más que eliminarlo sin ocasionar daños.

● Etiquetas (Tags):
Información textual que se añade como complemento a un conjunto de archivos o a un módulo
completo para indicar alguna información importante (como la versión).

● Módulo:
Es un directorio específico del proyecto, puede identificar una parte o ser el proyecto completo.

3|5
FORMACIÓN GIT

3. Áreas de Trabajo de GIT.

En Git, el concepto de "áreas de trabajo" se refiere a las tres principales secciones en las que se
puede dividir el ciclo de vida de los cambios en un repositorio:

● Working area:
Como su nombre indica, este es el directorio de trabajo donde crearemos los archivos,
realizaremos las modificaciones…etc.

Esta área es la que contiene la última versión de los ficheros. Los cambios realizados en el
directorio de trabajo no se registran automáticamente en Git, esto quiere decir que no estamos
protegidos si perdemos esta información a menos que la guardemos y es por eso, que se le suele
considerar a esta área la más volátil.

● Staging area:
Este es el área intermedia en la que preparamos los cambios y modificaciones de los archivos
del working area antes de la validación y el pase al repositorio. Esto te permite seleccionar qué
cambios específicos deseas incluir en el próximo commit. Ayuda a organizar tus cambios y a realizar
confirmaciones más controladas y significativas.

Para pasar nuestro contenido editado a esta área usaremos el comando “add” que va a mover
el contenido del Working Area al Staging Area.

● Local repository:
Este es el directorio que crea GIT donde almacena el historial completo de cambios. Es el área
más segura. Después de agregar los cambios al área de preparación, puedes confirmarlos (commit)
para guardar una versión de esos cambios en el repositorio. Principalmente lo que veremos en esta
área serán todos los puntos de control o commits. Este repositorio también almacena información
sobre todas las confirmaciones anteriores, lo que permite realizar un seguimiento del historial del
proyecto y revertir a versiones anteriores si es necesario.

- GIT Stash:
Además de estas tres áreas principales de trabajo, existe una extra, la ‘Stash’.

Esta la vamos a utilizar para almacenar modificaciones de manera temporal, es decir,

supongamos que estamos trabajando en el proyecto cuando de repente surge algo que tenemos que
modificar urgentemente, ¿Qué haríamos con los cambios que estábamos trabajando? pues tendríamos
que pasarlos al staging area y de ahí al repositorio, pero esta práctica no siempre nos puede ser útil ya
que igual, los cambios con los que estamos trabajando, no son lo suficientemente significativos para
crear un commit nuevo pero tampoco para descartarlos por el trabajo que han llevado. Para ello nace
este cuarto área, en ella nos vamos a apoyar cuando surjan problemas de este tipo.

En resumen, git stash te permite salvar temporalmente los cambios en tu área de trabajo,
limpiarla para poder cambiar de rama o realizar otras operaciones, y luego recuperar esos cambios
cuando lo necesites. Es una herramienta útil cuando quieres cambiar de contexto rápidamente sin
necesidad de realizar un commit permanente de tus cambios.

4|5
FORMACIÓN GIT

4. Instalando Git en Windows

Para instalar Git en Windows, sólo tienes que descargar el instalador y ejecutarlo. Sigue estos sencillos
pasos para hacerlo:

1. Descarga el instalador de GIT para Windows en este enlace.

2. Una vez que hayas descargado el instalador, haz doble clic sobre el ejecutable para que
comience el proceso de instalación y sigue las instrucciones que te aparecerán en pantalla. Al
igual que cualquier otro programa, tendrás que dar “Next” (siguiente) en varias ocasiones
hasta que aparezca la opción “Finish” (terminar) para completar la instalación.
3. Ahora tienes que abrir el símbolo de sistema y escribir los siguientes comandos en la terminal:
4. git config --global user.name "Tu nombre"
5. git config --global user.email "ejemplo@email.com"

Recuerda que debes de cambiar ‘Tu Nombre’ y ‘ejemplo@email.com’ por tu información.

¡Y listo! Ya has instalado GIT en tu equipo.

5|5
FORMACIÓN GIT

Práctica GIT
Contenido

1. Iniciando el repositorio. 2
2. Trabajando en el repositorio. 3

1|8
FORMACIÓN GIT

1. Iniciando el repositorio.

Para ir familiarizándonos con los comandos que podemos utilizar vamos a realizar un ejercicio
práctico.

El ejercicio lo vamos a realizar con GIT Bash, la interfaz de línea de comandos de Git, ya
que a pesar de que hay aplicaciones de escritorio gráficas que nos pueden ayudar, lo
más importante es saber manejarse bien con los comandos.

En primer lugar, abriremos el terminal de Git (Git Bash) y creamos un directorio de prueba en el
que vamos a trabajar. Una vez creado accedemos a él y ejecutamos el comando ‘git init’. Con este
comando creamos un repositorio local en el directorio de trabajo.

La terminal nos informa de que hemos iniciado el repositorio y que ha creado en el ‘fichero oculto’
‘.git’. Es importante mantener esta carpeta segura ya que si se pierde entonces perderemos el
repositorio.

Una vez creado el repositorio, la carpeta en la que estamos sería nuestro working directory. Para
ver el estado en el que se encuentra usamos el comando ‘git status’:

Este comando nos indica la rama en la que estamos trabajando y que no hemos realizado ningún
commit hasta la fecha. Esto es lógico ya que acabamos de crear el repositorio y aún no hemos
trabajado en él.

2|8
FORMACIÓN GIT

Un commit representa un punto en la historia del proyecto donde hemos guardado

cambios específicos. En otras palabras, es algo así como una captura de tu proyecto suele
ir acompañado de una breve descripción que aclara qué nuevas modificaciones se han
hecho. Este comando crea una nueva versión del proyecto en tu zona de trabajo local
(staging area).

Cada commit tiene un identificador único que nos permite realizar un seguimiento de la
evolución del código a lo largo del tiempo y tener un registro de los cambios realizados y
por lo tanto, podríamos incluso revertir cambios.

2. Trabajando en el repositorio.

Para comenzar a trabajar en el repositorio vamos a copiar el archivo ‘home.html’ en el directorio

que creamos en el paso anterior. El archivo contiene la siguiente información:

Una vez realizado el cambio, volvemos a comprobar el estado de nuestro repositorio (‘git
status’):

Vemos que Git nos avisa de que el archivo que acabamos de agregar en el directorio no está en
seguimiento. Para añadir los archivos al seguimiento utilizamos el comando ‘git add’:

3|8
FORMACIÓN GIT

El comando git add puede ser utilizado principalmente de dos formas:

1. ‘git add nombre_archivo’: Para agregar un archivo especifico.
2. ‘git add .’ : Para agregar todos los archivos modificados y nuevos en el
directorio actual.

Utilizando este comando estaríamos ‘colocando’ los archivos en el área de preparación o staging
area. Los archivos en esta área están listos para ser incluidos en el próximo commit. En otras palabras,
hemos indicado a Git que deseamos incluir esos cambios específicos en nuestro historial de versiones.

Es importante tener en cuenta que los archivos en el staging area no se han confirmado
completamente en el repositorio de Git, será necesario que realicemos un commit para que esos
cambios se guarden permanentemente en el historial de versiones. Para ello usamos el comando ‘git
commit’

Este comando coge los archivos que hemos agregado previamente con ‘git add’ al área de
preparación y los guarda como un nuevo commit en el historial de versiones de Git. El mensaje del
commit proporciona una descripción breve de los cambios realizados en ese commit en particular.

En comando ‘git commit -m "Mensaje del commit"’ el parámetro ‘-m

"Mensaje del commit" ’ proporciona una breve descripción de los cambios realizados en
ese commit en particular.

Nota: Si no usamos el parámetro ‘-m’, cuando ejecutemos el comando se nos abrirá un

editor de texto para que veamos el cambio que vamos a realizar y podamos añadir la
descripción.

¡Con esto hecho ya tenemos nuestro primer commit!

4|8
FORMACIÓN GIT

Para revisar el commit que acabamos de hacer usaremos el comando con ‘git log’. Este
comando nos permite ver el historial de commits en el repositorio de Git. Al ejecutarlo, veremos una
lista de commits junto con información relevante, como el autor, la fecha, y el mensaje asociado al
commit.

Vemos que nuestro commit tiene un código asociado a él, ‘fe731e6ee728326e8abd…’. Este código
nos servirá para poder identificarlo y, como veremos más adelante, volver a ese punto si fuese
necesario.

Si no queremos ver tanta información acerca de los commits, el parámetro ‘--oneline’ hará
que se nos muestre la información en una sola línea.

Ahora que hemos realizado nuestro primer commit, vamos a empezar a hacer cambios en el
repositorio y ver qué ocurre. Para ello, en primer lugar, debemos hacer alguna modificación en el
archivo. Esto lo podemos hacer abriendo el archivo en cualquier editor de texto plano y por ejemplo,
escribiendo ‘Bienvenidos a Nter 2.0’ y una vez hecho, seguimos los siguientes pasos:

5|8
FORMACIÓN GIT

A continuación, volvemos a modificar el archivo y hacemos lo siguiente:

Como vemos tenemos cambios guardados en el staging area y, posteriormente se han vuelto a
hacer cambios sobre el mismo fichero.

Para ver las modificaciones que se han hecho en fichero con respecto a lo que tenemos en el
staging area podemos utilizar el comando ‘git diff’. Este comando nos muestra en rojo la línea
modificada que está guardada en el staging area y en verde la línea de la última modificación que se
ha realizado.

Otra opción para ver estos cambios es usar ‘Git Gui’:

6|8
FORMACIÓN GIT

Si ahora hacemos un commit, debemos tener en cuenta que solo se almacenarán los cambios que
estaban en el staging area y, por lo tanto, si queremos almacenar todos los cambios debemos añadir
las últimas modificaciones.

No obstante, si hacemos ese commit, tenemos la opción de agregar esos cambios al commit
anterior, para ellos usamos el comando ‘git commit --amend’ :

Una vez ejecutemos el git commit --amend se nos abrirá ‘Vim’ un editor de código en el que GIT
nos va a indicar el mensaje descriptivo del commit al que vamos a agregar estos cambios de última
hora, junto con los ficheros involucrados, la fecha, etc. Será algo parecido a lo siguiente:

7|8
FORMACIÓN GIT

Ahora para aceptar los cambios debemos:

1. Presiona la tecla Esc para asegurarte de estar en modo de comandos.

2. Escribe ‘:wq’ y presiona Enter. (Esto guarda los cambios y cierra Vim)

Si se te ha abierto en VIM y no sabes salir, tienes que escribir la combinación de teclas ‘:qa!‘

¡Listo! Con esto ya hemos terminado la primera práctica.

8|8
FORMACIÓN GIT

Revirtiendo Cambios
Contenido

1. Introducción. 1
2. ‘git restore’. 1
3. ‘git reset’. 2
4. ‘git revert’. 5

1|7
FORMACIÓN GIT

1. Introducción.
En el mundo del desarrollo no es raro encontrarse con la necesidad de revertir o deshacer
cambios. Ya sea para corregir errores, retroceder a un estado anterior o simplemente explorar
diferentes ramas de desarrollo, conocer las formas adecuadas de revertir cambios en Git es esencial.

Este documento tiene como objetivo ser una guía práctica en el arte de deshacer alteraciones en
Git. Exploramos varias técnicas que abarcan desde revertir cambios locales no confirmados hasta
deshacer confirmaciones previas y restaurar archivos específicos. Descubriremos cómo utilizar
comandos como git checkout y git restore de manera efectiva, así como otras estrategias que te
permitirán mantener el control sobre tu repositorio en cualquier situación.

A lo largo de este documento, desentrañaremos los conceptos clave y proporcionaremos ejemplos

prácticos para asegurarnos de que estés equipado con las habilidades necesarias para navegar por los
desafíos que puedan surgir durante el desarrollo.

2. ‘git restore’.
Para empezar, vamos a volver a modificar nuestro archivo ‘home.html’ y vamos a eliminar todo el
cuerpo del documento, como si lo hubiéramos hecho sin querer:

Como podemos ver los cambios están hechos y GIT lo ha detectado, de hecho, si leemos con
atención veremos que nos dice “use ‘git restore <file>’ to discard changes in working directory”, es
decir, que si queremos deshacer los cambios que hemos hecho sin querer, solamente tenemos que
ejecutar dicho comando, añadiendo el fichero del que queremos deshacer los cambios.

2|7
FORMACIÓN GIT

Como vemos ahora ya no tenemos cambios en el working area y, si miramos nuestro archivo,
vemos que ha vuelto al estado anterior:

3. ‘git reset’.
El comando anterior está genial, pero ¿Qué ocurriría si los cambios realizados los hubiéramos
enviado al staging área?

3|7
FORMACIÓN GIT

Vemos que el comando ‘git restore’ no tiene ningún efecto sobre los cambios. Por lo tanto,
para revertir los cambios debemos usar otro comando. En este caso, usaremos el comando ‘git
reset’ que utilizará la información de algún commit anterior para revertir los cambios.

Como vemos, GIT ha eliminado el archivo del staging area, devolviendo los cambios de este
archivo al working directory. Esto quiere decir que ahora sí podemos utilizar nuestro comando de
confianza ‘git restore’ para eliminar los cambios.

Cuando usamos git reset debemos tener en cuenta que:

● ‘git reset nombre_archivo’: Este comando deshace los cambios que están en
el área de preparación, pero deja los cambios en el directorio de trabajo sin afectar.
● ‘git reset <hash_del_comit> --hard.’: Este comando deshace los cambios
en el área de preparación y también en el directorio de trabajo.
● ‘git reset <hash_del_comit> --mixed.’: Este comando deshace los cambios
en el área de preparación pero los mantiene en el directorio de trabajo. Este es el
comportamiento por defecto del comando si no se especifica ninguna etiqueta.
● ‘git reset <hash_del_comit> --soft.’: Este comando mantiene los cambios
en el área de preparación
HEAD hace referencia al hash del último commit.

Para poder hacer algunas pruebas más con este comando vamos a realizar varios cambios en
nuestro archivo y más commits, para así poder tener más opciones para hacer pruebas y entender
mejor el concepto.

4|7
FORMACIÓN GIT

La intención ahora es utilizar el comando para volver al commit que le indiquemos. Debemos
tener en cuenta que esto eliminará todos los commits que se hicieron después del indicado.

Como podemos ver, tras revertir los cambios, los commits anteriores ha desaparecido y podemos
ver las diferencias con el código anterior.

Hay que tener en cuenta que el comando git reset es peligroso, ya que como hemos
visto, elimina el resto de commits hechos posteriormente al indicado para revertir los
cambios.

4. ‘git revert’.
Por último, veremos el comando ‘git revert’ es otra herramienta en Git que se utiliza para
deshacer cambios en el historial de commits, pero a diferencia de ‘git reset’, no elimina los
commits anteriores ni cambia el historial existente. ‘git revert’ crea nuevos commits que deshacen
los cambios introducidos por los commits que deseas revertir.

En otras palabras, cuando ejecutas ‘git revert’, se crea un nuevo commit que deshace los
cambios introducidos por el commit especificado. Esto es útil cuando quieres mantener un historial de
commits completo y no deseas reescribir la historia del repositorio, especialmente si ya has compartido
el historial con otros.

5|7
FORMACIÓN GIT

Cuando ejecutamos el comando ‘git revert’ debemos tener en cuenta que a veces se pueden
producir conflictos a la hora de intentar fusionar cambios en un archivo.

Git nos está informando sobre el conflicto y a la vez nos proporciona sugerencias sobre cómo
proceder.

Para resolver el conflicto, en primer lugar, debemos abrir nuestro archivo en el editor de código,
Visual Studio Code:

Hacemos click en ‘Resolve in Merge Editor’ y se nos abrirá una nueva pestaña en la que nos
aparecerá a la izquierda la versión futura del archivo, a la derecha la versión actual y, en la parte
inferior, vemos el resultado final del merge. Una vez estemos de acuerdo con los cambios a realizar
hacemos click en ‘Complete merge’.

6|7
FORMACIÓN GIT

Por último, realizamos el commit con los cambios y con esto, habríamos terminado.

¡Listo! Ya estás preparado para revertir cambios en caso de ser necesario.

7|7
FORMACIÓN GIT

.gitignore

Contenido

1. Introducción. 1
2. Metacaracteres. 3

1|4
FORMACIÓN GIT

1. Introducción.

El archivo .gitignore es esencial en Git para especificar patrones de archivos o directorios que
deben ser ignorados al realizar operaciones como "git add" o "git commit", evitando así la inclusión de
archivos no deseados y mejorando la calidad y consistencia del historial de versiones. Su uso facilita la
colaboración al asegurar que todos los colaboradores del proyecto compartan un entorno de desarrollo
más consistente y libre de archivos innecesarios.

Su utilidad principal radica en mantener el repositorio limpio y enfocado, excluyendo archivos

prescindibles como configuraciones locales, archivos temporales y dependencias de proyectos.

Además, desempeña un papel clave al abordar limitaciones de espacio en repositorios remotos, ya

que, al evitar la inclusión de archivos superfluos, como dependencias de terceros o archivos generados,
se reduce significativamente el tamaño del repositorio. Esto mejora la eficiencia en la transferencia de
datos entre repositorios locales y remotos, facilitando la colaboración y la gestión de proyectos
distribuidos.

Esta última parte es importante porque como veremos más adelante, en algún momento nuestro
repositorio deberá ser replicado en un servidor remoto, tal como GitLab, y debemos tener en cuenta
que dichas plataformas de alojamiento no brindan capacidad de almacenamiento ilimitada. En el caso
específico de GitLab, la asignación de espacio para cada repositorio se encuentra limitada a 10GB.

La sintaxis del archivo .gitignore permite definir reglas para excluir ciertos archivos o patrones de
archivos, utilizando comodines y convenciones específicas. Por ejemplo, *.log excluye todos los
archivos con extensión ".log", y /logs/ excluye un directorio llamado "logs". Estas reglas proporcionan
flexibilidad para adaptarse a las necesidades específicas de cada proyecto. En la siguiente tabla se
recogen algunos ejemplos:

2|4
FORMACIÓN GIT

Patrones de git.

Patrón Coincidencias de ejemplo Descripción

Excluye todos los archivos con

*.log
extensión ".log"

Ignora el directorio " logs " y todo su

/logs/
contenido.
Ignora todos los directorios
logs/debug.log,
llamados "logs", sin importar en qué
**/logs logs/monday/foo.bar,
nivel de la estructura del proyecto se
build/logs/debug.log
encuentren.

Ignorar específicamente el
archivo llamado
logs/debug.log, pero no:
**/logs/debug.log "debug.log" que se
logs/build/debug.log
encuentre en cualquier
subdirectorio llamado
"logs",

Anteponiéndolo con una barra le

/debug.log debug.log indicaremos sólo el fichero que
cuelgue de la raíz del proyecto.

Indicando solamente el nombre del

archivo entonces el patrón coincidirá
debug.log debug.log, log/debug.log con los archivos que tengan ese
nombre en el directorio raíz del
repositorio.

Ignora archivos que terminan con

*~ documento.txt~ "~", típicamente utilizados como
copias de respaldo temporales.
Ignora archivos ejecutables de
*.exe programa.exe
Windows.
Ignora el directorio de configuración
.vscode/
de Visual Studio Code y sus archivos.

3|4
FORMACIÓN GIT

2. Metacaracteres.

En el contexto de Git y los archivos de configuración, los metacaracteres son caracteres especiales
que no representan su valor literal, sino que se utilizan para definir patrones. Estos patrones se
emplean comúnmente en archivos como .gitignore para especificar qué archivos o directorios se deben
ignorar.

Aquí tienes una tabla con algunos ejemplos de metacaracteres, su descripción y ejemplos de uso:

Metacaracter Descripción Ejemplo

Coincide con cualquier

* *.log
secuencia de caracteres

? Coincide con un solo carácter temp?.txt

Coincide con un solo carácter dentro
[] [aeiou]
del rango

[1-9][1-3] → Cadenas
Rango de valores a comparar (Va
- coincidentes: 32, 12, 82 y no
acompañado del [])
coincidentes: 99
Coincide con cero o más
** logs/**/debug
directorios

Coincide con cualquiera de los patrones

{} {*.jpg,*.png}
separados por coma

Niega el patrón, seleccionando todo

! excepto lo especificado !important.txt

Coincide con el inicio de una línea

^[xyz] → Empiezan por alguna
cuando está al principio de la expresión.
de esas letras.
^ Cuando está entre paréntesis y seguido
[^xyz] → No contiene ninguna
de caracteres, niega los caracteres que
de esas letras.
siguen.
Coincide con el final de una línea
$ docs$/

Colección de plantillas de .gitignore útiles.

https://github.com/github/gitignore

4|4
FORMACIÓN GIT

Repositorio Remoto

Contenido

1. Introducción. 2
2. Iniciando el repositorio remoto. 3
3. Trabajando con repositorio remoto. 5

1|7
FORMACIÓN GIT

1. Introducción.
En el mundo del desarrollo de software, la colaboración eficiente y la gestión de versiones son
esenciales para construir proyectos exitosos. En este documento, exploraremos la función vital que
desempeñan los repositorios remotos en la facilitación de la colaboración entre equipos y cómo Git, se
convierte en la herramienta fundamental para lograrlo.

Un repositorio remoto en Git es una versión de tu proyecto que se encuentra alojada en un

servidor o en otro lugar fuera de tu máquina local. Este repositorio remoto puede ser accesible y
compartido entre diferentes colaboradores de un proyecto. Los repositorios remotos permiten la
colaboración y la sincronización de cambios entre diferentes desarrolladores.

Algunas características clave de un repositorio remoto son:

● Colaboración:

Varios desarrolladores pueden trabajar en un proyecto compartido al acceder y clonar el mismo

repositorio remoto.

● Sincronización de cambios:

Los desarrolladores pueden enviar (push) sus cambios al repositorio remoto para que otros
puedan verlos y descargarlos (pull). Esto facilita la colaboración y la integración de cambios.

● Copia de seguridad:

El repositorio remoto sirve como una copia de seguridad centralizada del proyecto. Si tu máquina
local falla, puedes recuperar el código desde el repositorio remoto.

● Facilita la distribución:

Permite distribuir el código a través de equipos geográficamente dispersos. Los desarrolladores

pueden trabajar desde diferentes ubicaciones y contribuir al mismo proyecto.

● Seguimiento de versiones:

Los repositorios remotos mantienen un historial de versiones del proyecto, lo que facilita la
colaboración y la gestión de cambios a lo largo del tiempo.

Los repositorios remotos suelen estar alojados en plataformas como GitHub, GitLab, Bitbucket u
otros servicios de alojamiento de Git. Estas plataformas ofrecen funciones adicionales, como
seguimiento de problemas, solicitudes de extracción y otras herramientas de colaboración.

2|7
FORMACIÓN GIT

2. Iniciando el repositorio remoto.

En esta sección, explicaremos los pasos necesarios para crear una cuenta en el GitLab de NFQ y
realizar la configuración inicial para comenzar a trabajar con repositorios remotos.

Para acceder a este repositorio desde casa, será necesario conectarse a la VPN (OpenVPN
Connect). Si aún no tienes la VPN configurada, puedes seguir las instrucciones del documento
‘MANUAL INSTALACIÓN VPN’. En caso de estar accediendo desde la oficina, NO será necesario
conectarse a la VPN.

Una vez accedemos a la página, observaremos lo siguiente:

Deberemos iniciar sesión con el correo corporativo de la empresa. Una vez logueados, tendremos
acceso a todos los proyectos en los que seamos miembros.

El siguiente paso será crear un proyecto dentro de nuestra sesión de GitLab y obtener su URL para
clonarlo mediante https:

3|7
FORMACIÓN GIT

4|7
FORMACIÓN GIT

Disponemos de dos métodos de clonado y la principal diferencia es que HTTPS utiliza

autenticación mediante nombre de usuario y contraseña y es fácil de configurar, mientras
que SSH utiliza autenticación basada en claves, que ofrece mayor seguridad, pero requiere
configuración adicional. Ambos son seguros para interactuar con repositorios de GitLab y la
elección depende de las preferencias, requisitos de seguridad y entorno corporativo.

Una vez hecho esto, tenemos que clonar el repositorio remoto en nuestro equipo usando el
comando ‘git clone’.

A la hora de clonar repositorios tenemos que prestar atención al usuario que tenemos
configurado, ya que si el repositorio no es público no podríamos clonarlo.

3. Trabajando con repositorio remoto.

● Subiendo cambios al repositorio remoto:

Para comenzar a trabajar con el repositorio remoto empezaremos añadiendo al directorio local
nuestro archivo ‘home.html’ y hacemos nuestro primer commit:

5|7
FORMACIÓN GIT

Vemos que git nos informa de que nuestro repositorio local está a un commit del repositorio
remoto. Para actualizar el repositorio remoto debemos usar el comando ‘git push’:

Este comando nos sirve para subir los cambios que tenemos en nuestro repositorio local hacia el
repositorio remoto.

Una de las ventajas de GitLab es que tenemos la opción de ver toda la información sobre los
commits realizados de una forma muy intuitiva:

6|7
FORMACIÓN GIT

● Actualizando el repositorio local:

Por último, nos quedaría ver como actualizar nuestro repositorio local en relación con el
repositorio remoto. Para comenzar necesitamos hacer cambios en el repositorio remoto y para ello
utilizaremos ‘Web IDE’, una utilidad de GitlLab que nos permite editar los archivos de nuestro proyecto
de una forma rápida y sencilla.

Para actualizar los cambios en nuestro repositorio local usamos el comando ‘git pull’:

Este comando actualiza la rama del repositorio local en la que se está trabajando y además nos da
un resumen de las modificaciones que se han realizado.

¡Listo! Ya estás preparado para trabajar con repositorios remotos.

7|7
FORMACIÓN GIT

Ramas en Git
Contenido

1. Introducción 2
2. Comandos básicos 2
3. Práctica 4

1|9
FORMACIÓN GIT

1. Introducción
En Git, una rama (branch) es una línea de desarrollo independiente que permite trabajar en
funcionalidades, correcciones de errores o mejoras de forma aislada del resto del código.Esta
bifurcación del estado del código permite crear un nuevo camino para la evolución del mismo,
permitiendo realizar modificaciones sin interferir en el desarrollo de la rama principal. Cuando se
completa el desarrollo, una rama se puede unir (merge) con la rama principal para integrar la nueva
versión del código. Cada repositorio de Git puede tener múltiples ramas, y cambiar entre ellas te
permite trabajar en diferentes aspectos del proyecto sin afectar las demás ramas. Esto facilita el
desarrollo colaborativo y la gestión de versiones del código.

2. Comandos básicos

● Crear una rama nueva:

Unset
git branch <nombre_de_la_rama>

Este comando solo crea la rama, no nos sitúa en la nueva rama creada para poder trabajar
en ella.
El comando solo crea la rama en el repositorio local.

Para añadir una rama al repositorio remoto, se debe ejecutar un push de la misma:

Unset
git push origin -u <nombre_de_la_rama>

● Listar todas las ramas del repositorio:

Unset
git branch

Este comando es equivalente a git branch --list.

El * indica sobre que rama estamos trabajando actualmente.

2|9
FORMACIÓN GIT

● Cambiar a una rama:

Unset
git checkout <nombre_de_la_rama>

Este comando nos mueve desde la rama actual, a la rama indicada.

La salida nos informará que se ha cambiado de rama:
Switched to branch ‘<nombre_de_la_rama>’

● Crear una rama y cambiar a ella en un solo comando:

Unset
git checkout -b <nombre_de_la_rama>

● Eliminar una rama:

Unset
git branch -d <nombre_de_la_rama>

Este comando solo borra la rama en el repositorio local.

Si se desea eliminar una rama no se debe estar sobre esta. Primero hay que moverse
(checkout) a otra rama y luego ejecutar el comando.
La opción -d es un alias para --delete, que solo borra la rama si está sincronizada con su
rama de referencia.
La opción -D es un alias para --delete --force independientemente de su estado de
sincronización.

Para borrar una rama del repositorio remoto, se debe ejecutar el siguiente comando:

Unset
git push origin --delete <nombre_de_la_rama>

● Fusionar/Unir ramas:

Unset
git merge <nombre_de_la_rama>

3|9
FORMACIÓN GIT

Este comando integra los cambios de la rama indicada en la rama en la que estamos
trabajando actualmente.

3. Práctica

Para poder comenzar a usar los comandos de ramas debemos inicializar un repositorio. Vamos a
hacerlo siguiendo estos pasos:

1. Crea una carpeta con el nombre practica_ramas, en cualquier directorio de tu preferencia.

2. Dentro de la carpeta crea un archivo con nombre home.html que tenga el siguiente contenido:

Unset
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,
initial-scale=1.0">
<title>Nter</title>
</head>
<body>

</body>
</html>

3. Dentro de la carpeta practica ramas abre git bash haciendo click derecho y selecciona la
opción Git Bash Here:

4. En la consola que se ha abierto ejecuta el comando: git init. Esto inicializará nuestro repositorio
local.

4|9
FORMACIÓN GIT

5. Al inicializar el repositorio no existe ninguna rama creada. Para poder crear ramas y realizar la
práctica, necesitamos crear una rama principal. Por defecto, en git la rama principal tiene el
nombre master.

Para git esta rama principal no existe todavía, para crearla debemos hacer un primer commit
en ella. Para hacerlo seguimos los siguientes pasos:

1) Hacemos un git add del archivo home.html

2) Hacemos commit de los cambios añadiendo el mensaje: “Creación de archivo

home.html”

Con estos pasos ya tendremos inicializado nuestro repositorio y creada nuestra rama principal master.

Ahora practiquemos los comandos de ramas aprendidos:

1. Crea una rama ejecutando el comando:

Unset
git branch nueva_funcionalidad

Con esto ya tenemos nuestra primera rama creada. Esta rama se crea en base al contenido de
la rama master. Al crear una rama con este comando no nos sitúa automáticamente en la
rama, para cambiarnos a esta tenemos que realizar el siguiente paso.

5|9
FORMACIÓN GIT

2. Cambiate a la rama creada ejecutando el comando:

Unset
git checkout nueva_funcionalidad

En esta nueva rama tendremos el mismo código que tenemos en la rama master.

3. Cambiate de nuevo a la rama master ejecutando el comando:

Unset
git checkout master

4. Crea otra rama y cambiate a ella ejecutando un solo comando:

Unset
git checkout -b correccion_errores

Luego de esto ya tendremos dos ramas creadas por nosotros a partir de la rama master.

6|9
FORMACIÓN GIT

5. Lista las ramas del repositorio ejecutando el comando:

Unset
git branch

Se identifica con un asterisco a la rama en la que nos encontramos actualmente

6. Cambiate de nuevo a la rama nueva_funcionalidad ejecutando:

git checkout nueva_funcionalidad.

Abre el archivo home.html en un editor de texto y añade el texto subrayado:

Unset
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,
initial-scale=1.0">
<title>Nter</title>
</head>
<body>
<h1>
Esto es un cambio de la rama nueva_funcionalidad
</h1>
</body>
</html>

Luego guarda los cambios y haz un commit de los cambios realizados:

1) Hacemos un git add del archivo home.html
2) Hacemos commit de los cambios añadiendo el mensaje: “Modificación de archivo
home.html”

7|9
FORMACIÓN GIT

Ahora en nuestra rama nueva_funcionalidad tenemos un cambio que no se encuentra en la

rama principal (master). Supongamos que este cambio es una funcionalidad nueva que nos
pidieron desarrollar para nuestro proyecto y ahora queremos integrar esos cambios en la rama
principal para que sean utilizados en un entorno productivo. Para eso debemos fusionar/unir
la rama nueva_funcionalidad con la rama master. Eso lo haremos en el siguiente paso.

7. Para realizar la fusión/unión (merge) de ramas debemos seguir los siguientes pasos:
1) Debemos movernos a la rama a la cual queremos unir nuestra rama.
En este caso queremos unir la rama nueva_funcionalidad a master.
Para cambiarnos a master ejecutamos el comando:
git checkout master

2) Abre el archivo home.html y revisa su contenido. Como podrás ver, el archivo en la

rama master no contiene los cambios que hemos realizado sobre la rama
nueva_funcionalidad.

3) Para realizar la unión (merge) de ramas ejecutamos el comando:

Unset
git merge nueva_funcionalidad

Si abres de nuevo el archivo home.html, podrás ver que ya la rama master contiene los
cambios de la rama nueva_funcionalidad.

Antes de realizar una fusión/unión (merge) de ramas es buena práctica que la rama que
queremos unir (nueva_funcionalidad) esté actualizada con los últimos cambios que pueda
tener la rama a la que la queremos unir (master). En este caso sabemos que la rama master
no tiene cambios porque solo hemos estado trabajando nosotros sobre este repositorio, pero
en un caso real trabajaremos sobre un repositorio que es utilizado por un equipo de personas
que pueden haber hecho cambios sobre la rama principal mientras nosotros hacemos
nuestro desarrollo en nuestra rama.
Si al realizar la unión (merge) ambas ramas contienen cambios realizados por distintas
personas sobre las mismas líneas de código, esto genera lo que se conoce como un conflicto.
Los conflictos serán explicados en su propia sección, con su respectiva práctica.

8|9
FORMACIÓN GIT

8. Por último, borra la rama correccion_errores con el siguiente comando:

Unset
git branch -d correccion_errores

¡Listo! Con este último paso damos por finalizada la práctica de ramas.

9|9
FORMACIÓN GIT

Conflictos en Git

Contenido

1. ¿Que es un conflicto dentro de GIT? 2

2. Práctica guiada 2

1|7
FORMACIÓN GIT

1. ¿Que es un conflicto dentro de GIT?

Un conflicto en Git ocurre cuando dos o más ramas tienen cambios en las mismas líneas de un
archivo o cuando un archivo ha sido eliminado en una rama y modificado en otra. Git no puede
determinar automáticamente qué cambio debe conservarse, por lo que requiere de intervención manual
para resolver el conflicto.
Vamos a realizar un ejercicio donde vamos a crear un conflicto y vamos a resolverlo. Algunos de los
IDEs más utilizados hoy en día son: VS Studio (para front-end) e IntelliJ (para back-end). Por este motivo,
vamos a realizar esta práctica utilizando alguno de estos IDEs. Cada uno podrá elegir el IDE que prefiera,
aunque lo ideal es que elijáis el IDE que luego utilizaremos dentro de las formaciones.

Este manual ha sido extraído de utilizar el IDE IntelliJ, aunque también se encontrará como se pueden
realizar los cambios dentro del terminal.

2. Práctica guiada

1. Crear un repositorio nuevo:

Antes de crear el repositorio tendremos que crear un proyecto nuevo:

En IntelliJ, selecciona la opción para crear un nuevo proyecto y asegúrate de marcar la opción para
crear el repositorio Git.

En caso de no activar esta opción, tendrás que abrir la consola y ejecutar el comando “git init”

2|7
FORMACIÓN GIT

2. Creación de archivos y commit:

Dentro del proyecto, crea un fichero llamado “Conflicto.txt”. Dentro de IntelliJ, aparecerá la opción de
añadir el fichero a Git automáticamente:

En caso de no añadirlo automáticamente, tendremos que realizar un “git add Conflicto.txt”

Ahora realizaremos un commit de este fichero:

3|7
FORMACIÓN GIT

Esto es lo mismo que hacer un “git commit -m COMMIT INICIAL DE NUESTRO FICHERO DE PRUEBA”.
Recordar que es muy importante poner un mensaje explicativo dentro del commit, esto facilitará mucho el
trabajo de compañeros que revisen nuestro trabajo.

3. Crear y movernos de rama1:

Crearemos la rama “RamaConflicto1” y nos cambiaremos de Rama:

El comando en la consola sería: “git checkout -b RamaConflicto1”.

4. Modificar el archivo y hacer commit en la rama1:

Una vez estemos situados en la nueva rama, tendremos que modificar el archivo y hacer un commit.

Para finalizar nos moveremos a la rama master.

4|7
FORMACIÓN GIT

5. Crear y movernos de rama2:

Realizaremos el mismo paso que en el anterior punto donde creamos la “RamaConlicto1”, pero esta vez
desde la terminal:

6. Modificar el archivo y hacer commit en la rama2:

Realizar el mismo cambio que en la rama 1

7. Merge del cambio y resolución del conflicto:

Lo primero que tenemos que hacer es cambiarnos a la rama “master” (git checkout master) y realizar
un merge con la Rama1 (git merge RamaConflicto1).

Ahora haremos un merge de la RamaConflicto2 (git merge RamaConflicto2):

5|7
FORMACIÓN GIT

Ahora tendremos que ver que versión/cambios queremos mantener, OJO hay que tener en cuenta
que si no realizamos una revisión previa de los cambios, podremos perder el trabajo que ha realizado otro
de nuestros compañeros.
Es muy importante tener claro qué cambios finalmente tienen que subir, incluso nos podría interesar
tener los dos cambios. En esta ocasión para resolver el conflicto vamos a unir los dos ficheros:

En el caso de haber realizado la práctica con el terminal, tendremos que modificar el fichero con los
cambios que nos interesen y hacer un commit.

6|7
FORMACIÓN GIT

Una vez realizado el commit veremos el log de git (git log), donde podremos observar los commit
realizados en las dos ramas y la resolución de conflictos aplicada.

¡Listo! Ya estás preparado para resolver conflictos entre tus ramas.

7|7
FORMACIÓN GIT

Manual usuario Intellij

Contenido

1. Introducción 2
2. Creación de proyectos 2
3. Apertura de un proyecto ya existente 4
4. Gestión de Ramas 6
5. Visualización de los cambios realizados 7
6. Commit y push 8
7. Historial de cambios 9
8. Terminal 9

1|9
FORMACIÓN GIT

1. Introducción
IntelliJ IDEA es uno de los entornos de desarrollo integrado (IDE) más utilizados y avanzados,
especialmente popular para el desarrollo de aplicaciones backend. IntelliJ ofrece soporte robusto para
lenguajes de programación como Java, Kotlin, Groovy, y Scala, entre otros. Su potente motor de análisis
de código, herramientas de depuración avanzadas, integración con sistemas de control de versiones
como Git, y soporte para múltiples frameworks y tecnologías (Spring, Hibernate, etc.) lo convierten en
una elección preferida para desarrolladores que trabajan en el desarrollo de software a nivel de
servidor. Además, su interfaz intuitiva y numerosas funcionalidades adicionales mejoran
significativamente la productividad y eficiencia en el desarrollo de aplicaciones complejas.

2. Creación de proyectos
Para empezar con este manual, lo primero que vamos a ver es cómo podríamos generar un
proyecto desde 0.

Pulsando en el botón de “New Project”, nos aparecerá un menú básico de configuración, donde
se podrá configurar el nombre, lenguaje, etc…

2|9
FORMACIÓN GIT

3|9
FORMACIÓN GIT

3. Apertura de un proyecto ya existente

Si disponemos de un proyecto ya descargado, podremos abrirlo pulsando en el botón “Open”:

En el caso de que entremos a un proyecto, el cual se encuentra subido a GitLab podremos

clonarlo directamente:

4|9
FORMACIÓN GIT

Deberemos introducir la URL del proyecto para poder clonarlo.

5|9
FORMACIÓN GIT

4. Gestión de Ramas
Dentro del IntelliJ podremos directamente crear ramas dentro del proyecto, movernos de rama,
actualizar las ramas, etc…

6|9
FORMACIÓN GIT

5. Visualización de los cambios realizados

Dentro del propio IntelliJ disponemos de un visualizador de cambios, donde podremos visualizar
todos los archivos que hemos modificado:

7|9
FORMACIÓN GIT

6. Commit y push
Para realizar un commit de un cambio realizado, tendremos que marcar que fichero queremos
“proteger” (git add) y añadir un mensaje para nuestro commit (o marcar la opción amend para poder
sobreescribir el último commit). Debemos recalcar que, directamente podremos realizar un push de los
cambios:

8|9
FORMACIÓN GIT

7. Historial de cambios
Disponemos de una opción para poder visualizar el historial de cambios realizados dentro de una
rama

8. Terminal
Podemos destacar que el IDE cuenta con un terminal, en el cual podremos ejecutar los
comandos directamente, como si fuera la herramienta “GIT Bash”.

9|9
FORMACIÓN GIT

Git en Visual Studio Code

Al instalar Visual Studio Code este trae por defecto un apartado para el uso de Git. En esta guía
se mostrará de manera resumida como poder realizar operaciones con git desde este editor de código.
Si necesitas más información puedes visitar la documentación oficial:

https://code.visualstudio.com/docs/sourcecontrol/overview

Abrir directorio de repositorio

Para poder utilizar Git en Visual Studio Code debemos abrir el directorio del repositorio. El
directorio del repositorio es el que contiene en su interior una carpeta oculta que tiene el nombre .git.
En el caso de la imagen, el directorio del repositorio sería gitbot, ya que este es el que contiene en su
interior un carpeta de configuración de repositorio (.git). Esta configuración es leída automáticamente
por VSC al abrir el directorio en el editor.

Sección de Git en VSC

Para acceder a las funcionalidades de git debemos hacer clic en este icono que se encuentra en
el menú lateral izquierdo:

Después de clicar se abrirá la sección:

1|7
FORMACIÓN GIT

Si clicamos en el icono de los tres puntos, podremos observar todas las operaciones que
podemos realizar sobre el repositorio: pull, push, fetch, etc.

2|7
FORMACIÓN GIT

En la parte inferior nos indica sobre que rama estamos situados:

También podemos cambiar de rama si clicamos sobre la rama en la que nos encontramos
actualmente, esta acción desplegará un menú con las operaciones de rama. Además de cambiar de
rama también podremos crear una nueva.

3|7
FORMACIÓN GIT

¿Cómo hacer un commit?

Para hacer un commit, primero debemos realizar los cambios necesarios en el repositorio y
guardar. Cuando ya se tienen los cambios necesarios para realizar un commit debemos abrir la sección
de git:

Añadimos los cambios con los cuales deseamos hacer el commit. Esto lo hacemos clicando sobre
el icono +:

4|7
FORMACIÓN GIT

Los cambios añadidos aparecerán en la sección Staged Changes:

Luego de esto debemos añadir un mensaje para el commit:

5|7
FORMACIÓN GIT

Por último luego de tener los cambios añadidos y el mensaje escrito, hacemos clic en el botón
commit:

Luego del paso anterior ya tendremos hecho el commit, si lo deseamos podemos realizar un
push de este commit al repositorio remoto clicando en el botón Sync Changes:

Esto hará que salga una ventana para confirmar esta acción. Luego de clicar en OK, se realizará
un pull del repositorio para luego realizar el push.

6|7
FORMACIÓN GIT

Resolución de conflictos

Los conflictos que puedan surgir aparecerán en el área Merge Changes:

Estarán delimitados por los caracteres:

<<<<<<<

=======

>>>>>>>

Las opciones que tenemos para resolver los conflictos son las siguientes:

Aceptar cambios actuales (Accept current change - nos quedamos con los cambios de la rama
actual).
Aceptar cambios entrantes (Accept incoming change - nos quedamos con los cambios de la rama
que estamos uniendo con la nuestra).
Aceptar ambos cambios (Accept both changes - nos quedamos los cambios de ambas ramas).
Los cambios actuales se encuentran en el área verde, mientras que los entrantes se encuentran
en el área azul.

Una vez resuelto el conflicto se puede añadir el archivo para incluirlo en el commit.

7|7
FORMACIÓN GIT

Práctica de conflictos con bot

1. Objetivos de la práctica 2
2. Práctica 3
Ejercicio 1 3
Ejercicio 2 4
Ejercicio 3 5
Ejercicio 4 7
Ejercicio 5 10
Ejercicio 6 15

1 | 17
FORMACIÓN GIT

1. Objetivos de la práctica
En esta práctica vamos a centrarnos en la resolución de conflictos haciendo uso de un bot que irá
añadiendo cambios a la rama develop.

En primer lugar, crearemos una rama a partir de la rama develop que posteriormente debemos ir
actualizando a medida que el bot vaya haciendo cambios.(Estos cambios serán notificados por el
formador).

El objetivo de la práctica es definir con qué cambios queremos quedarnos en nuestra rama,
resolviendo los posibles conflictos que surjan. Al comienzo se irá indicando con qué parte del código
debemos quedarnos para obtener el resultado deseado y, a medida que la práctica avance, solo se
facilitará el resultado final y se deberán resolver los conflictos para que el código quede como el ejemplo
indicado.

Nota: Las capturas para mostrar los conflictos están hechas con el IDE Visual Studio Code.
Para realizar esta práctica se puede utilizar el IDE de su preferencia que cuente con una
extensión de Git.

Para realizar todos los ejercicios debemos tener clonado en nuestro ordenador el siguiente
repositorio:

https://gitlab.nfqsolutions.es/evaluanter/gitbot/conflicts-practice

Debemos estar ubicados sobre la rama develop y crear una rama con el nombre:

practica_conflictos_<nombre-apellido>

Esta rama es la que utilizaremos para realizar la práctica.

Esta guía cuenta con 6 ejercicios. Pasa a la siguiente página para comenzar con el ejercicio 1.

2 | 17
FORMACIÓN GIT

2. Práctica
Ejercicio 1

1. Abre el archivo index.html y agrega tu nombre después de la frase “Hello World”.

Una vez modificado el archivo de esta forma debemos hacer commit de los cambios y hacer
push en nuestra rama.

2. Espera a que el formador te indique que puedes continuar.

3. En este momento el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre la misma línea en ambas ramas.

Aceptar cambios actuales (Accept current change - nos quedamos con los cambios de la
rama actual)
Aceptar cambios entrantes (Accept incoming change - nos quedamos con lo cambios de la
rama que estamos uniendo con la nuestra)
Aceptar ambos cambios (Accept both changes - nos quedamos los cambios de ambas ramas)

3 | 17
FORMACIÓN GIT

4. Para este ejercicio se quieren conservar los cambios realizados por nosotros en nuestra rama. En
este caso seleccionamos aceptar cambios actuales (accept current change). Al hacer esto el
código quedará igual que antes de realizar la unión.

5. Después de resolver el conflicto, debemos guardar los cambios, hacer commit y push de nuestra
rama.

6. Abre el archivo index.html en un navegador y verás el Hello World con tu nombre sin los cambios
del bot, con esto terminamos el ejercicio 1.

Ejercicio 2

1. Abre el archivo index.html y elimina tu nombre. El archivo debe quedar así:

2. Guarda, haz commit y push del cambio en tu rama.

3. Espera a que el formador te indique que puedes continuar.

4. En este momento el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre la misma línea en ambas ramas.

4 | 17
FORMACIÓN GIT

5. Para este ejercicio, se quiere conservar el cambio realizado por el bot. En este caso,
seleccionamos aceptar cambios entrantes (Accept incoming change). Al hacer esto el código de
nuestra rama quedará con los cambios realizados en la rama develop por el bot:

6. Después de resolver el conflicto, debemos guardar los cambios, hacer commit y push de nuestra
rama.

7. Abre el archivo index.html en un navegador y verás que en tu rama ya posees los cambios
realizados por el bot, con esto terminamos el ejercicio 2.

Ejercicio 3
1. Abre el archivo index.html y debajo del código añadido por el bot en el ejercicio anterior coloca
el siguiente texto: <p>New change</p>.
El archivo debe quedar así:

2. Guarda, haz commit y push del cambio en tu rama.

3. Espera a que el formador te indique que puedes continuar.

5 | 17
FORMACIÓN GIT

4. En este momento el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre la misma línea en ambas ramas.

5. Para este ejercicio, se quiere conservar tanto el cambio realizado por el bot en la rama develop
cómo el cambio que hemos realizado en nuestra rama. En este caso, seleccionamos aceptar
ambos cambios (Accept both changes). Al hacer esto el código de nuestra rama quedará de la
siguiente forma:

6. Después de resolver el conflicto, debemos guardar los cambios, hacer commit y push de nuestra
rama.

7. Abre el archivo index.html en un navegador y verás que en tu rama ya posees los cambios
realizados por el bot y por ti, con esto terminamos el ejercicio 3.

6 | 17
FORMACIÓN GIT

Ejercicio 4
1. Abre el archivo index.html y reemplaza el contenido con el siguiente texto:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Conflict Practice</title>
</head>
<body>
<h1>This is a conflict practice</h1>

<div id="line-11-my-branch">
<p>Line 11 of code in my branch</p>
</div>

<br>

<div id="line-17-my-branch">
<p>Line 17 of code in my branch</p>
</div>

<div id="line-21-my-branch">
<p>Line 21 of code in my branch</p>
</div>

<br>

<div id="line-27-my-branch">
<p>Line 27 of code in my branch</p>
</div>

<br>

<div id="line-33-my-branch">
<p>Line 33 of code in my branch</p>
</div>

<br>

<p>Line 38 of code in my branch</p>

</body>
</html>

2. Guarda, haz commit y push del cambio en tu rama.

7 | 17
FORMACIÓN GIT

3. Espera a que el formador te indique que puedes continuar.

4. En este momento el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre las mismas líneas en ambas ramas.

8 | 17
FORMACIÓN GIT

5. Deben solucionar los conflictos para que el código muestre el siguiente resultado al abrir el
archivo index.html en el navegador:

6. Una vez que logres que en el navegador se visualice el texto anterior habrás resuelto el conflicto
de manera correcta. Guarda, haz commit y push del cambio en tu rama. Con esto ya has
terminado con el ejercicio.

9 | 17
FORMACIÓN GIT

Ejercicio 5
1. Abre el archivo index.html y reemplaza el contenido con el siguiente texto:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Conflict Practice</title>
</head>
<body>
<h1>This is a conflict practice</h1>
<h3>Open the browser console to see the results</h3>
</html>

<script>
console.log("Addition result: " + addition());

function addition() {
return 2 + 2;
}
</script>

En este ejercicio incorporaremos el uso de Javascript para poder crear funciones. El código
Javascript se encuentra dentro de las etiquetas <script>.

2. Guarda, haz commit y push del cambio en tu rama. Abre el archivo index.html en el navegador.
Después abre la consola del navegador para ver el resultado de la ejecución del código. En
Chrome la consola se abre presionando f12 y luego navegando a la pestaña console.

3. Espera a que el formador te indique que puedes continuar.

4. En este momento, el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre las mismas líneas en ambas ramas.
10 | 17
FORMACIÓN GIT

En la rama develop se han creado más operaciones. En este caso se han añadido las funciones:
restar, multiplicar y dividir. Necesitamos resolver el conflicto de forma que el código contenga la
operación desarrollada por nosotros (sumar) y las tres operaciones creadas que se encuentran en la
rama develop.

Existen conflictos que no se pueden solucionar solo con aceptar los cambios. Para este caso si
elegimos una de las 3 opciones de selección de cambios (entrante, actual o ambos) generará un
resultado no deseado, además de que el código no podrá ser ejecutado porque contendrá errores.

5. Para lograr realizar la unión y que conservemos las funciones con las cuatro operaciones, se
deben realizar algunos cambios de forma manual antes de aceptar los cambios entrantes o
actuales.
Realiza alguna de las dos opciones que se ofrecen a continuación para resolver el conflicto:

11 | 17
FORMACIÓN GIT

a) Copia el contenido de los cambios actuales y añadelo en el área de los cambios

entrantes:

Posteriormente, acepta los cambios entrantes.

12 | 17
FORMACIÓN GIT

b) Copia el contenido de los cambios entrantes y añadelo en el área de los cambios

actuales:

Posteriormente, acepta los cambios actuales.

13 | 17
FORMACIÓN GIT

Después de de realizar alguna de las dos opciones previas, el código debe quedar de la siguiente
forma:

6. Guarda, haz commit y push de los cambios realizados.

7. Abre el archivo index.html en el navegador y visualiza la consola. Debes observar lo siguiente:

Con esto ya has terminado con el ejercicio.

14 | 17
FORMACIÓN GIT

Ejercicio 6
1. Abre el archivo index.html y reemplaza el contenido con el siguiente texto:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Conflict Practice</title>
</head>
<body>
<h1>This is a conflict practice</h1>
<h2>Congratulations, you have finished the conflict practice with the
bot</h2>
<h3>Open the browser console to see the results</h3>
</html>

<script>
console.log("Addition result: " + addition());
console.log("Subtraction result: " + subtraction(3, 1));
console.log("Multiplication result: " + multiplication());
console.log("Division result: " + division());

function addition() {
return 3 + 3;
}

function subtraction(a, b) {
return a - b;
}

function multiplication() {
return 2 * 2;
}

function division() {
return 6 / 2;
}
</script>

Hemos realizado los siguientes cambios en base al ejercicio anterior:

a) Se ha añadido la línea: <h2>Congratulations, you have finished the conflict practice with
the bot</h2>
b) Se han modificado los valores del método addition.
c) Se ha modificado el método subtraction para añadir parámetros.
d) Se han modificado los valores del método ‘division’.

2. Guarda, haz commit y push del cambio en tu rama.

15 | 17
FORMACIÓN GIT

3. Espera a que el formador te indique que puedes continuar.

4. En este momento, el bot ya habrá realizado un cambio sobre la rama develop.

Une (merge) la rama develop con tu rama. Al realizar la unión se generará un conflicto debido a
que se han realizado cambios sobre las mismas líneas en ambas ramas.

5. Resuelve los conflictos para que al abrir el archivo index.html veas el siguiente resultado en el
navegador y en su consola:

16 | 17
FORMACIÓN GIT

6. Guarda, haz commit y push del cambio en tu rama.

¡Enhorabuena! Has finalizado con la práctica de conflictos.

17 | 17