Actualmente existe una gran demanda en el mercado laboral de conocimiento de aplicaciones que permiten trabajar en equipo y controlar las versiones de los proyectos de desarrollo de software. Lo que se conocen como repositorios y controladores de versiones.
Independientemente del sistema operativo que empleemos, el uso de este sistema es elemental. Puesto que nos permite realizar proyectos en trabajo colaborativo. No solamente es necesario conocer un determinado lenguaje para ejercer el trabajo, es preciso también saber la lógica de funcionamiento que emplean estos gestores de versiones.
Git es un sistema de Código Abierto u Open Source y además distribuido, que permite administrar el código fuente de proyectos grandes y pequeños. Existen tantos repositorios como usuarios. Cada desarrollador podrá disponer del repositorio en local, en la propia máquina de trabajo.
Un control de versiones (SCV) o administrador de código fuente es un sistema que almacena los cambios realizados sobre un archivo o un conjunto de archivos a lo largo del tiempo. Podremos recuperar versiones. Nos posibilita retroceder en el tiempo para corregir, modificar o eliminar, editar cambios en el proyecto.
Existen muchas alternativas a GIT, como pueden ser Mercurial, SVN, Darcs, CVS, etc.
GIT fue creado por linus Torvarls, el creador del kernel de GNU\Linux. GIT es rápido, ofrece un diseño sencillo, perfectamente válido para proyectos grandes (ejemplo el núcleo de Linux). El sistema de ramas o branches es excepcional.
Un SCV nos debe permitir restaurar los históricos de forma sencilla, cada uno de ellos queda identificado con una cadena numerada o ID (HASH).
GIT ofrece grandes ventajas para la empresa. Cuando trabajamos en un proyecto empresarial a diario, sin un SCV, los guardados realizados ocupaban más espacio, y duplicaban información, no existe control de archivos, los cambios e información que ha ido agregándose simplemente no se registra.
Actualmente este mecanismo ya no es eficaz, puesto que no permite un trabajo colaborativo y los problemas que ello deriva.
Incluso los freelances pueden trabajar con GIT para colaborar con el resto y avanzar rápidamente en el proyecto bajo un mismo directorio.
Gracias a este SCV podremos evitar conflictos entre archivos de usuarios, controlar las versiones, recuperar datos, crear diversas ramas, y recopilar información de los cambios y trabajo que se va realizando.
Por lo tanto es un software nos permite trabajar en proyectos en equipo, ganar tiempo, aumentar la rentabilidad del proyecto.
Para poder trabajar con GIT existen herramientas cliente software pero algunos prefieren trabajar en modo consola o mediante comandos.
No debemos confundir servicios en la nube para trabajar en equipo con un sistema de control de versiones. Ejemplo, si trabajamos en dropbox podremos trabajar en equipo, pero no tiene nada que ver con un sistema distribuido de control de versiones. Nada en absoluto. El último que guarde los datos en el dropbox pisara los datos de otro. Un caos. No existe un sistema de control de cambios, una lógica de control de modificaciones, ni un historio de los mismos cambios.
Para descargar GIT e instalarlo se puede visitar accediendo a la web (independiente de la plataforma)
Para Windows existe un proyecto msysgit.guithub.io
Para comprobar que está instalado podemos abrir una terminal y ejecutar
git –version
Para Mac podríamos visitar la web de
Esta web Homebrew se encarga de instalar todo aquello que Apple no instala de serie. Homebrew instala cada paquete en su propio directorio, creando enlaces simbólicos a sus archivos dentro de usr/local
Estados de trabajo en GIT
Existen 3 estados, y es necesario tenerles muy presentes porque es vital. Nuestros archivos se van a ir moviendo entre estos estados.
El working directory o área de trabajo, donde los ficheros se encuentran en estado de modificado. Editamos el archivo.
Staging Area. Área de almacén. El archivo se encuentra en estado de preparado.
Git directory (repository). Historial o repositorio. El archivo se encuentra confirmado, se le ha dado el visto bueno. Donde residen los datos y metadatos del proyecto. Es lo que copiamos en nuestros ordenadores cuando descargamos un repositorio.
Entre el área de trabajo y el almacén se hacen operaciones como un add desde trabajo hacia el almacén o un checkout desde el almacén hacia el trabajo.
Desde almacén se puede hace un commit hacia el repositorio o un reset desde el repositorio hacia el almacén
Podemos rescatar un archivo del repositorio hacia el working directory con instrucciones o comandos.
Existen muchos comandos podemos visualizarles en la ayuda o en la web.
El git config permite definir la configuración de git. Es bastante utilizado e importante.
Git init inicializa el repositorio.
Git config –l
Lista la configuración de la carpeta.
No quiero entrar al trapo en esta entrada en los comandos, puesto que anteriormente cree una sección específica relacionada con los comandos (ver enlace inferior).
El facebook de los programadores y diseñadores. Uso básico de Git y acceso a repositorios Github
Git config –global user.mail oscar@palentino.es
Git config –global core.editor Sublime
Las configuraciones de git se almacenan en un archivo .git config
Resumen de comandos básicos (bueno, repasaremos un poco).
Git init // Creamos un repositorio en el directorio actual/local. Solo necesitamos estar colocados en la carpeta de nuestro proyecto. Inicializa un nuevo repositorio para el control de cambios.
Git clone direccionURL // Trae una copia del repositorio central/remoto a nuestro ordenador. Para clonarle. Traemos una copia a nuestro ordenador para trabajar en local.
Git add nombre_archivo // Añade al repositorio el archivo que le indiquemos. Si indicamos un .punto añaderia todos los archivos.
Git commit –am “mensaje” + archivos. // Quedan almacenadas nuestras modificaciones con mensaje
Git rm archivo // Borra un archivo del working y del stage
Git mv origen destino //Mueve el archivo o directorio a una nueva ruta.
Git status // Nos muestra el directorio/ estado de trabajo local.
Git diff // Muestra la diferencia entre los cambios que aun no está en stage.
Git diff rama1 rama2 // Muestra las diferencias entre dos ramas.
Git log // Muestra la información de una rama de trabajo. Podemos marcar las fechas desde hasta.
Git show // muestra los metadatos y cambios de un commit.
Git reset HEAD nombreArchivo //No incluye el archivo en el próximo commit.
Get reset –soft HEAD // Deshace el commit
Git checkout rama // Recuperar ramas
Git branch // Muestra las ramas existentes
Git pull // descarga las últimas modificaciones remotas del repositorio
Git push // Subimos los cambios al repositorio
Git fetch // Trae los cambios desde remoto pero no los fusiona
Git remote // Muestra los repositorios remotos.
Etc, etc, etc.
Respecto a las banderas o flags son ayudas que nos muestra el estado que se encuentra un documento. R,M C, A, U, etc.
Continuaré en la parte II
GIT, trabajando con control de versiones.
