En el siguiente enlace tienes el indice para acceder al resto de entradas de este tutorial:

Indice Tutorial Git >>

• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 1
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 2
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 3
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 4
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 5
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 6

Hola a todos, hoy vamos a continuar con el  tutorial de iniciación a Git, en el post anterior conocimos nuevos comandos de git, hoy vamos a seguir aprendiendo a utilizar esta herramienta:

Gitignore

Si tenemos archivos o carpetas dentro de la carpeta de nuestro proyecto que no queremos que sean gestionadas por git, como por ejemplo archivos que genera el propio IDE o editor que estamos utilizando, archivos compilados, o cualquier archivo que no necesitamos sincronizar tenemos que crear un archivo llamado .gitignore y dentro indicaremos los archivos y/o carpetas que no queremos que git procese.

Podemos utilizar * como comodín el el nombre de los archivos por ejemplo si queremos excluir todos los archivos que empiecen por config podemos utilizar config*.

A continuación vemos un ejemplo de un archivo .gitignore para un proyecto en java:

# Compiled class file
*.class

# Log file
*.log

# BlueJ files
*.ctxt

# Mobile Tools for Java (J2ME)
.mtj.tmp/

# Package Files #
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# virtual machine crash logs, see http://www.java.com/en/download/help/error_hotspot.xml
hs_err_pid*

Este ejemplo está sacado de la siguiente página de github donde podemos ver ejemplos de diferentes archivos .gitignore según el lenguaje de programación:

https://github.com/github/gitignore

Ramas: git branch

Una rama es una bifurcación o división dentro de tu proyecto donde puedes hacer cambios sin modificar la rama principal, esto nos permite por ejemplo probar cambios sin afectar al proyecto y después una vez comprobado que esos cambios funcionan correctamente  si queremos podemos incorporarlos a la rama principal.

Para crear una nueva rama utilizamos el siguiente comando:

git branch nombre_rama

nombre_rama es el nombre que le queremos dar a la nueva rama, por ejemplo si queremos desarrollar una nueva funcionalidad para nuestro proyecto le podemos dar el nombre de esa funcionalidad para identificarlo mejor.

Para probarlo vamos crear una nueva funcionalidad en nuestro proyecto que consiste en un archivo que muestre un listado de usuarios.

Para no alterar la rama principal y preservar esta tal y como está vamos a crear una nueva rama a la que vamos a llamar listado:

git branch listado

Con git log  a secas no vemos la creación de la nueva rama, para verlo podemos utilizar git log –oneline:

Vemos que en la primera linea nos muestra (Head -> master, listado).

Head -> master nos indica que la rama activa en estos momentos es la rama master, y separado por una coma nos indica que tenemos también la rama listado que acabamos de crear.

Si ejecutamos el comando git branch sin parámetros nos muestra las ramas que tenemos en nuestro proyecto y marca con color la rama activa en este momento:

Para cambiar a la rama que acabamos de crear utilizamos el comando git checkout:

git checkout listado

También podemos crear una nueva rama y hacer un checkout a la rama que acabamos de crear con una única sentencia:

git checkout -b nueva_rama ← esto crea la rama y cambia el control de git a la rama recién creada.

Ahora que la rama activa es listado para nuestra prueba vamos a crear un archivo al que vamos a llamar listado.html, de momento para este ejemplo no nos importa el contenido del archivo, podemos dejarlo en blanco.

Una vez creado el archivo lo añadimos:

git add .

Y  por ultimo hacemos el commit:

git commit -m "se ha anadido listado.html"

Si ejecutamos git status nos indica que estamos en la rama listado.

Como hemos comentado todos los cambios que realicemos en esta rama no afectarán a la rama principal.

Para volver a la rama principal solo tenemos que escribir:

git checkout master

Si hemos creado archivos en la rama que hemos creado al cambiar a la rama principal veremos que esos archivos desaparecen de la carpeta ya que todas las modificaciones que hagamos en una rama solo afectan a esa rama, de la misma manera los cambios que hemos realizado en la rama vuelven a aparecer cuando cambiamos a dicha rama.

Podemos crear tantas ramas como necesitemos en un proyecto.

Uniones: git merge

Si queremos unir los cambios de la rama secundaria que hemos creado con la rama principal tenemos que hacer un merge.

Primero nos situamos en la rama principal:

git checkout master

Ahora para unir las dos ramas utilizamos en comando merge de la siguiente manera:

git merge listado

Ahora todos los cambios que hayamos realizado en la rama listado estarán también en la rama principal (master), en este caso vemos que ahora tenemos el archivo listado.html también en la rama master.

Una vez hecho el merge podemos eliminar la rama listado con el siguiente comando:

git branch -d listado

Resolver conflictos al hacer Merge

Si creamos una rama y modificamos un archivo en esa rama, luego volvemos a la rama principal y modificamos ese mismo archivo, al tratar de hacer un merge git no nos dejará y nos informará de que hay un conflicto.

Vamos a verlo con un ejemplo:

Primero vamos a crear una nueva rama a la que vamos a llamar holamundo2:

git branch holamundo2

Situamos el control en la rama que acabamos de crear:

git checkout holamundo2

Ahora vamos a modificar el archivo holamundo.html, lo editamos y lo dejamos de la siguiente manera:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
        <h1>Hola mundo de nuevo...</h1>
        <h2>Hoy es un buen dia para aprender Git</h2>
    </body>
</html>

Lo añadimos al stage:

git add .

Y hacemos el commit:

