Archivo de la etiqueta: git

Git Merging con Ubuntu (Linux)

Como muchos programadores de Linux ya os habréis dado cuenta, no hay una aplicación nativa de GitHub para Linux (a diferencia de Windows y Mac). Sinceramente me parece algo ilógico ya que los programadores tenemos una tendencia a gravitar hacia Linux. Pero a grandes males grandes remedios, no? Cuando en un repositorio tenemos conflictos (merge conflict) y hay que solventarlos, una herramienta de merge nos va a ser bastante útil más que resolver el conflicto a mano o usando la consola. Una GUI, aunque no lo parezca, es bastante útil en algunos casos.

He probado kdiff3 y meld. A mi parecer no tienen punto de comparación, claramente la mejor herramienta es meld por algunas simples razones.

Kdiff3:

Captura de pantalla de la GUI de kdiff3

  • Me parece que usa una GUI obsoleta y poco intuitiva.
  • No encontré la opción para cambiar el idioma (la instalé des de Alemania y estaba en alemán).

Meld

Captura de pantalla de la GUI de meld

  • Por el contrario su GUI es más intuitiva y algo más moderna.
  • Estaba en inglés des del principio.
  • No me gustó que creara dos ficheros, para el archivo remoto y otro para el local (además del que se sube a la rama).

Para usar estos merge tools usaremos esta linea en la consola (cambiando meld por kdiff3 si te gusta más este):

 git mergetool -t meld

Puede ser que no los tengas instalados, usando el siguiente comando lo instalaremos (o kdiff3 en vez de meld):

sudo apt-get install meld

Finalmente una vez convencido de la herramienta podremos usar la siguiente linea para guardar la herramienta deseada e iniciar el programa que más nos haya gustado cada vez que surja un merge conflict.

git config --global merge.tool meld

Si conoces una herramienta mejor no puedes en dejarlo en los comentarios. Me encantará conocerla! :)

Fuente e imágenes

Git avanzado: Etiquetas, logs y el botón del pánico

Una vez inicializado git, conocidos los primeros comandos y aprendido a hacer ramas con git ahora toca aprender un poco sobre etiquetas (tags), logs y que hacer cuando la lías parda.

Las etiquetas sirven básicamente para etiquetar commits. ¿Y para que quiere uno etiquetar commits? Bien, pues para indicar en que momento se definió una versión de la aplicación. Para crear una etiqueta usaremos:

 git tag NumeroVersion idCommit

El id del Commit son los primeros 10 caracteres del commit al que queremos etiquetar. Te preguntarás, ¿y como se esos 10 caracteres? Pues fácil te vas al log, y para ver el log usarás el comando:

 git log

Si quieres algo más sofisticado y con menos ruido puedes filtrar por autor:

 git log --author=NombreUsuario

Sólo que archivos fueron cambiados:

 git log –name-status

O si aun así quieres ver todo el árbol con todas las ramas y etiquetas puedes usar el comando:

 git log --graph --oneline --decorate --all

En cualquier caso si quieres indagar más profundamente échale una ojeada a:

 git log --help

En el hipotético caso de que la hayas liado parda y no sepas como solucionar el problema eliminando todos los cambios locales y commits hechos trayendo la versión de la rama master más reciente. Ten en cuenta que sobre-escribirás todos tus ficheros, pero si aun así lo deseas deberás usar los siguientes comandos:

 git fetch origin
 git reset --hard origin/master

Para los que hayáis llegado tan lejos decir que git tiene incorporado algo parecido a una interfaz gráfica. Recordar que no hay para linux una GUI que permita hacer push y toda la mandanga, solo está en Mac y WIndows. Pero para acceder a su sucedáneo se puede acceder escribiendo en la consola:

gitk

Pero si aun así preferís seguir usando la linea de comandos quizás os interese colorear un poco el output con el comando

git config color.ui true

o en los logs simplemente mostrar sólo una linea por commit con:

 git config format.pretty oneline

Como crear ramas (branches) con git

Ahora que ya tenemos git inicializado  y hemos aprendido unos primeros pasos tocará empezar con unos conceptos un poco más avanzados. En este post aprenderemos a crear ramas. Normalmente los proyectos usan ramas para mantener la rama master “más limpia”, evitar commits a medias y evitar conflictos.

Para que nos entendamos la rama master es la rama principal y en las otras ramas es dónde hacemos los cambios. Para crear una rama empezaremos con:

 git checkout -b NombreRama

Como ya vimos después de aplicar los cambios en nuestra rama tocará subir los cambios al directorio remoto haciendo un:

 git push

Una vez terminados todos los cambios y dar la rama por acabada realizaremos el merge. Que básicamente es mezclar nuestros cambios con la rama master. Para esto usaremos el comando:

git merge nombreRama

Algunas veces esto ocasionará conflictos que deberemos solventar. Para ver los conflictos podemos usar:

 git diff <source_branch> <target_branch>

Y si hemos intentado hacer un “merge” que ha sido fallido debido a los conflictos deberemos volver a hacer un:

git add nombreArchivo

Una vez terminado del todo lo que podemos hacer es volver a la rama master con:

git checkout master

Y finalmente borrar la rama con el comando:

git branch -d feature_x

Cabe mencionar que la rama “no está disponible para terceros” a menos que se haga un push al repositorio remoto. Esto se puede hacer con el comando:

