GIT o no GIT, esa es la cuestión.

Cuando has trabajado en varios equipos de desarrollo, aprendes que el control de versiones es un concepto OBLIGATORIO. No saber manejar herramientas de este tipo a estas alturas de la historia, sólo te puede llevar a un destino, el CAOS. Por eso nuestro primer post va de GIT, porque trabajar en equipo mola, que se lo digan a OK Go.

HISTORIA REAL (2015), después de varias experiencias laborales que nos han demostrado lo valioso que es el control de versiones, entramos a una empresa en la que el código se distribuye utilizando una herramienta para compartir archivos (no hacemos publicidad porque no nos pagan, la herramienta es DR***OX). Os podéis imaginar el problema que se genera a diario, cada vez que alguien hace un cambio, todas las modificaciones hechas por otra persona se borran, los cambios no se combinan, nadie sabe que ha ocurrido en la última subida, volver a cambios anteriores es imposible…. no quiero escribir nada más que me entra la ira.

CONCLUSIÓN: para que la relación entre el código y el equipo de desarrollo funcione, se necesita el control de versiones, sí o sí. Nos parece un básico para poder montar cualquier proyecto de manera eficiente.

Repasar, aprender, lo que sea, pero es necesario este post y lo sabes.

Y lo sabes

Así que os vamos a dejar a continuación unas guías para poder llevar a cabo control de versiones con GIT, que nos parece la herramienta más completa de todas las que hemos utilizado en nuestra vida jejeje.

Si no sabes lo que es GIT:

Primer paso. INSTALAR GIT.

Segundo paso. CONOCER ESTRUCTURA GIT

Una manera simple de ver git es la siguiente. Git tiene varios niveles en los que podemos dividir:

  • Working directory: nuestra copia local del proyecto, en la que vamos modificando, borrando y creando archivos.
  • Staging area: los cambios han sido preparados para subir al repositorio, pero aún están en espera.
  • Local repository: los cambios de staging pasan a nuestro repositorio local, pero aún no hemos subido estos cambios a nuestro repositorio remoto.
  • Remote repository: finalmente nuestro código en la nube, que podremos clonar desde cualquier máquina.

GIT genera al hacer git init una carpeta oculta .git donde se almacenarán todas las versiones de tu repositorio, a nivel básico, nunca accederemos a este directorio para nada. Ese directorio es nuestro repositorio local, podremos subirlo a la nube a través de un servidor remoto (normalmente lo llamaremos origin, aunque podemos llamarlo como queramos y tener varios), recomendamos GitHub para repositorios Open Source y BitBucket para repositorios privados. Básicamente en estos repositorios os creáis una cuenta, y ellos os ofrecen espacio para alojar el repositorio en la nube.

Dentro de nuestro repositorio se nos creará una rama principal llamada master, de la que podemos sacar más ramas y luego fusionarlas cuando estén listas. Las ramas son un concepto muy interesante que nos da Git. Estas ramas, permiten crear desarrollos paralelos a la rama de la que estamos trabajando, con lo que más tarde, podemos volver a unir (merge) nuestra rama con la rama padre. EJEMPLO GRÁFICO: un proyecto tiene una rama MASTER, dónde encontraremos todas las versiones finales de una app. De esta rama, sale una rama DEVELOP, dónde los desarrolladores van creando nuevas funcionalidades de la app y cuando estas están funcionando, vuelven a unirse con MASTER, para que su jefe pueda ver las versiones finales y les de la enhorabuena por una trabajo bien hecho (CIENCIA-FICCIÓN).

Cuando queremos que ciertos archivos (como archivos temporales) no se almacenen en nuestro repositorio, podemos crear un archivo en la raíz del repositorio llamado .gitignore y añadir ahí el fichero o el path que queremos ignorar. Os obligaríamos a incluirlo en el repositorio, pero no podemos. El archivo .gitignore, nos ayuda sobre todo a evitar subir archivos al repositorio que creen conflictos en otras máquinas, ya que puede contener archivos directamente relacionados con el entorno de desarrollo, que apuntan a rutas de una máquina en concreto, etc.

Tenemos múltiples modelos de ficheros .gitignore disponibles en gitignore.io

Tercer paso. USAR GIT

Para comprimir un poco las cosas, en este post vamos a hablar de usar git vía consola de comandos, la manera “primitiva” de usar git. También se puede usar git con distintos entornos gráficos, pero lo explicaremos en otro post.

Lo dicho. Comandos de git, más útiles a nuestro parecer:

  • git init – Inicializa un repositorio git en la carpeta que se ejecuta el comando.
  • git remote add <nombre_repositorio_remoto> <url_repositorio>  – Añadir un repositorio remoto.
  • git clone <url_repositorio>  – Permite clonar (descargar) un repositorio en la carpeta actual.
  • git status  – Nos informa del estado de los archivos de nuestro repositorio. Cuales están modificados, cuales son nuevos y añadidos al repositorio, y finalmente cuales no están añadidos (untracked)
  • git add <dirección_archivo>  – Añade archivos no trackeados al repositorio.
  • git add .  – Añade todos los archivos no trackeados.
  • git rm <dirección_archivo>  –  Elimina un archivo del repositorio.
  • git rm --cached <dirección_archivo>  – Devuelve al estado untracked un archivo. Si queremos sacarlo de los próximos commits, debemos meter este archivo en el .gitignore.
  • git commit -m "mensaje"  – Sube los cambios efectuados en los archivos a la copia local.
  • git push <nombre_repositorio_remoto> <nombre_rama>  – Sube los archivos preparados en los commit al repositorio remoto.
  • git checkout -b <nombre_rama>  – Crear una rama nueva que sale desde la que nos encontramos en ese momento y nos posiciona en la nueva rama.
  • git branch <nombre_rama> – Crear una nueva rama a partir de la rama actual.
  • git branch -d <nombre_rama>  – Borrar una rama.
  • git pull <nombre_repositorio> <nombre_rama>  – Actualiza el repositorio local con los cambios del repositorio remoto.
  • git merge <nombre_rama_a_unir>  – Une los cambios de dos ramas en la rama en la que nos encontramos actualmente.
  • git fetch <nombre_repositorio> <nombre_rama>  – Actualiza el estado de los repositorios remotos.
  • git reset --hard  – Deshacer todos los cambios, borrando archivos no subidos, etc.
  • git help  – Ayuda por defecto de git (solo para paquetes que no usan esta guía).

Documentación oficial GIT

Hoja de comandos de GIT

Curso gratuito de iniciación a GIT

Otro tutorial interesante de Udemy

Ruegos, preguntas y demás… abajo!

Gracias [email protected]

  • Pepa Hernando

    FANTÁSTICO BLOG! QUE CALIDAD!: nivel de conocimientos alto, bien documentado, contrastado con experimentación, estupendamente estructurado, consejos muy prácticos, guías autoinstructivas muy asequibles; y, además muy agradable plásticamente y divertido…..¡.WAU!.