Revista Informática

Configuración de un entorno de trabajo con GIT

Publicado el 18 abril 2017 por Caminomedio
Configuración de un entorno de trabajo con GIT

Cuando emprendemos el desarrollo de un sistema o de un sitio web, en el que participan dos o más personas, tenemos que organizarnos muy bien para evitar destruir con nuestros cambios el trabajo previo de los compañeros de proyecto. A pesar del nivel de sincronía y organización que se pueda alcanzar, frecuentemente surgen conflictos o dudas al trabajar en aspectos del proyecto muy cercanos entre si, por ejemplo cuando un desarrollador requiere modificar un archivo de código sobre el que viene trabajando un colega. La situación se complica cuando los involucrados no comparten un mismo entorno físico, por lo que el chat, correo o teléfono no mejoran el asunto. Es por ello que en estas circunstancias hay que recurrir a lo que se denomina un control de versiones, de los que existen varios, pero uno destaca especialmente por su origen: el GIT.

¿Que es el GIT?

Git (pronunciado "guit"2 ) es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Al principio, Git se pensó como un motor de bajo nivel sobre el cual otros pudieran escribir la interfaz de usuario o front end como Cogito o StGIT. 3 Sin embargo, Git se ha convertido desde entonces en un sistema de control de versiones con funcionalidad plena. 4 Hay algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del núcleo Linux. (Wikipedia, 2017)

Manos a la obra

A continuación describiremos los pasos básicos para la configuración de un entorno de desarrollo conformado por al menos dos desarrolladores regido por el sistema de control de versiones GIT. Sin embargo esta metodología también sera aplicable para un programador solitario, ya que un control de versiones entre sus bondades ofrece un historial de versiones, por lo que se puede regresar a estados previos del desarrollo, en el caso de que los cambios efectuados no nos satisfagan.

En el servidor

Crearemos el usuario git para que el repositorio principal se ubique en su directorio de trabajo, sin embargo se puede utilizar un usuario existente o crear uno distinto.

TERMINAL
  1. useradd git
  2. passwd git

Ahora creamos y configuramos el directorio donde se alojara el repositorio

TERMINAL
  1. cd ~
  2. mkdir repositorio.git
  3. cd repositorio.git
  4. git init --bare --shared
  5. mv hooks/post-update.sample hooks/post-update

Podemos usar el comportamiento por defecto del servicio git al momento de procesar la información proveniente de los clientes, o cambiarla por un esquema básico que se detalla a continuación:

Editamos el archivo hooks/post-update

TERMINAL
  1. nano hooks/post-update

Y realizamos el siguiente cambio:

ARCHIVO hooks/post-update
  1. # El parámetro $1 del script es el nombre del branch actualizado
  2. # Comparamos con master para actualizar el entorno de producción
  3. # y con test para actualizar el entorno de pruebas
  4. case " $1 " in
  5. *'refs/heads/master'*)
  6. echo "Pulling producción"
  7. unset GIT_DIR
  8. cd /var/www/repositorio || exit
  9. git pull origin master
  10. ;;
  11. esac
  12. case " $1 " in
  13. *'refs/heads/test'*)
  14. echo "Pulling pre-producción"
  15. unset GIT_DIR
  16. cd /var/www/repositorio-test || exit
  17. git pull origin test
  18. ;;
  19. esac
  20. exec git-update-server-info

En el cliente del desarrollador 1 (líder)

Procedemos a configurar el repositorio del desarrollador líder, aquel que tiene la última palabra cuando surge un conflicto con los cambios que el equipo de desarrollo actualiza sobre el repositorio principal

TERMINAL
  1. cd ~
  2. mkdir repositorio.git
  3. cd repositorio.git
  4. git init
  5. git remote add origin usuario@servidor-ip:/home/usuario/repositorio.git

Ahora creamos o copiamos un archivo cualquiera en esta carpeta, por ejemplo:

TERMINAL
  1. touch prueba

Procedemos a hacer la sincronización inicial

TERMINAL
  1. git add *
  2. git commit -m “Subida inicial”
  3. git push origin master

En el cliente del desarrollador 2

Esta sera la configuración tipo a seguir por el resto del equipo de desarrollo

TERMINAL
  1. cd ~
  2. mkdir repositorio.git
  3. cd repositorio.git
  4. git init
  5. git remote add origin usuario@servidor-ip:/home/usuario/repositorio.git
  6. git pull origin master

En el servidor carpeta /var/www

Hasta ahora hemos configurado lo relativo a los repositorios, los pasos que se listan a continuación están enfocados hacia la construcción de un entorno adecuado para el desarrollo de un proyecto web. El objetivo es que al momento de actualizar cambios hacia el repositorio central, estos también se reflejen en el servidor web del ambiente de desarrollo de nuestro proyecto.

TERMINAL
  1. sudo usermod -G git www-data
  2. cd /var/www
  3. sudo mkdir repositorio
  4. sudo chown -R git:git repositorio
  5. sudo chmod 775 repositorio
  6. cd repositorio
  7. git init

En caso de tener un repositorio de pruebas, dentro del ambiente de desarrollo, se siguen estos pasos adicionales:

TERMINAL
  1. sudo usermod -G git www-data
  2. cd /var/www
  3. sudo mkdir repositorio-test
  4. sudo chown -R git:git repositorio-test
  5. sudo chmod 775 repositorio-test
  6. cd repositorio-test
  7. git init

REFERENCIA

Wikipedia. (18 de abril de 2017). Git. Recuperado de: https://es.wikipedia.org/wiki/Git



Volver a la Portada de Logo Paperblog