git push origin

Para los que les haya interesado este post sobre como crear ramas (branches) en git quizás les interese indagar un poco más en este [EN] modelo de creación de ramas con git. Haciendo un resumen rápido, tienen la rama principal, luego la rama developer y a partir de aquí crean ramas de features.

Primeros pasos con git

Como dije ya en su momento, git es un sistema de control de versiones. Ahora que ya tenemos git inicializado tenemos que aprender las posibilidades más básicas que nos ofrece.

Para empezar tendremos que crear un repositorio. Para esto usaremos:

git init

En caso de que algún colega ya tenga un repositorio lo que haremos será:

git clone username@host:/path/to/repository

 En el caso que esté alojado en github, este link lo encontraremos en el lado derecho debajo de “SSH clone URL”.

Ahora que tenemos los ficheros en nuestro ordenador, tocará trabajar con ellos. Una vez hayamos hecho el cambio que queríamos tenemos que proponer un cambio. Para esto usaremos:

git add nombreArchivo

o si simplemente queremos subirlo todo haremos

git add *

Pero para realmente remitir los cambios tendremos que usar:

git commit -m “mensaje que queramos”

 Cabe indicar que cuanto más descriptivos los mensajes mejor, ya que cuando haya conflictos nos servirá para entender mejor como debemos proceder.

Ahora después del commit, tenemos los cambios “guardados” en el fichero HEAD de nuestro ordenador. Ahora tocará enviar nuestros cambios al directorio remoto. Para esto usaremos el siguiente comando:

git push origin master

Espero que os haya servido ya que va a haber algunos más! :)

GitHub vs Bitbucket: Que control de versiones Git usar?

El otro día hablando sobre proyectos con mis compañeros descubrí, que a diferencia de lo que pensaba algunos de ellos no alojan sus proyectos en GitHub. Por lo que con toda mi curiosidad quise saber cual es la diferencia entre los dos.

Ambos pueden usar Git como sistema de control de versiones. Como “punto a favor” Bitbucket soporta Mercurial aunque ninguno de los dos Subversion. Por lo que Bitbucket ganaría este punto, aunque no es muy significativo.

Repositorios públicos vs privados. En GitHub no te permite tener repositorios privados a menos que pagues una mensualidad (o seas estudiante). Por el contrario Bitbucket si que ofrece la posibilidad de tener repositorios privados sin ningún coste añadido. Por lo que ambos tienen ventajas e inconvenientes.

El punto anterior está sub-editado a la forma que tienen de monetizar ambos servicios. GitHub factura en función de la cantidad de repositorios privados que quieras tener (max. 50 por 50$/mes), por el contrario Bitbucket monetiza el servicio basándose en el número de colaboradores (ilimitados por 200$/mes).

La comunidad de Github es 4 veces la de Bitbucket por lo que en este caso no hay discusión alguna, 4M usuarios a 1M. Además curiosamente encontré algunos proyectos alojados en ambos sitios, por ejemplo GitHub hospeda el Kernel de Linux, MongoDB y Neo4j y Bitbucket Aldrin y TortoiseHg entre otros. Por lo que va a ser bastante más fácil encontrar información sobre GitHub.

Para autenticarnos Githb solo ofrece GitHub mientras que Bitbucket a parte de ofrecer la autenticación de GitHub ofrece la de Facebook, Twitter, OpenID y Google. En este caso no hay discusión alguna.

En conclusión, creo que la decisión depende mucho del tipo de proyecto. Yo personalmente uso GitHub porque es el primero que me enseñaron. Uso repositorios privados usando el email de la facultad, pero si no los tuviera probablemente usaría Bitbucket por sus similitudes y la probabilidad de “ocultar” los proyectos de clase.

La información la he recopilado básicamente de las dos fuentes siguientes:

Inicializar git en Linux

Según wikipedia: Git es un software de control de versiones, pensando en la eficiencia y la fiabilidad del mantenimiento de versiones de aplicaciones cuando estas tienen un gran número de archivos de código fuente.”

1- Instalar Git

$ sudo apt-get install git-core

2- Asignar una identificación

$ git config --global user.name "Paco"
$ git config --global user.email paco@ejemplo.com

Ahora para enlazar nuestro pc con la cuenta en github.

3 – Comprobando los certificados

$ cd ~/.ssh
$ ls -al

Si con los comandos anteriores encontramos alguno de los siguientes ficheros id_rsa.pub o id_dsa.pub puedes saltarte la generación de una nueva clave SSH e ir directamente a añadir tu clave en Github, paso 5.

4- Generar una nueva clave SSH

$ ssh-keygen -t rsa -C "paco@ejemplo.com"
$ ssh-add id_rsa

Te pedirán que entres una frase de contraseña (passphrase) dos veces (guardatela).

5- Añadir tu clave SSH a Github

Puedes printar por consola el texto usando el siguiente comando:

$ cat ~/.ssh/id_rsa.pub

Y luego desde pantalla copiar el texto.

Finalmente en Github iremos a Account settings en el apartado de SSH keys y una vez allí en el campo de la Key pegaremos el output de la consola anteriormente copiado.

Para comprobar que lo hemos hecho todo correctamente podemos usar el siguiente comando:

$ ssh -T git@github.com