GIT INIT
Un controlador de versiones nos ayuda a llevar un historial de los cambios que hemos realizado a nuestro código y archivos binarios (documentos). Si debemos revisar una versión antigua u ocurre un error y debemos regresar a la versión anterior, el controlador de versiones nos ayuda a realizar estos cambios.
Usar un controlador de versiones es una buena práctica, al trabajar en equipo es muy probable que entre varios compañeros están modificando los mismos archivos o partes del código que se integran, al fusionar estos nuevos cambios es importante que se tenga una trazabilidad de lo que ha ocurrido y que todos los cambios funcionen en conjunto. Algunas de las ventajas de usar controladores de versiones son:
- Historial de cambios: Podrás observar todos los cambios que has realizado en el tiempo y devolverte en caso de ser necesario.
- Control de errores: Si varias personas están trabajando en un mismo proyecto, el controlador de versiones va a permitir llevar el historial de cambios que cada uno ha realizado, esto evitará muchos errores al fusionar código, nos permitirá añadir cambios al código fuente y corregir errores.
- Trabajar en equipo: Se crean espacios por separado para cada miembro del equipo lo que evita que sus trabajos se interfieran, además permite tener copias del código fuente para realizar validaciones y verificar que todo funciona con el fin de evitar fallas en un ambiente productivo.
GIT es uno de los controladores de versión más utilizados y por ello veremos cómo dar esos primeros pasos para crear repositorios y guardar versiones de nuestros archivos.
Git es un controlador de versiones distribuido que permite trabajar en ambientes separados para cada desarrollador con copias del código principal. Además nos permite tener una identificación de la persona que realiza las modificaciones para llevar una mejor trazabilidad, sumado a la seguridad que brinda para almacenar la información.
¿Qué es una rama?
Cuando queremos hacer referencia a las ramas en git, quizás estamos haciendo referencia a una de las principales funciones de git que permite el trabajo colaborativo, en un flujo de trabajo las ramas son fundamentales para poder permitir que cada integrante del equipo desarrolle su propio código, o en proyectos personales te permiten desarrollar una funcionalidad de la cual aún no estás seguro de poner en tu proyecto final.
Pero … ¿Qué es específicamente una rama?
Podríamos ir a definiciones estándar como: “Una rama es un área de trabajo, ensayo y prueba, con un historial independiente de commits” pero ¿Existe quizás alguna forma más amigable de entender el concepto de ramas?
Git normalmente puede ser visto como un historial de cambios en nuestro código, visto como una simple línea de tiempo (main), en la cual cada vez que completamos un ciclo de trabajo de git al realizar un commit (Este ciclo lo abordaremos en la próxima publicación) se genera un evento en nuestra línea de tiempo.
Pero, supongamos que cuando realizamos nuestro Commit 1, queremos realizar un experimento en nuestro código sin tener que cambiar aquello que está en nuestro código en (main) porque tenemos incertidumbre en aquello que vamos a codear ¿Cómo podría tener una versión exacta de mi código para poder trabajar independientemente? Aquí es donde el concepto de rama es importante y el resultado es el siguiente:
En nuestra rama (Branch 1) tendremos una copia exacta de Commit 1 y de aquí en adelante todos los ciclos de trabajo que realizamos en (Branch 1) serán de esta rama y (main) se mantendrá paralelo a esta, ahora tendremos dos líneas de tiempo de nuestro proyecto, y aquí los curiosos preguntarán:
¿Y solo puedo generar ramas desde el código en (main)?
Un no rotundo es la respuesta, desde cualquier commit en cualquier rama se puede generar una nueva rama, una nueva línea de tiempo de nuestro proyecto, el resultado sería el siguiente si quisiéramos crear una rama desde (Branch 1) con el nombre (Branch 2)
O podemos crear a (Branch 2) desde (main) y el resultado sería el siguiente:
La imaginación y la creatividad combinados con la necesidad de realizar cambios en tu código serán los principales responsables de determinar cuando creas una rama y a partir de que punto, sin embargo, existen metodologías para organizar mejor un repositorio en ramas, siendo la más estandarizada Gitflow.
Ahora, Git nos va a permitir añadir los cambios a la versión principal, descargar la información y llevar una trazabilidad, pero no nos permitirá tener los archivos en un lugar donde todos los miembros del equipo puedan acceder, para ello se requiere un repositorio remoto.
Un repositorio remoto es una plataforma que nos permite compartir el código y los archivos que hemos realizado para que otras personas lo puedan usar e incluso tú mismo tengas un lugar donde almacenar esa información. Los repositorios nos permiten trabajar de manera colaborativa, crear nuevas versiones, hacer copias de códigos que nos ayuden y aportar a los código que otras personas han creado. El repositorio remoto más utilizado es Github, que podemos utilizar fácilmente con Git y nos brinda un ambiente de escritorio amigable para su uso. Además se ha convertido en una red colaborativa para crear aplicaciones de código abierto y un espacio donde podemos crear nuestro portafolio y presentar el trabajo que estamos realizando en nuestras carreras.
Instalación
Git tiene su propia documentación y página oficial donde puede ser descargado en el siguiente link:
Tenemos disponibilidad de instalar en sistemas Windows, Linux/Unix y MacOS.
Empezamos por la más sencilla de instalar, en sistemas Linux/Unix disponemos de comandos para instalar por nuestro terminal de acuerdo a la distribución que estemos utilizando, por ejemplos prácticos y al ser una de las más comunes, el comando para sistemas basados en Debian/Ubuntu es:
$apt-get install gitPara Windows, debemos realizar la descarga e instalación manual, esta tiene sus correspondientes versiones de 32-bit y 64-bits, debemos elegir aquella correspondiente a nuestro equipo, normalmente bastaría con dar siguiente en todas nuestras opciones, pero observemos algunos aspectos interesantes de la instalación:
Git nos sugiere por defecto Vim como editor principal de git, nos advierte que el uso de Vim puede resultar un poco difícil para algunos usuarios, podemos revisar otras opciones de editores recomendados y elegir uno con el que estemos más relacionados (Como Visual Studio Code)
Git y GitHub en sus más recientes versiones permite elegir el nombre para nuestra rama principal en vez del tradicional (Master) como una iniciativa promoviendo la inclusión.
Añadir Git a nuestro PATH , nos permite poder usar Git en otro software como el terminal Powershell de Windows, si elegimos la primera opción únicamente podremos usar Git desde el terminal Git Bash (Instalado con Git)
Esta es la elección de cómo implementaremos el protocolo SSH para conexiones seguras, utilizaremos el que Git trae con su instalación.
En esta opción configuramos como es el proceso al realizar los commits, es importante entender que Git está escrito para sistemas Unix, si seleccionamos la primera opción, Git verificará la información como en un sistema Windows y subirá como una estructura en Unix, le hacemos caso al instalador y utilizaremos esta como recomendada para Windows
Acá instalamos el terminal MinTTY , recomendamos esta opción para tener una terminal Unix en nuestro sistema Windows, configurada en Unicode para presentación de caracteres especiales entre otras funciones.
Aquí se nos indica cómo realizaremos los ‘git pull’ un comando que utilizaremos más adelante, seleccionamos la sugerida por defecto.
¿Estamos listos para usar Git y Github? Si ya tienes una cuenta en github creada, la respuesta es sí, pero primero repasemos algunos comandos Unix que nos ayudarán a navegar en nuestro computador y compartir los archivos de nuestro repositorio local a un repositorio remoto como Github.
Dejaremos algunos recursos si quieres profundizar en este tema:
Conexión Github vía SSH
Antes de empezar con git, configuremos nuestra cuenta de github, por seguridad el protocolo de conexión Secure Shell (SSH) será el que configuraremos. Si alguna vez has creado una llave ssh deberías dirigirte a la ruta:
$ ~/.ssh (Sistemas Unix)C:\Users\{Tu_usuario}\.ssh (Sistemas Windows)
Aquí deberías tener un archivo id_rsa.pub o id_dsa.pub con tu llave pública, en caso contrario, abriremos nuestro Git Bash e ingresamos:
$ssh-keygen -t rsa -b 2048 -C “nombre_clave”Reemplazando el argumento “nombre_clave” por un nombre con el que queremos identificar nuestra llave pública, seguiremos las instrucciones como poner una contraseña y finalmente si volvemos a la ruta que describimos hace un instante, deberíamos encontrar nuestra llave identificada con la extensión “.pub” (nuestra llave privada también, pero NUNCA debes compartirla)
Volviendo a nuestra llave pública, la abrimos con un editor de texto y copiaremos el contenido del archivo, luego en github deberíamos ir a la página de configuración y buscar SSH and GPG Keys
En esta página añadiremos nuestra llave SSH pública
Bastará con ponerle un título con el que identifiquemos a que equipo corresponde esta llave pública y el texto copiado en el archivo generado.
¡Listo! Tu github puede conectarse a tu repositorio local mediante el protocolo SSH.
Tenemos git instalado, nuestro github listo para conectarse a nuestro repositorio local vía SSH, ahora siéntete libre de abrir un terminal (Git Bash en windows), ubícate en una carpeta donde quieras empezar tu repositorio y empecemos la magia:
$git initRecursos
En la próxima publicación realizaremos un tutorial del flujo de git y cómo solucionar un conflicto.
Esta publicación la hicimos en compañía de Sebastián Pastrana, Data Analyst Jr, 99% Electronic Engineering. Music lover, data fanatic & other geeks hobbies. Pueden encontrarlo en redes como @sebastianpasar
Gracias por leernos.
Hecho con ❤