git commit -m "Hemos vuelto a modificar holamundo.html"

Ahora vamos a volver a la rama principal:

git checkout master

Y vamos a modificar holamundo.html desde la rama principal, por ejemplo lo dejamos de esta manera:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
        <h1>Hola mundo</h1>
        <h2>Hoy no me apetece aprender Git</h2>
    </body>
</html>

Una vez más lo añadimos al stage:

git add .

Y hacemos el commit:

git commit -m "Hemos vuelto a modificar holamundo.html"

Ahora tenemos el archivo holamundo.html con dos modificaciones diferentes en la rama master y en la rama holamundo2, vamos a ver que pasa si intentamos hacer un merge:

git merge holamundo2

Vemos que nos muestra un mensaje indicando que hay conflictos al hacer el Merge:

Si editamos el archivo holamundo.html vemos que nos ha añadido código indicando las lineas donde hay conflicto:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
<<<<<<< HEAD
        <h1>Hola mundo</h1>
        <h2>Hoy no me apetece aprender Git</h2>
=======
        <h1>Hola mundo de nuevo...</h1>
        <h2>Hoy es un buen día para aprender Git</h2>
>>>>>>> holamundo2
    </body>
</html>

Debemos resolver los conflictos antes de poder hacer el merge,  por ejemplo podemos dejar el archivo holamundo.html  de la siguiente manera:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
        <h1>Hola mundo</h1>
        <h2>Hoy es un buen día para aprender Git</h2>
    </body>
</html>

Ahora lo añadimos al stage:

git add .

Y hacemos el commit:

git commit -m "Hemos resuelto el conflicto con holamundo.html"

Ahora si hacemos un git merge holamundo2 nos muestra en mensaje “Already up to date.”, esto es porque ya hemos hecho la modificación manualmente.

Con git log –graph podemos ver gráficamente como se bifurcan y se vuelven a unir las ramas:

Tags

Los Tags o etiquetas los utilizamos para nombrar a los commits que realizamos. Por ejemplo lo podemos utilizar para nombrar las diferententes versiones del proyecto y así saber en que punto comienza una versión en concreto.

Para crear una etiqueta escribimos git tag nombre_tag.

Tenemos que saber que no nos permite utilizar espacios en blanco en el nombre que le damos a la etiqueta, podemos utilizar un guión “-” o una barra baja  “_” para separar las palabras.

Por ejemplo, vamos a realizar un último cambio a nuestro archivo holamundo.html, editamos su código y lo dejamos de la siguiente manera:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
        <h1>Hola mundo</h1>
        <h2>Hoy es un buen dia para aprender Git</h2>
        <p>Con este ejemplo tenemos lista la version 1.0</p>
    </body>
</html>

Supongamos que ya tenemos una versión de nuestro proyecto preparada, por ejemplo la versión 1.0. Podemos realizar un commit y etiquetarlo para saber que en este punto esta la versión 1.0 de nuestro proyecto.

Una vez más añadimos los cambios al stage:

git add .

Y hacemos el commit:

git commit -m "Hemos añadido un párrafo a holamundo.html"

Ahora vamos a añadir una etiqueta indicando que en este punto tenemos la versión 1.0 de nuestro proyecto:

git tag version_1.0

Si lo deseamos podemos poner varias etiquetas.

Si escribimos git tag nos  muestra todas las etiquetas que hemos utilizado.

Cuando hacemos un git log vemos la etiqueta o etiquetas que hemos añadido en el ultimo commit.

Podemos utilizar el tag para identificar el commit por ejemplo si queremos volver al estado de una versión anterior en lugar de utilizar su identificador podemos utilizar su tag.

Por ejemplo vamos a añadir una linea más a nuestro código en el archivo holamundo.html:

<html>
    <head>
        <title>Hola mundo</title>
    </head>
    <body>
        <h1>Hola mundo</h1>
        <h2>Hoy es un buen día para aprender Git</h2>
        <p>Con este ejemplo tenemos lista la versión 1.0</p>
        <p>Otra línea de código</p>
    </body>
</html>

Añadimos los cambios al stage:

git add .

Y hacemos el commit:

git commit -m "Hemos añadido otra línea a holamundo.html"

Ahora podemos volver al punto en que lo teníamos en la versión 1.0 utilizando su etiqueta en lugar del identificador:

git reset --hard version_1.0

Para eliminar un tag utilizamos git tag -d nombre_de_la_etiqueta

Con git show nombre_de_etiqueta podemos ver en detalle el contenido de ese commit y la diferencia con la versión actual.

Por ejemplo en este caso si ponemos:

git show version_1.0

Obtendremos algo como esto:

Podemos etiquetar un commit anterior utilizando su identificador.

Hacemos un git log –oneline y copiamos el identificador del commit que queremos etiquetar y utilizamos el siguiente comando:

git tag nombre_tag identificador

Por ejemplo:

git tag v.0.0.1 ba94ee2

Esto es todo por hoy, con los comandos que hemos aprendido hasta ahora ya podemos manejar un repositorio en git y aprovechar las ventajas que nos ofrece esta herramienta.

En el próximo post aprenderemos a utilizar un repositorio remoto para poder tener nuestros proyectos en Github y Gitlab

En el siguiente enlace tienes el índice para acceder al resto de entradas de este tutorial:

Indice Tutorial Git >>

• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 1
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 2
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 3
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 4
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 5
• Tutorial de Git - Aprende Git y GitHub/GitLab de manera fácil, rápida y sencilla - Parte 6