All posts in Sistemas
Tutorial de Git: Parte III
Estos últimos meses han sido un poco locura para mi y no he sacado mucho tiempo para poder dedicarme al tutorial de git como debía, pero volvemos a la carga 
En esta tercera parte vamos a trabajar la parte de gestión de diferentes orígenes de código, las ramas en remoto y haremos nuestro primer tag.
En el Tutorial de Git: Parte II empezamos a trabajar con las ramas de forma local e hicimos nuestro primer push a un repositorio remoto. Recordemos los comandos:
- git branch [-d para eliminar, sin rama para listar]
- git checkout
- git merge
Recordad que el merge lo hacemos siempre estando en la rama en la que queremos actualizar/fusionar el código y pasando como parámetro el nombre de la rama origen. A modo de mapa recordad esta imagen en la que habíamos dejado nuestro repositorio local alienado con el remoto.
Diferentes orígenes de código
Es fácil tener en un proyecto en que estén implicadas 2 o más personas varios orígenes de datos remotos. Como vimos en la primera parte del tutorial el punto más fuerte de Git es la descentralización a la que está sometida SVN por ejemplo. Cada uno de estos orígenes de código puede representar un colaborador en el proyecto o un repositorio que actúe de nexo para todos (recomendado en grandes proyectos). Para este caso desde la cuenta de Softwhisper en Github voy a hacer un fork (insisto, no es igual que un fork de SVN a efectos prácticos) desde github directamente. Realmente es muy sencillo, solo debéis hacer login con vuestra cuenta e ir al repo del tutorial; una vez en el pulsar sobre fork y ya tendréis vuestra propia copia en vuestro repositorio remoto. Con git clone lo que hacemos realmente es una copia del principal y trabajaríamos siempre contra el, en vez de en nuestro espacio.
Tras unos pocos segundos ya tendremos una versión del código en nuestro propio remoto. En este caso podemos hacer un git clone de nuestra propia url, eso nos creará en nuestra maquina el repositorio local y el remoto origin para poder empezar a trabajar, pero antes debemos agregar el remoto principal para mantener los datos actualizados o enviar por push cambios que hayamos realizado.
Tutorial de Git: Parte I
Últimamente estamos trabajando de forma más exhaustiva en varios proyectos con otros colaboradores que encuentran en Git un problema para llevar la gestión de versiones y el código.
Los primero que hay que tener claro a la hora de empezar con Git es que no es sistema de control de versiones como SVN, pertenece a la nueva generación de DVCS, sistemas de control de versiones distribuidos.
El flujo normal en con SVN es de tirar siempre los commits hacia un mismo servidor centralizado, de modo que cada persona implicada en el proyecto trabajara sobre el mismo punto final.
Con Git lo más difícil de entender al principio es la desaparición de esa centralización para entrar en un mundo en el que cada uno tiene su repositorio en local sobre el que hacer los commits, merges, ramas y todas las operaciones que realizaremos sobre un repositorio normal pero en nuestro maquina local.
¿Que sucede con la parte remota y donde esta la colaboración?
En Git se crean repositorios remotos, cada usuario puede tener el suyo (la forma ideal de trabajar) o se puede tener un único repositorio remoto que hacen de principal. Sobre estos repositorios se realizan la mayor parte de veces las operaciones de push, para enviar nuestros commits, o pull, apara actualizar el contenido de nuestro repositorio local pero estas operaciones las veremos con mas detalla más adelante.
SSH Autocomplete
Normalmente por A por B siempre acabamos teniendo 3 o 4 servidores entre staging, desarrollo, bbdd, producción etc… Si a esto le sumamos los proyectos en los que trabajamos en Softwhisper acordarte de todas las direcciones nombres de usuarios etc… puede ser un poco coñazo. Ya hace tiempo que tenemos ficheros de configuración para las conexiones ssh, de forma que con
$ ssh softwhisper_staging
nos lanza ya al puerto, dirección y usuario que indiquemos en el fichero .ssh/config. Este fichero tiene este aspecto más o menos:
Host softwhisper_staging
HostName softwhisper.es
Port 22
User pablo
IdentityFile ~/.ssh/id_rsa
Ahora para darle un poco más de estilo podemos añadir esta línea a nuestro .bashrc y tendremos un autocomplete del campo Host:
complete -W “$(echo $(grep ‘^Host ‘ ~/.ssh/config | sort -u | sed ‘s/^Host //’))” ssh
Espero que os sea de ayuda 