Esto es git: conceptos básicos [parte 1]

24 de mayo de 2016
7 min. de lectura

Bienvenidos. En esta oportunidad hablaremos de un software para el manejo de control de versiones denominado Git. Hoy empezaremos hablando de los conceptos básicos, así como de su instalación para plataformas Windows y MacOS.

Control de versiones, ¿qué es eso? 

En tiempos prehistóricos, cuando estábamos desarrollando código para algún proyecto de software, se hacía recurrente el hecho de no guardar en el momento adecuado lo que teníamos adelantado. Por ende, si el equipo se apagaba, perdíamos todo lo que había hasta ese momento. El hecho de querer recuperar código viejo resultaba aún peor. Y sin mencionar que trabajar dos personas en un mismo código era una tarea casi imposible. 

Todo esto fue evolucionando hasta que en algún momento llegaron a nosotros los sistemas de control de versiones. Como su nombre lo indica, estos permiten guardar versiones estables del software para posteriores salidas a producción o pruebas. Aparte tenemos el registro de los cambios realizados por cada uno de los miembros de desarrollo para que al momento de unir estas capas todo pueda fluir y se reduzca el margen de error. 

Entre los sistemas más utilizados hasta hace algún tiempo estaban Subversion, SourceSafe, Mercurial, entre otros. Para el año 2005 empieza a gestarse una historia bastante interesante con el núcleo de Linux y su sistema de control de versiones descentralizado (DVCS). Entre todo lo sucedido, el proyecto empieza a sufrir cambios en su manejo, y es cuando sucede el nacimiento de Git. 

¿Pero qué es git? 

Como lo debes adivinar, git es simplemente un software para el manejo de control de versiones de nuestro código. 

¿Por qué git está de moda? 

Una de las cosas por las cuales los desarrolladores están utilizando git por encima de otros sistemas es debido a su velocidad. Git lo hace todo muy rápido y sencillo para el desarrollador. 

A diferencia de SVN, por ejemplo, git hace honor a su nacimiento siendo sistema de control de versiones distribuido. Así como existe el repositorio central (o remoto) del proyecto, cada desarrollador posee en su equipo lo que se conoce como repositorio local. Esto ayuda de gran manera a tener un control más ordenado, preciso, y además reduce el porcentaje de error. 

Estados

Empecemos por conocer las etapas importantes que les ocurren a los archivos dentro de un repositorio de git. Supongamos por un momento que tenemos el desarrollo de un proyecto que tiene como principio un carro de compras. Hasta el momento solo tenemos un módulo que se encarga de publicar productos, pero vemos la necesidad de desarrollar otro para el registro de los usuarios en el sitio. 

Con ese fin iniciamos el desarrollo del módulo hasta que lo finalizamos. Existe la necesidad de registrar los cambios que tuvieron los archivos, la creación de algunos nuevos y como no, es posible que los eliminados. Debemos realizar, entonces, algunos pasos que veremos más adelante; sin embargo, vamos a ver qué ocurre con estos archivos en las distintas fases. Analicemos el siguiente gráfico de izquierda a derecha: 

Acá empezamos a manejar 3 conceptos nuevos: working directory, staging area y git repository. Todos los cambios que hemos realizado para el desarrollo del nuevo módulo actualmente se encuentran en estado “Modificado” y estos están en el working directory. Una vez nosotros le digamos al sistema cuáles archivos o cambios queremos subir al repositorio, estos pasarán a estado “Preparado” y se encontraran en el staging area. Por último, cuando ya estemos seguros y pasemos estos cambios a estado “Confirmado”, ya estarán en nuestro git repository. Al momento de llegar a esta fase final, nuestro repositorio ya poseerá la actualización del módulo de usuarios. 

Repositorio 

Hemos hablado de muchas cosas hasta ahora, pero aún no definimos concretamente nuestro concepto de repositorio. Un repositorio no es más que un conjunto de archivos colocados en una o varias carpetas para el manejo y la configuración de nuestro proyecto. Para este caso, nuestro repositorio está configurado con git. 

Agregando cambios Como lo mencione arriba, existen algunos pasos con el fin de lograr completar las fases y tener los estados comentados en el punto anterior. Para entender cómo funcionan estos pasos o comandos vamos a ver nuevos conceptos de git. 

Add: este método nos permite agregar los cambios realizados, es decir, cambia el estado de nuestros archivos de “Modificado” a “Preparado”, pasa los archivos del working directory al staging area. 

Commit: realiza el cambio de nuestros archivos en estado “Preparado” a “Confirmados”, lo que quiere decir que los deja finalmente en el git repository. 

Ramas 

Ya hemos visto las fases por las que pasan nuestros archivos y los métodos que nos permiten hacer dichos pasos, todo esto dentro de un repositorio local. Ahora conozcamos un nuevo concepto llamado ramas. Las ramas son líneas de desarrollo únicas que se encuentran dentro de nuestro repositorio y nos ayudan a tener un mejor control. De hecho, un repositorio debe tener al menos una rama. Por convención la rama principal es frecuentemente denominada “máster”. 

Traduciendo un poco lo anterior y tomando el mismo ejemplo del sitio con carro de compras, para el desarrollo del módulo de usuarios deberíamos trabajar de una forma en la que no dañemos el que tenemos actualmente funcionando de forma correcta, en este caso, el módulo de productos. Por eso se creó el concepto de ramas.

