¿Qué son Git y GitHub? Antes de responder a esta pregunta hay que entender el concepto de Sistema de Control de Versiones. ¿Qué es y para qué sirve?
Sea lo que sea a lo que te dediques, cuando llevas a cabo un proyecto, ya sea un documento, una presentación, escribes un libro, desarrollas una aplicación o creas un juego, el proceso no es inmediato ni directo. Sabes cuando empiezas, pero no cuando acabas. Y una vez terminado, cuando lo veas, lo corregirás y lo modificarás, pero no una vez, ni dos, lo vas a modificar y corregir en repetidas ocasiones.
Esto de las correcciones y revisiones será porque detectas errores. Desde una falta de ortografía en la redacción de un artículo, pasando por una diapositiva de la presentación que no tiene ningún sentido, o un bug en el juego. O bien, porque quieres modificar una parte del mismo para mejorarla. Por ejemplo, porque el libro que estás escribiendo es sobre una determinada aplicación, que se ha actualizado y han liberado una nueva versión con nuevas características.
Llegados a este punto, el problema lo encontrarás cuando quieras volver atrás. Por ejemplo, una vez has introducido una modificación en tu libro, puede ser que no te guste como ha quedado y quieras deshacer los cambios. Si son pocos cambios, con deshacer tienes suficiente, pero ¿qué sucede cuando has introducido cambios sustanciales?
¿Cómo podemos regresar al pasado? Para esto es necesario llevar un control de versiones.
Sistemas de Control de Versiones
Para poder gestionar todos los cambios que se producen en nuestro proyecto, tenemos que recurrir a los sistemas de control de versiones. Un sistema de control de versiones no es más que un registro histórico de los cambios producidos.
Sin embargo, existen diferentes modalidades de sistemas de control de versiones, en función de su funcionamiento.
Sistemas de Control de Versiones Locales
Durante la ejecución del proyecto es fundamental registrar los cambios que se van produciendo. Este registro de cambios te puede ayudar a volver a una versión anterior, en el caso de que la actual no sea de tu agrado, o a comprender por qué tu proyecto se encuentra donde se encuentra actualmente. Es de gran utilidad porque nos da un gran abanico de posibilidades como:
- Volver a una versión anterior de un documento del proyecto
- Volver a una versión anterior de todo el proyecto.
- Comparar los cambios entre dos versiones
Esto se puede resolver haciendo copias de nuestro proyecto. Es decir, cada vez que cambiamos un archivo, ya sea un documento, una imagen o lo que sea, creamos una nueva copia del proyecto.
En pequeños proyectos, lo que hago es exactamente esto. Por ejemplo, cada vez que realizo una modificación de un plano de un proyecto, creo una copia del mismo. Sobre esta copia hago las modificaciones que necesito, y genero una nueva versión. Ahora bien, aunque la mayor parte de las veces registro la fecha del cambio, no siempre, o más bien, casi nunca, registro a qué se han debido los cambios. En otras ocasiones, también me ha sucedido que mi modificación la he hecho no sobre la última versión, sino sobre una previa.
Efectivamente, esto es un problema, y es que en un momento podemos estar trabajando en la versión que no toca o simplemente borrar la última versión, o no guardar una versión anterior.
Para resolver este primer problema, se desarrollaron los Sistemas de Control de Versiones Locales. Que no es, ni más ni menos, que una base de datos donde se registran cada uno de los cambios que se producen en nuestro proyecto.
Sistemas de Control de Versiones Centralizado
Pasemos al siguiente nivel. ¿Qué pasa cuando trabajáis varios en el mismo proyecto? ¿Cuando sois varios los que intervenís en el proyecto? Cada uno de vosotros irá realizando cambios en el proyecto, de forma simultánea (o no). Si en el caso anterior ya era importante registrar los cambios, imagínate ahora. En este caso,
- Podemos averiguar quién ha introducido un determinado cambio
- Quién a resuelto un problema o lo ha creado
Habrás comprendido claramente por qué es importante llevar un sistema de control de versiones en un grupo. Si en ocasiones, cuando trabajo solo, me equivoco y no parto de la última versión para realizar mis modificaciones, con varios es misión, prácticamente, imposible.
Pero aún nos queda un nivel más. ¿Qué pasa cuando cada uno de los miembros que trabajan en el proyecto está en una parte del mundo?
Sistemas de Control de Versiones Distribuidos
Aquí entramos en los trabajos colaborativos. Varios miembros trabajando sobre un mismo proyecto, y deslocalizados, es decir, no todos se encuentran en la misma oficina (por ejemplo).
A priori, la solución es tan sencilla como tener el proyecto en la nube, ya sea en un servicio propio o en un servicio ajeno. Cuando necesitamos realizar una modificación del proyecto, descargamos la última versión de lo que queremos modificar, lo actualizamos y lo volvemos a subir. Esto tiene varios problemas:
- Estás limitado por el ancho de banda de tu conexión. Si cada vez que tienes que realizar una modificación tienes que mirar en la nube la última versión, descargarla, hacer las modificaciones, volverla a subir, y tu conexión a internet es tremendamente lenta, tu trabajo será muy lento.
- ¿Qué sucede cuando otro realiza modificaciones a la vez que tú? ¿Cuando dos estáis trabajando a la vez sobre un mismo archivo? ¿Cuál es la versión válida?
La solución a todo esto son los sistemas de Control de Versiones Distribuidos. Esto no es más que cada miembro del grupo tiene una copia local del control de versiones. Es decir, una copia del historial de cambios que se han ido realizando.
Cada vez que realizamos una modificación en nuestra copia ésta se reporta a la copia principal, donde es gestionada convenientemente por el administrador del proyecto.
Git
Git es un sistema de control de versiones distribuido pensado para proyectos donde existe un gran número de archivos de código fuente.
Los fundamentos
Una secuencia de instantáneas
Mientras que en otros sistemas de control de versiones lo que se guarda en la base de datos son los cambios que se producen, Git guarda instantáneas. Es decir, cada vez que guardas el estado de tu proyecto, Git realiza una fotografía de tu proyecto, de cada uno de los archivos de tu proyecto. Esta instantánea, refleja el estado de ese archivo.
En el caso de que un archivo determinado no haya sufrido ninguna modificación, no hace una copia de él, sino que guarda un enlace hacia el último archivo guardado.
De esta manera Git trabaja con tu proyecto como una secuencia de instantáneas. Cada plano de la película está constituido por cada una de las instantáneas que se tomaron de cada uno de los archivos que constituyen el proyecto.
Funcionamiento en local
Como Git guarda toda la historia del proyecto en tu ordenador, en una base de datos local, no necesita conectarse al servidor central para ver la evolución de un determinado archivo.
Igualmente, cuando realizas un cambio, éste lo puedes hacer en local, no necesitas conectarte a la base de datos central para registrar este cambio.
Garantía de Integridad
Cada vez que realizas un cambio, cuando se va a guardar el registro se realiza una suma de comprobación (hash). Esta suma de comprobación es la que se utiliza para referirse al cambio. Evidentemente, esto es una garantía de integridad.
Por otro lado, Git solo añade información. Si has realizado un cambio y éste se lo has confirmado a Git, se puede recuperar.
Los tres estados
El flujo de trabajo con Git es el siguiente:
- Realizas un cambio en un archivo (estado modificado)
- Le indicas a Git que has modificado ese archivo (estado preparado)
- Confirmas todos los cambios realizados en los diferentes archivos (estado confirmado)
Así, cualquier archivo que se encuentre en nuestro sistema de control de versiones, pasa por cada uno de estos tres estados.
Es importante comprender esto de los tres estados, puesto que es el trabajo habitual con el que te enfrentarás cuando pelees con las revisiones.
Cuando estás trabajando en tu proyecto, vas modificando archivos (cada vez que modificas uno de ellos pasa al estado modificado). Cuando consideras que uno de los archivos modificados ya está terminado, llega el momento de comunicárselo al sistema de control de versiones. En ese momento este archivo pasa al estado preparado. Por último, cuando ya tienes todos tus archivos en estado preparado, llega el momento de confirmarlo, pasando a partir de ese momento al estado confirmado.
Es posible que esto te pueda parecer algo enrevesado en un principio pero, como verás, todo tiene su lógica.
Esto lo veremos con mas detalle y de un modo más práctico en el próximo artículo de esta serie…
Más información,
Imágenes originales con licencia Creative Commons Attribution-Share Alike 3.0 Unported, modificadas y adaptadas de:
Gran artículo. Espero con ansias la publicación del próximo.
¿Una vez completada la serie se expondrán los conocimientos suficientes para poder instalar un Git propio en un servido?
No olvidemos GitLab que también es una gran opción con muchas buenas características!!
Buen artículo!! 😉
Pienso que git podría servir para diferentes medios, estoy pensando en un proyecto al respecto, por ejemplo vídeos colaborativos, alguien agrega la narración otro el audio, otro edita imágenes y así se tienen vídeo colaborativos.
¿Alguien sabe si hay un proyecto así que sea libre? ¿Si alguien aquí sabe programar, puede especular que haría falta para que git funcionara de la manera que propongo?
Muy clarificador, esperando más!