Para el supuesto, todo nuestro desarrollo se encuentra en la rama máster, y al iniciar el nuevo desarrollo lo haremos en una rama que llamaremos “usuarios”. De esta forma, si algo llegara a salir mal, saldrá mal en la rama “usuarios” y no en la rama máster. Esto garantizará la integridad de nuestro código. 

Una vez finalizado el desarrollo del módulo y después de haber verificado que se encuentre correctamente diseñado y probado, podremos unir nuestro código de la rama de usuarios al código de la rama máster. Así, hemos actualizado ya nuestro proyecto. Esto lo permite hacer git de una manera muy sencilla e íntegra. Desde un punto de vista gráfico lo podemos observar en la siguiente imagen: 

Merge

Acá nos encontramos con un nuevo y popular concepto dentro del entorno git. En la imagen podremos ver una explicación gráfica que nos resume lo que es un merge: la unión de una rama con otra, sencillamente eso. 

Estos conceptos son utilizados en nuestro día a día en el manejo de git, pero ahora pasemos a la parte divertida. Vamos a ver cómo toda esta teoría se empieza a concretar en la vida real. 

Instalación de git 

Para poder pasar a la diversión, debemos tener instalado git en nuestros equipos. Quienes deseen realizar la instalación haciendo uso de un entorno gráfico (cualquier plataforma) pueden descargar git desde el siguiente enlace: https://git-scm.com/downloads 

Para los más geeks, podemos instalar git desde nuestra línea de comandos desde Mac haciendo a través del siguiente comando (recuerda tener instalado Homebrew): $ brew install git. Si te encuentras en Linux, puedes utilizar los siguientes comandos: para fedora,$ yum install git-core; para Debian o Ubuntu, $ apt-get install git. 

Una vez realizada la instalación, pasarás a formar parte de un grupo de gente interesante y cool.

Creando nuestro primer repositorio 

Vamos a crear nuestro primer repositorio a continuación. En nuestro caso, que somos muy geeks, todos los pasos que realizaremos a continuación serán mediante nuestra consola de comandos. Sea la plataforma que sea (Windows, Linux o MacOs) estas líneas serán transparentes para ti. 

Lo primero que realizaremos es entrar mediante nuestra consola de comandos a la carpeta en la que queremos crear nuestro repositorio; la llamaremos example, y colocaremos el siguiente comando: git init. 

Como podremos ver luego de ejecutarlos, la línea de comandos nos anuncia que hemos inicializado un nuevo repositorio. Cuando creamos un nuevo repositorio, nos coloca en la rama máster como rama principal del proyecto. 

Si verificamos lo que tenemos dentro de la carpeta del proyecto, encontraremos una carpeta .git. Es en esta carpeta donde se encuentra toda la configuración y el almacenamiento de nuestro repositorio. Esta es administrada por git para nuestro repositorio. En lo posible trataremos de no manipularla y mucho menos de borrarla, ya que perderíamos todo el histórico de nuestro repositorio. Para finalizar este primer episodio de git, vamos a poner en práctica dos de los conceptos mencionados, add y commit.

Para esto vamos a crear un nuevo archivo vacío en la carpeta, el cual llamaremos readme.md. Tú puedes utilizar este mismo o algún otro que quieras; la finalidad es la misma. Luego por línea de comandos desde la carpeta del repositorio ejecutamos el siguiente comando. Este nos permitirá conocer el estado de los archivos de nuestro repositorio: git status. 

Podemos ver que git nos dice que existen archivos que se encuentran en estado Untracked; es decir, que no les estamos haciendo versionamiento dentro del repositorio, ya que son nuevos. 

Este estado es el que arriba llamamos Modificado. Para pasarlos al Staging Area debemos agregarlos con el comando add. 

Al momento de realizar add, es importante que sepamos que lo podemos hacer masivo o detallado dependiendo de nuestras necesidades. En este ejemplo vamos a realizar un add masivo, pues solo tenemos un archivo por subir, así que ejecutamos el comandogit add -A. Seguidamente ejecutamos nuevamente el siguiente comando para conocer el estado de nuestro repositorio: git status.

Acá podemos ver que nuestro archivo se ha vuelto de color verde, lo que nos indica que nuestro archivo ya se encuentra en estado Preparadodentro del Staging area; está listo para ser confirmado en nuestro repositorio y para tal fin colocaremos el siguiente comando: git commit -m “Mi primer commit :)” 

Con el comando commit pasamos nuestro archivo a estado Confirmado y ya se encuentra listo dentro de la rama máster en nuestro Git repository. Lo que quiere decir que, si alguna persona quiere clonar (concepto que manejaremos más adelante) nuestro repositorio para realizar otros desarrollos, en el momento que lo haga va a tener el archivo readme.md dentro de los archivos de la rama. 

El comando -m nos permite colocar un mensaje al commit, de tal forma que podamos identificar más fácilmente qué hacemos en cada confirmación de nuestro código. También hay que resaltar que por convención nuestro primer commit debe tener el título de “primer commit” y tratar de que solo tenga un archivo. En este caso ponemos como ejemplo el archivo readme.md, que idealmente debe tener en su interior las características del proyecto que estamos realizando.

Con esto damos por finalizado el primer episodio de la serie. Tratamos siempre de ser bastante específicos en lo que estamos explicando. Si en algún momento se presentan dudas, con gusto dejamos a disposición nuestro formulario para comentarios.

En el próximo episodio estaremos manejando la segunda parte de conceptos básicos. Esto nos servirá como entrada a los episodios de repositorio remoto y flujos que nos traerá más adelante uno de los mas geeks @jaiversin. 

Que tengan excelente semana, nos vemos en un próximo post.

Suscríbete