Manual de Git
Manual de Git
Manual de Git
http://desarrolloweb.com/manuales/manual-de-git.html Página 1 de 54
Manual de Git
Esta es una compilación de artículos y vídeos destintados a aprender Git, el sistema de control de versiones
más utilizado en la actualidad, popularizado en gran medida gracias al servicio de gitHub, el más popular de
los hosting para repositorios Git.
Git es una de las herramientas fundamentales para cualquier equipo de desarrollo. "Ningún grupo de
programadores debería desarrollar software sin usar un sistema de control de versiones". Existen muchos en
el mercado, pero Git se destaca por ser un sistema de control de versiones distribuido que simplifica
bastante el trabajo en cualquier tipo de entorno. No queremos decir que Git sea simple, sino que hace
fáciles algunas tareas de control de versiones donde otros sistemas resultan bastante más complejos.
Git nos facilita llevar un control de los cambios de cualquier pieza de software, mediante el control de todos
los archivos que forman parte de un proyecto. De este modo puedes saber qué estados han tenido tus
archivos a lo largo del tiempo y permite que los componentes del equipo de desarrollo sincronicen sus
cambios los unos con los otros.
Todos deberíamos saber manejarnos con Git y comenzar no cuesta mucho trabajo, porque las cosas son
bastante sencillas. Otra cosa es cuando queramos realizar usos avanzados, pues a veces las cosas se pueden
complicar, sobre todo al gestionar ramas y solucionar conflictos.
Estos artículos te sacarán de dudas acerca de las nociones más básicas y muchos de los conceptos
avanzados que podrás encontrar en el día a día del uso de Git.
http://desarrolloweb.com/manuales/manual-de-git.html Página 2 de 54
Manual de Git
Las siguientes personas han participado como autores escribiendo artículos de este manual.
Israel Alcázar
Joan Leon
Jon Torrado
http://desarrolloweb.com/manuales/manual-de-git.html Página 3 de 54
Manual de Git
http://desarrolloweb.com/manuales/manual-de-git.html Página 4 de 54
Manual de Git
Introducción a Git
Git es un sistema extremadamente útil, pero resulta muy confuso cuando uno está iniciando. En estos
primeros artículos nuestros objetivos son los de aclarar conceptos necesarios para entender el sistema de
control de versiones y algunas partes de su operativa fundamental.
Los sistemas de control de versiones son programas que tienen como objetivo controlar los cambios en el
desarrollo de cualquier tipo de software, permitiendo conocer el estado actual de un proyecto, los cambios
que se le han realizado a cualquiera de sus piezas, las personas que intervinieron en ellos, etc.
Este artículo sirve como introducción a este tipo de herramientas de manera global, pero también para
conocer uno de los sistemas de control de versiones existentes en la actualidad que se ha popularizado
tremendamente, gracias al sitio Github. Se trata de Git, el sistema de control de versiones más conocido y
usado actualmente, que es el motor de Github. Al terminar su lectura entenderás qué es Git y qué es
Github, dos cosas distintas que a veces resultan confusas de entender por las personas que están dando sus
primeros pasos en el mundo del desarrollo.
Nota: Este texto es una transcripción libre de la primera media hora del hangout donde presentamos Git
y Github.
http://desarrolloweb.com/manuales/manual-de-git.html Página 5 de 54
Manual de Git
programando, conservando sus distintos estados. Es absolutamente necesario para el trabajo en equipo,
pero resulta útil incluso a desarrolladores independientes.
Aunque trabajemos solos, sabemos más o menos cómo surge la necesidad de gestionar los cambio entre
distintas versiones de un mismo código. Prueba de ello es que todos los programadores, más tarde o más
temprano, se han visto en la necesidad de tener dos o más copias de un mismo archivo, para no perder su
estado anterior cuando vamos a introducir diversos cambios. Para ir solucionando nuestro día a día
habremos copiado un fichero, agregándole la fecha o un sufijo como "antiguo". Aunque quizás esta acción
nos sirva para salir del paso, no es lo más cómodo ni mucho menos lo más práctico.
En cuanto a equipos de trabajo se refiere, todavía se hace más necesario disponer de un control de
versiones. Seguro que la mayoría hemos experimentado las limitaciones y problemas en el flujo de trabajo
cuando no se dispone de una herramienta como Git: machacar los cambios en archivos hechos por otros
componentes del equipo, incapacidad de comparar de manera rápida dos códigos, para saber los cambios
que se introdujeron al pasar de uno a otro, etc.
Además, en todo proyecto surge la necesidad de trabajar en distintas ramas al mismo tiempo, introduciendo
cambios a los programas, tanto en la rama de desarrollo como la que tenemos en producción.
Teóricamente, las nuevas funcionalidades de tu aplicación las programarás dentro de la rama de desarrollo,
pero constantemente tienes que estar resolviendo bugs, tanto en la rama de producción como en la de
desarrollo.
Nota: Un sistema en producción se refiere a que está disponible para los usuarios finales. O sea, es una
versión que está ya puesto en marcha y por lo tanto debería funcionar correctamente. Un sitio web,
cuando lo estás creando, está en su etapa de desarrollo y cuando lo liberas en el dominio definitivo y lo
pones a disposición de tu cliente, y/o los usuarios de Internet en general, se dice que está en
producción.
Para facilitarnos la vida existen sistemas como Git, Subversion, CVS, etc. que sirven para controlar las
versiones de un software y que deberían ser una obligatoriedad en cualquier desarrollo. Nos ayudan en
muchos ámbitos fundamentales, como podrían ser:
Comparar el código de un archivo, de modo que podamos ver las diferencias entre versiones
En definitiva, con estos sistemas podemos crear y mantener repositorios de software que conservan todos
los estados por el que va pasando la aplicación a lo largo del desarrollo del proyecto. Almacenan también las
personas que enviaron los cambios, las ramas de desarrollo que fueron actualizadas o fusionadas, etc. Todo
este mundo de utilidades para llevar el control del software resulta complejo en un principio, pero veremos
que, a pesar de la complejidad, con Git podremos manejar los procesos de una manera bastante simple.
http://desarrolloweb.com/manuales/manual-de-git.html Página 6 de 54
Manual de Git
Comenzaron a aparecer los sistemas de control del versionado del software allá por los años setenta, aunque
al principio eran bastante elementales. Para hacerse una idea, en los primeros sistemas existía una restricción
por la que sólo una persona podía estar a la vez tocando el mismo código. Es posible imaginarse que cosas
semejantes provocaban retraso en los equipos de trabajo, por ello, a lo largo de los años fueron surgiendo
nuevos sistemas de control de versiones, siempre evolucionando con el objetivo de resolver las necesidades
de los equipos de desarrollo.
Sistemas centralizados: En estos sistemas hay un servidor que mantiene el repositorio y en el que cada
programador mantiene en local únicamente aquellos archivos con los que está trabajando en un momento
dado. Yo necesito conectarme con el servidor donde está el código para poder trabajar y enviar cambios en
el software que se está programando. Ese sistema centralizado es el único lugar donde está todo el código
del proyecto de manera completa. Subversion o CVS son sistemas de control de versiones centralizados.
Sistemas distribuidos: En este tipo de sistemas cada uno de los integrantes del equipo mantiene una copia
local del repositorio completo. Al disponer de un repositorio local, puedo hacer commit (enviar cambios al
sistema de control de versiones) en local, sin necesidad de estar conectado a Internet o cualquier otra red.
En cualquier momento y en cualquier sitio donde esté puedo hacer un commit. Es cierto que es local de
momento, luego podrás compartirlo con otras personas, pero el hecho de tener un repositorio completo me
facilita ser autónomo y poder trabajar en cualquier situación. Git es un sistema de control de versiones
distribuido.
Nota: Muchas personas, llegados a este punto, quieren saber dónde se encuentra Github y qué tiene que
ver con Git, por lo que intentaremos aclarar algo en este sentido. Git es un sistema de control de
versiones distribuido. Con Git hacemos repositorios de software. GitHub es un servicio para hacer
hosting de repositorios de software que se administra con Git. Digamos que en GitHub mantienes una
copia de tus repositorios en la nube, que además puedes hacer disponible para otros desarrolladores. De
todos modos, sigue leyendo que más tarde en este mismo artículo te explicaremos todo esto con más
detalle.
Tanto sistemas distribuidos como centralizados tienen ventajas e inconvenientes comparativas entre los
unos y los otros. Para no hacer muy larga la introducción, cabe mencionar que los sistemas un poco más
antiguos como CVS o también Subversion, por sus características son un poco más lentos y pesados para la
máquina que hace de servidor central. En los sistemas distribuidos no es necesario que exista un servidor
central donde enviar los cambios, pero en caso de existir se requiere menor capacidad de procesamiento y
gestión, ya que muchas de las operaciones para la gestión de versiones se hacen en local.
Es cierto que los sistemas de control de versiones distribuidos están más optimizados, principalmente
debido al ser sistemas concebidos hace menos tiempo, pero no todo son ventajas. Los sistemas
centralizados permiten definir un número de versión en cada una de las etapas de un proyecto, mientras que
en los distribuidos cada repositorio local podría tener diferentes números de versión. También en los
centralizados existe un mayor control del desarrollo por parte del equipo.
De todos modos, en términos comparativos nos podemos quedar con la mayor ventaja de los sistemas
distribuidos frente a los sistemas centralizados: La posibilidad de trabajar en cualquier momento y lugar,
gracias a que siempre se mandan cambios al sistema de versionado en local, permite la autonomía en el
http://desarrolloweb.com/manuales/manual-de-git.html Página 7 de 54
Manual de Git
desarrollo de cada uno de los componentes del equipo y la posibilidad de continuar trabajando aunque el
servidor central de versiones del software se haya caído.
Sobre Git
Como ya hemos dicho, Git es un sistema de control de versiones distribuido. Git fue impulsado por Linus
Torvalds y el equipo de desarrollo del Kernel de Linux. Ellos estaban usando otro sistema de control de
versiones de código abierto, que ya por aquel entonces era distribuido. Todo iba bien hasta que los gestores
de aquel sistema de control de versiones lo convirtieron en un software propietario. Lógicamente, no era
compatible estar construyendo un sistema de código abierto, tan representativo como el núcleo de Linux, y
estar pagando por usar un sistema de control de versiones propietario. Por ello, el mismo equipo de
desarrollo del Kernel de Linux se tomó la tarea de construir desde cero un sistema de versionado de
software, también distribuido, que aportase lo mejor de los sistemas existentes hasta el momento.
Así nació Git, un sistema de control de versiones de código abierto, relativamente nuevo que nos ofrece las
mejores características en la actualidad, pero sin perder la sencillez y que a partir de entonces no ha parado
de crecer y de ser usado por más desarrolladores en el mundo. A los programadores nos ha ayudado a ser
más eficientes en nuestro trabajo, ya que ha universalizado las herramientas de control de versiones del
software que hasta entonces no estaban tan popularizadas y tan al alcance del común de los desarrolladores.
Git es multiplataforma, por lo que puedes usarlo y crear repositorios locales en todos los sistemas
operativos más comunes, Windows, Linux o Mac. Existen multitud de GUIs (Graphical User Interface o
Interfaz de Usuario Gráfica) para trabajar con Git a golpe de ratón, no obstante para el aprendizaje se
recomienda usarlo con línea de comandos, de modo que puedas dominar el sistema desde su base, en lugar
de estar aprendiendo a usar un programa determinado.
Para usar Git debes instalarlo en tu sistema. Hay unas instrucciones distintas dependiendo de tu sistema
operativo, pero en realidad es muy sencillo. La página oficial de descargas está en gitscm.com.
Allí encontrarás para descarga lo que se llama la "Git Bash" es decir, la interfaz de Git por línea de
comandos. Tienes que descargar aquella versión adecuada para tu sistema (o si estás en Linux instalarla
desde los repositorios dependiendo de tu distribución). Aparte de Windows, Linux o Mac, también hay
versión para Solaris. La instalación es muy sencilla, lo que resulta un poco más complejo al principio es el
uso de Git. No obstante, en futuros artículos podremos ver cuáles son los primeros pasos con Git y
veremos que para realizar unas cuantas funciones básicas el manejo resulta bastante asequible para cualquier
persona. Otra cosa es dominar Git, para lo cual te hará falta más tiempo y esfuerzo.
Sobre Github
Nota: Queremos agradecer a Alejandro Morales de Honduras, estas explicaciones sobre Github en el
http://desarrolloweb.com/manuales/manual-de-git.html Página 8 de 54
Manual de Git
hangout donde estuvo con nosotros como ponente. Su perfil de Github es github.com/alejandro.
Cabe destacar que Github es un proyecto comercial, a diferencia de la herramienta Git que es un proyecto
de código abierto. No es el único sitio en Internet que mantiene ese modelo de negocio, pues existen otros
sitios populares como Bitbucket que tienen la misma fórmula. No obstante, aunque Github tenga inversores
que inyectan capital y esté movido por la rentabilidad económica, en el fondo es una iniciativa que siempre
ha perseguido (y conseguido) el objetivo de hacer más popular el software libre. En ese sentido, en Github
es gratuito alojar proyectos Open Source, lo que ha posibilitado que el número de proyectos no pare de crecer,
y en estos momentos haya varios millones de repositorios y usuarios trabajando con la herramienta.
Pero ojo, para no llevarnos a engaño, al ser Git un sistema de control de versiones distribuido, no necesito
Github u otro sitio de alojamiento del código para usar Git. Simplemente con tener Git instalado en mi
ordenador, tengo un sistema de control de versiones completo, perfectamente funcional, para hacer todas
las operaciones que necesito para el control de versiones. Claro que usar Github nos permite muchas
facilidades, sobre todo a la hora de compartir código fuente, incluso con personas de cualquier parte del
mundo a las que ni conoces.
Esa facilidad para compartir código del repositorio alojado en la nube con Gitgub y la misma sencillez que
nos ofrece el sistema de control de versiones Git para trabajar, ha permitido que muchos proyectos Open
Source se hayan pasado a Github como repositorio y a partir de ahí hayan comenzado a recibir muchas más
contribuciones en su código.
Quizás te estés preguntando ¿cómo obtienen dinero en Github si alojar proyectos en sus repositorios es
gratis? Realmente solo es gratuito alojar proyectos públicos, de código abierto. El servicio también permite
alojar proyectos privados y para ello hay que pagar por una cuenta comercial o un plan de hosting que no es
gratuito. Existen planes iniciales, para alojar hasta cinco proyectos privados a partir de 7 dólares por mes, lo
que resulta bastante barato. Ese mismo plan es gratuito para los estudiantes universitarios.
Github además se ha convertido en una herramienta para los reclutadores de empleados, que revisan
nuestros repositorios de Github para saber en qué proyectos contribuimos y qué aportaciones hemos
realizado. Por ello, hoy resulta importante para los programadores no solo estar en Github sino además
mantener un perfil activo.
Conclusión
Esperamos que esta introducción al mundo de los sistemas de control de versiones te haya interesado y te
haya ayudado a aclarar diversos conceptos. En futuros artículos os explicaremos otros detalles que tienen
que ver con el uso de estos sistemas para versionar nuestro software. Si quieres acceder a formación
especializada no dejes de consultar el Curso de Git completo, intensivo y profesional que comenzamos en
EscuelaIT.
http://desarrolloweb.com/manuales/manual-de-git.html Página 9 de 54
Manual de Git
Curso de Git
Presentamos el curso de Git con esta primera clase experimental y gratuita en la que practicamos
con los comandos más fundamentales de la herramienta de control de versiones.
Vamos a conocer los comandos principales de Git por medio de una práctica en la que trataremos de
ilustrar cuál es el uso de la herramienta para gestionar las versiones de un proyecto. El objetivo es ver cómo
se crea un repositorio, cómo se actualizan los archivos del repositorio y cómo podemos volver hacia atrás
para recuperar el estado de los ficheros en versiones anteriores de desarrollo.
Posteriormente, veremos cómo se puede crear en Github un repositorio y cómo podemos mandar los
cambios de nuestro repositorio Git en local a Github, todo ello en el espacio de poco más de una hora de
clase.
En el vídeo trabajamos siempre con el terminal, introduciendo los comandos a mano. Aunque existen
diversos programas con interfaz gráfica que también te pueden facilitar las cosas, la única manera de
explotar todas las posibilidades de Git, es a través de la línea de comando.
Instalando Git
En el vídeo dedicamos unos momentos a mencionar las principales vías de instalación de Git en un
ordenador en local, para disponer de la terminal donde podremos lanzar los comandos de Git. Es muy fácil
de instalar, obteniendo la descarga desde su página oficial:
http://git-scm.com/
En Windows la descarga es un ejecutable que puedes instalar normalmente. En Mac también puedes
instalarlo a través del archivo que descargas, así como bajarlo usando Home Brew. En Linux lo encuentras
en todos los repositorios de las principales distribuciones, cuyos paquetes instalas con Aptget, Yum, etc.
Nota: Con la versión de Git para Windows no puedes ejecutar los comandos Git directamente desde la
consola de Windows, sino que tienes que usar el Git Bash, que obtendrás al instalar la herramienta.
No tenemos que asustarnos por usar la consola de comandos, pero si lo deseamos podemos usar
herramientas visuales, que hay un montón, así como también se puede integrar Git en la mayoría de los
IDE e incluso por medio de plugins en editores de código como Sublime Text.
http://desarrolloweb.com/manuales/manual-de-git.html Página 10 de 54
Manual de Git
Es tan sencillo como irse a un directorio de nuestra máquina desde la línea de comandos o desde Git Bash,
si estás en Windows. Empezamos con un directorio vacío, ya que se supone que estamos comenzando
nuestro proyecto y entonces podemos lanzar el comando:
git init
A partir de ese momento tienes todo un repositorio de software completo en tu máquina del proyecto que
tenías en ese directorio. Puedes crear los archivos que quieras en el directorio (tu proyecto) y luego puedes
enviarlos al repositorio haciendo un "commit".
Nota: La gran diferencia de Git con respecto a otros repositorios es que está distribuido. Todos los
repositorios en cada máquina están completos, de modo que esa máquina podría ser perfectamente
autónoma y desarrollar código en cualquier parte del proyecto. Por eso yo puedo hacer commit al
repositorio local, independientemente de si el ordenador está o no conectado a una red.
Antes de enviar cambios al repositorio, lo que se conoce como hacer commit, tienes que enviar los ficheros
a un área intermedia llamada "staging area" en donde se almacenan los archivos que serían actualizados en el
próximo commit. Éste es uno de los conceptos esenciales para aprender Git y para mandar los ficheros a
este área tenemos que añadirlos al repositorio.
git add
Con ese comando paso los ficheros al "staging area" y a partir de ahí podremos hacer el commit sobre esos
ficheros.
Ese comando permite enviar los archivos a una especie de base de datos donde puedes colocar los archivos
cuyo estado queremos siempre memorizar.
Aquí en el vídeo hablamos brevemente de las ramas y de cómo se gestionan en Git y mencionamos que la
rama principal, que se crea al iniciarse el repositorio; se llama "master". También vemos cómo localizar los
commits a través de su identificador, lo que nos sirve para poder movernos entre las actualizaciones de
software.
Cada vez que se modifica un fichero, se tiene que agregar al área intermedia con el comando "add" y luego
hacer el commit para que se actualice el repositorio con los archivos nuevos o actualizados. Eso significa
que en teoría cada vez que cambias un archivo tendrías que añadirlo al Staging area para poder hacer el
commit, aunque más adelante veremos que hay maneras de automatizar las tareas un poco más y, mediante
atajos, poder resumir el paso de hacer el "add" cuando se ha cambiado el código de un fichero.
http://desarrolloweb.com/manuales/manual-de-git.html Página 11 de 54
Manual de Git
Deshacer cambios
En cualquier momento puedo deshacer cambios que haya realizado en los archivos, recuperando versiones
anteriores que podamos tener en el repositorio. Podría descartar los cambios que tengo en staging area.
En Git puedes tener código principalmente en tres lugares, el directorio de trabajo, en el Staging area o en
una versión que tengas en un commit antiguo de ese repositorio. Existen diferentes comandos para hacer
todas estas cosas, dependiendo del lugar de Git donde tengas el código que quieres recuperar. Pero lo
verdaderamente útil y potente que tenemos con el control de versiones es poder recuperar archivos
realizados commit anteriores, en el último commit, pero también en otros que tengas más antiguos.
Existen muchos comandos para recuperar código anterior como "reset", en el vídeo se ven varios ejemplos,
se explican también como fusionar commits y muchas otras cosas interesantes.
Github
En el vídeo se ve después cómo trabajar con Github, mostrando las posibilidades de este servicio de
almacenamiento de repositorios en remoto. Vemos cómo se crea un repositorio en Git y cómo se puede
clonar en nuestro sistema local.
Para trabajar con Github tenemos algunas características importantes como las claves de seguridad SSH,
que tenemos que generar en local y llevarnos a Github para dar un nivel de seguridad adicional a las
actualizaciones contra los repositorios.
En el vídeo se muestra cómo se crea el repositorio en Github y cómo se clona en local por medio del
comando "clone". Una vez clonado se muestra cómo se actualizan los archivos en local, se añaden al área
intermedia con "add" y se hace el "commit" al repositorio en local. Por último se envían los cambios al
servidor remoto con "push".
Curso de Git
Todo el material que se ve en el vídeo no es más que la punta del iceberg, es decir, una pequeña muestra de
entre todas las enormes posibilidades de Git. Esta clase de una hora seguro que te servirá para dar los
primeros pasos con Git, pero hay mucho más detrás de esta herramienta. Hay todavía muchas cosas que ver
y conceptos fundamentales como hacer "fork", "pull", "merge", "checkout", "fetch", "branch"...
Todo ese material lo veremos con detalle en el Curso de Git de EscuelaIT, a lo largo de diez horas de clases
en directo que se celebrarán durante algo más de una semana. Este vídeo es solo una pequeña muestra de
los contenidos que se verán allí con todo detalle.
http://desarrolloweb.com/manuales/manual-de-git.html Página 12 de 54
Manual de Git
En este artículo te explicamos los primeros pasos con Git y GitHub, a partir de la transcripción de unas
clases en directo que fueron emitidas en DesarrolloWeb.com antes del curso de Git que se impartió en
EscuelaIT.
Asimismo, encontrarás los vídeos de cada uno de los bloques de la clase junto con un resumen del vídeo a
modo de transcripción de lo que se contó en esta clase. Son ideales para comenzar con el sistema de control
de versiones Git. En este caso para entender unos conceptos básicos y crear tu entorno para poder trabajar
con Git.
Antes de meternos a fondo con Git y comenzar a practicar, nos interesa cubrir algunas de las típicas dudas
que se tiene cuando se comienza con este sistema de control de versiones. Se trata de ver algunas claves
rápidas sobre las características de Git, el flujo de trabajo y algunas diferencias con GitHub.
En Git, cada desarrollador dispone de un repositorio completo instalado en su máquina; es algo inherente a
los sistemas de control de versiones distribuidos, como vimos en el artículo sobre Qué son Git y GitHub.
Es condición indispensable. Todos los cambios de nuestros archivos a lo largo del desarrollo los vamos a
tener en local. Opcionalmente, esos cambios los enviaremos a repositorios remotos, como puede ser
GitHub o cualquier otro.
Esto quiere decir que mi máquina tendrá todo lo que necesito para trabajar. Tendremos una copia del
repositorio completo, cada uno de los archivos de todo el proyecto. Con el repositorio Git en local, luego
decidiré a qué otros servidores o máquinas mando mis cambios.
http://desarrolloweb.com/manuales/manual-de-git.html Página 13 de 54
Manual de Git
GitHub es un hosting de repositorios Git, por tanto, el uso que le daremos es como repositorio remoto. Pero
debe quedar claro que primero debo tener los cambios en el repositorio local y luego podré "empujar" esos
cambios al repositorio remoto.
Nota: Como convención, usaremos el verbo "empujar" refiriéndonos a la acción que se hace con el
comando "push" de Git, que veremos dentro de poco. De momento, para que nos entienda todo el
mundo y hacernos una idea mejor del funcionamiento de Git, podemos limitarnos a usar términos
llanos del español, ya habrá momento de ponerse técnicos.
Por tanto, ya se ve la primera diferencia entre Git y GitHub: Git es la tecnología para hacer el control de
versiones y GitHub simplemente es un hosting de repositorios Git, con una interfaz web que nos ofrece
algunas utilidades basadas en el propio control de versiones Git.
En GitHub puedo tener repositorios diversos y si quiero trabajar con alguno de ellos, primero debo tenerlo
en local. Ojo, no necesitamos tener todos los repositorios que has publicado en GitHub en local, solo
aquellos con los que vayamos a trabajar. En el momento que los tenemos en local podremos hacer cambios,
almacenarlos en nuestro repositorio local y cuando lo juzguemos oportuno, enviarlo (empujar, push) a tantos
servidores o repositorios remotos como queramos.
Nota: Ten en cuenta también que al referirnos a GitHub queremos que se entienda como un
repositorio remoto en general. Es decir, realmente lo que digamos de GitHub en líneas generales sirve
para entender otros servicios de hosting de repositorios Git como Bitbucket.
Para concluir y tener más claro el flujo de trabajo con un control de versiones Git, imaginar un equipo de
trabajo con varios componentes. Todos y cada uno de los desarrolladores deberán tener una copia completa
de todo el repositorio de software que se está desarrollando. Luego el equipo decidirá a qué servidor con un
repositorio remoto quiere enviar los cambios.
Cada desarrollador podrá enviar los cambios que tiene en local hacia el repositorio remoto cuando quiera y
ese repositorio remoto lo usarán todos los componentes del equipo para sincronizarse y tener la versión
más nueva del código en cada momento que lo deseen.
Este esquema podemos considerarlo como la base del trabajo con Git, aunque luego en la práctica la cosa se
complica porque habrá conflictos y tendrás que resolverlos.
Instalar Git
Tener Git instalado en local es condición indispensable para trabajar con el sistema de control de versiones.
http://desarrolloweb.com/manuales/manual-de-git.html Página 14 de 54
Manual de Git
El proceso para instalar Git es bien sencillo porque no difiere de la instalación de cualquier otro software
que hayas hecho.
Te tienes que descargar la versión de tu sistema operativo en la página oficial (o si usas Linux lo bajarás de
los repositorios de software que usas habitualmente en tu distribución).
gitscm.com
Lo instalas como cualquier otro software. Si estás en Windows tendrás un asistente al que harás "siguiente,
siguiente" hasta acabar el proceso. Puedes ver este vídeo que aclara algunos puntos sobre la instalación.
El único sitio donde puedes tener dudas es en el paso que te dice si quieres instalarlo como comando en la
línea de comandos de tu consola o si simplemente quieres el "git bash".
Si lo instalas en la propia consola del Windows, la única ventaja es que lo tendrás disponible desde la
ventana de línea de comandos de Windows y podrás hacer desde allí los comandos de Git. Si lo instalas solo
en Git Bash no habrá más problemas, solo que cuando quieras usar Git tendrás que abrir la consola
específica de Git que ellos llaman "git bash".
La manera más sencilla de saber si Git está instalado en tu sistema es a través del comando:
git version
Esto te mostrará en la pantalla el número de la versión de Git que tengas instalada. Si en Windows instalaste
Git en consola (la ventana de línea de comandos), observarás que en cualquier consola de comandos de
Windows tienes disponible Git. Si lo instalaste únicamente en el Git Bash, no tendrás ese comando y Git no
está disponible desde la consola de Windows.
Git Bash es la línea de comandos de Git para Windows, que además te permite lanzar comandos de Linux
básicos, "ls -l" para listar archivos, "mkdir" para crear directorios, etc. Es la opción más común para usar
Git en Windows.
Es indiferente si instalas Git en la línea de comandos del Windows o si lo instalas solamente en el Git Bash.
Simplemente escoge la que te sea más cómoda.
http://desarrolloweb.com/manuales/manual-de-git.html Página 15 de 54
Manual de Git
Antes que nada, inmediatamente después de instalar Git, lo primero que deberías hacer es lanzar un par de
comandos de configuración.
Con estos comandos indicas tu nombre de usuario (usas tu nombre y apellidos generalmente) y el email. Esta
configuración sirve para que cuando hagas commits en el repositorio local, éstos se almacenen con la
referencia a ti mismo, meramente informativa. Gracias a ello, más adelante cuando obtengas información de
los cambios realizados en el los archivos del "repo" local, te va a aparecer como responsable de esos
cambios a este usuario y correo que has indicado.
http://desarrolloweb.com/manuales/manual-de-git.html Página 16 de 54
Manual de Git
Ahora vamos a explicar los procedimientos básicos en la operativa del día a día con Git. Acciones como
añadir código al repositorio, compartir el código a través de servidores remotos donde nos permitan
sincronizar el proyecto entre los integrantes de un equipo y evitar que Git tenga en cuenta archivos que no
deberían estar en el proyecto.
En los artículos anteriores de Git hemos visto los pasos iniciales que se deben realizar para poder usar Git,
o mejor dicho, "comenzar a usarlo". Sin embargo, aún no hemos empezado a trabajar con repositorios y a
controlar el estado de nuestro software a través de sus diversas versiones.
Si has llegado aquí y no sabes qué es este sistema de control de versiones, te recomendamos acceder al
artículo donde explicamos cómo instalar y configurar Git. Si ya has realizado esos primeros pasos, sigue
leyendo.
A continuación te explicamos cómo crear tu primer repositorio de software y cómo enviar archivos al
repositorio para que comiencen a ser rastreados por Git y que el sistema de control de versiones almacene
sus diversos estados a lo largo del tiempo.
Una vez instalado Git, vamos a trabajar con la consola de comandos para aprender de verdad a usar este
sistema. Existen diversas aplicaciones de interfaz gráfica para trabajar con Git, pero no son realmente las
mejores opciones para aprender a usar este sistema. Es por ello que te recomendamos aprender por línea de
comandos, tal como te explicamos en estos artículos.
Si estamos en Windows, podremos abrir el "Git Bash" (ver artículo mencionado anteriormente) y si estamos
http://desarrolloweb.com/manuales/manual-de-git.html Página 17 de 54
Manual de Git
en Linux / Mac, simplemente tendremos que abrir un terminal del sistema operativo.
Una vez dentro de tu consola de comandos, vamos a crear un directorio donde vamos a dejar todos
nuestros repositorios. Aunque realmente puedes tenerlos dispersos en las carpetas que desees, eso es
indiferente.
Nota: Si no sabes qué es un repositorio, podemos aclarar que es simplemente como una estantería de tu
biblioteca donde guardas un software. Es un lugar, una carpeta, donde almacenas todos los archivos de
un proyecto y cuando trabajas con Git tienes la posibilidad de tener no solo el estado actual de tus
ficheros, sino el estado por el que han pasado en todas sus versiones a lo largo de la vida de ese
software.
Para trabajar con Git o Github (sabemos las diferencias porque ya lo explicamos en el artículo de conceptos
iniciales) tenemos dos formas de trabajar:
2) Clonar un repositorio de Github (u otro hosting de repositorios) para traernos a local el repositorio
completo y empezar a trabajar con ese proyecto.
Vamos a elegir de momento la opción 1) que nos permitirá comenzar desde cero y con la que podremos
apreciar mejor cuáles son las operaciones básicas con Git. En este sentido, cualquier operación que realizas
con Git tiene que comenzar mediante el trabajo en local, por lo que tienes que comenzar por crear el
repositorio en tu propia máquina. Incluso si tus objetivos son simplemente subir ese repositorio a Github
para que otras personas lo puedan acceder a través del hosting remoto de repositorios, tienes que comenzar
trabajando en local.
Entonces, estando en una carpeta de tu ordenador donde hemos dicho que vamos a crear todos nuestros
repositorios, puedes crear una carpeta específica para tu primer proyecto con Git. La carpeta de tu proyecto
la puedes crear con el explorador de archivos o si quieres por línea de comandos, es indiferente.
Una vez creada tu carpeta puedes crear archivos dentro. Como estamos hablando de desarrollo de software,
los archivos que meterás dentro de tu carpeta contendrán el código de tu aplicación, página web, etc.
Nota: Para crear los archivos, en el flujo de trabajo común de un desarrollador usarás tu editor de
código preferido: Eclipse, Sublime Text, Komodo, Notepad++, Gedit, PhpStorm, etc. Como prefieras.
También, por supuesto, puedes crear tu archivo por línea de comandos y editarlo si estás en Linux con
el conocido Vim o cualquier otro editor de interfaz solo texto.
Para crear tu repositorio Git, donde monitorizamos los archivos de un proyecto, tienes que realizar una
http://desarrolloweb.com/manuales/manual-de-git.html Página 18 de 54
Manual de Git
operación previa. Es la inicialización del repositorio Git que queremos crear en la carpeta de tu proyecto y
es una operación que deberás realizar una única vez para este proyecto.
Nota: Cada proyecto lo tendrás en una carpeta distinta y será un repositorio independiente. Esta
operación de inicialización de tu repositorio, por tanto, la tendrás que realizar una única vez para cada
proyecto que quieras controlar sus versiones por medio de Git.
Así pues, antes que nada (antes de enviar cualquier archivo al repositorio), creo el repositorio Git con el
comando "git init".
git init
Una vez has inicializado el repositorio, podrás observar que se ha creado una carpeta en tu proyecto llamada
".git" . Si ves esa carpeta en tu proyecto es que el repositorio se ha inicializado correctamente y que ya tienes
convertida esa carpeta en un repositorio de software Git.
Nota: Los archivos o carpetas en Linux / Mac que comienzan por un punto están ocultos en el sistema
de archivos. Para verlos tendrás que ejecutar el comando "ls -la".
En la carpeta .git es donde se va a guardar toda la información relativa al repositorio. Resultará obvio, pero
conviene decir que nunca se debe borrar esa carpeta y tampoco deberíamos acceder de forma directa a sus
contenidos, ya que nos vamos a comunicar siempre con el repositorio por medio de comandos.
Una vez que crees tus primeros archivos, puedes comenzar a trabajar con Git, enviando esos ficheros al
repositorio. Aunque los archivos estén en la carpeta de tu proyecto y hayas iniciado el repositorio Git
previamente, el sistema de control de versiones no los está monitorizando, por lo que a nivel de tu
repositorio Git todavía es como si no estuvieran.
A esa acción de guardar los archivos en el repositorio se llama, en la jerga de Git, hacer un "commit". En
este caso el commit lo estás haciendo en local, porque los archivos los estás enviando a tu repositorio local
que tienes en tu máquina.
1) Tengo que añadir el fichero a una zona intermedia temporal que se llama "Zona de Index" o "Staging
Area" que es una zona que utiliza Git donde se van guardando los ficheros que posteriormente luego se van
a hacer un commit.
Cualquier archivo que quieras mandar a la zona de index lo haces con el comando "add".
http://desarrolloweb.com/manuales/manual-de-git.html Página 19 de 54
Manual de Git
Una vez añadido podrías ver que realmente tienes ese fichero en el "staging area", mediante el comando
"status".
git status
Verás que, entre las cosas que te aparecen como salida de ese comando, te dice que tienes tu fichero
añadido como "new file". Además te dice que estos cambios están preparados para hacer commit.
2) Tengo que enviar los archivos de la zona de Index al repositorio, lo que se denomina el commit
propiamente dicho. Lo haces con el siguiente comando:
Con esto ya tenemos nuestro primer archivo dentro del repositorio. A partir de aquí podremos mantener y
controlar los cambios que se hagan sobre este archivo (u otros que hayamos incluido por medio del
commit).
Si haces de nuevo un comando "git status" podrás comprobar que no hay nada para enviar al repositorio.
Eso quiere decir que la zona de Index está limpia y que todos los cambios están enviados a Git.
Hasta este punto hemos podido aprender a crear nuestro repositorio y enviar los primeros cambios por
medio de la operación de commit. Ahora puedes probarlo en tu sistema para comenzar a experimentar Git.
En las siguientes entregas continuaremos explorando el flujo de trabajo con Git, y mejorando esta primera
aproximación con nuevos comandos que te permitan hacer mas cosas y facilitarte el trabajo resumiendo las
operaciones ya comentadas en menos pasos.
A continuación puedes ver un vídeo que hemos resumido en este artículo y donde podrás ver todas estas
operaciones en directo y explicadas en directo y paso por paso.
En este artículo vamos a abordar una operativa básica del día a día del desarrollador y el trabajo con el
http://desarrolloweb.com/manuales/manual-de-git.html Página 20 de 54
Manual de Git
sistema de control de versiones Git. Básicamente explicaremos los pasos para crear un nuevo repositorio en
Github con el código de un proyecto.
Este artículo está motivado por una duda respondida a un compañero de la comunidad que tenía dudas con
el sistema de control de versiones. La duda era la siguiente:
Me han pedido que suba un proyecto, el código, a Github en un nuevo repositorio que tengo que crear. Mi
problema es que desconozco esta operativa y por miedo a parecer inexperto prefiero preguntaros a
vosotros. Imagino que esto se hace con Git, pero no se muy bien como hacerlo... si tengo que hacerlo
publico, privado, si subo el zip o como lo hago para que el código aparezca en Github.
Nuestra respuesta, viene a continuación, explicando toda la operativa paso a paso. De todos modos, esta
respuesta te quedaría mucho más clara si echas un vistazo al Manual de Git de DesarrolloWeb.com, o bien
el Curso de Git de EscuelaIT que es muchísimo más avanzado.
Realmente no sé muy bien en qué momento del proceso tienes la duda, pero parece un poco general del uso
de Git, así que te explico en pocas palabras cómo debes de hacerlo.
Desde Github creas un repositorio con el botón "+" de arriba a la derecha. Obviamente tienes que haberte
registrado en Github para comenzar. El registro es gratuito.
Apareces en una página para que indiques los datos del repositorio. Básicamente tienes que darle un
nombre, elegir si es público o privado y opcionalmente una descripción. Yo la parte que dice "Initialize this
repository with a README" siempre la dejo desmarcada. Luego comentaré algo más sobre el
"README".
http://desarrolloweb.com/manuales/manual-de-git.html Página 21 de 54
Manual de Git
El tema de hacer el repositorio público o privado te lo tienen que decir los que te han pedido realizar esta
tarea. Si no me equivoco, para hacer repositorios en privado debes tener una cuenta de pago en Github, por
lo que entiendo que ellos te habrán pedido hacerlo público. Tendrás que salir de dudas con ellos
Una vez que creas el repositorio mantén en el navegador de momento la página que te aparece en Github,
porque tiene información importante que en seguida usaremos.
¿Sabes lo q tienes que hacer para subir los archivos? Es fácil. No lo subes por Zip ni nada de eso, sino que
usas el propio Git, el sistema de control de versiones. La operación que tienes que realizar se llama "push".
Yo lo hago desde la línea de comandos, pero hay programas de interfaz gráfica que también te hacen estos
pasos quizás más fácilmente. Si no tienes instalado Git, primero tendrás que ver cómo se hace (es descargar
un ejecutable e instalarlo) en este artículo: Instalar Git y primeros pasos.
Nota: Ten en cuenta que el si estás en Linux o Mac usarás el terminal del propio sistema operativo,
pero si estás en Windows usarás "Git Bash" que es el terminal de línea de comandos que se instala
cuando instalas Git, que es mucho mejor que el terminal básico que viene con Windows. El comando
para moverte entre carpetas es "cd" seguido del nombre de la carpeta donde te quieres meter.
http://desarrolloweb.com/manuales/manual-de-git.html Página 22 de 54
Manual de Git
Una vez tienes Git instalado, tienes que ir, en el terminal, a la carpeta de tu proyecto, entonces allí generas tu
repositorio en local con la orden "init" (si es q no lo has hecho ya).
git init
Luego, desde la carpeta de haces el comando "add" para agregar todos los archivos al "staging area".
git add .
Luego lanzas el comando para el commit, que se lleva los archivos al repositorio para control de cambios.
Es el siguiente:
En vez de ‘mi primer commit’ pon algo que sea menos genérico y más relevante, relacionado con tu
proyecto y el estado en el que estás ;)
Luego tienes q hacer el "push" desde tu repositorio local a remoto con los comandos que aparecen en la
página de Github que hay justo después de haber creado el repositorio (allí donde te pedí que permanecieras
con el navegador). Vuelve a tu navegador y los verás, abajo del todo, en la alternativa de subir un repositorio
existente en local.
Inisisto que estos dos comandos te aparecen justo en la página que llegas al crear un repositorio. Es bueno
copiar y pegar de allí, porque aparecerá la URL de tu repositorio en GitHub y así no corres el riesgo de
equivocarte al escribir.
Para acabar, o antes de subir el proyecto con push, por buenas prácticas, deberías ponerle un README.md
http://desarrolloweb.com/manuales/manual-de-git.html Página 23 de 54
Manual de Git
a tu proyecto (generas el archivo en local y haces el git add . para que se agregue y luego el commit).
Ese archivo README.md tiene sintaxis Markdown, que permite escribir cosas como enlaces,
encabezamientos, negritas, etc.
Luego también es recomendable tener un archivo .gitignore, del que podemos hablar en otro momento,
pero básicamente hace que se ignoren para Git ciertas carpetas o archivos que no deberían subirse al control
de versiones.
Creo que es todo. Seguro que te he aclarado varios puntos. Inténtalo y peléate un poco, que así es como se
aprende. Esta operativa puede parecer complicada al principio, pero cuando la haces unas cuantas veces la
cosa va quedando má clara.
Archivo .gitignore
Qué es el archivo gitignore, para qué sirve, cómo implementar el gitignore en un repositorio Git.
Git tiene una herramienta imprescindible casi en cualquier proyecto, el archivo "gitignore", que sirve para
decirle a Git qué archivos o directorios completos debe ignorar y no subir al repositorio de código.
Su implementación es muy sencilla, por lo que no hay motivo para no usarlo en cualquier proyecto y para
cualquier nivel de conocimientos de Git que tenga el desarrollador. Únicamente se necesita crear un archivo
especificando qué elementos se deben ignorar y, a partir de entonces, realizar el resto del proceso para
trabajo con Git de manera habitual.
En el gitignore se especificarán todas las rutas y archivos que no se requieren y con ello, el proceso de
control de versiones simplemente ignorará esos archivos. Es algo tan habitual que no debíamos de dejarlo
pasar en el Manual de Git.
Piensa que no todos los archivos y carpetas son necesarios de gestionar a partir del sistema de control de
versiones. Hay código que no necesitas enviar a Git, ya sea porque sea privado para un desarrollador en
http://desarrolloweb.com/manuales/manual-de-git.html Página 24 de 54
Manual de Git
concreto y no lo necesiten (o lo deban) conocer el resto de las personas. Pueden ser también archivos
binarios con datos que no necesitas mantener en el control de versiones, como diagramas, instaladores de
software, etc.
El ejemplo más claro que se puede dar surge cuando se trabaja con sistemas de gestión de dependencias,
como npm, Bower, Composer. Al instalar las dependencias se descargan muchos archivos con documentos,
tests, demos, etc. Todo eso no es necesario que se mantenga en el sistema de gestión de versiones, porque
no forma parte del código de nuestro proyecto en concreto, sino que es código de terceros. Si Git ignora
todos esos archivos, el peso total de proyecto será mucho menor y eso redundará en un mejor
mantenimiento y distribución del código.
Otro claro ejemplo de uso de gitignore son los archivos que crean los sistemas operativos automáticamente,
archivos que muchas veces están ocultos y no los vemos, pero que existen. Si no evitas que Git los procese,
estarán en tu proyecto como cualquier otro archivo de código y generalmente es algo que no quieres que
ocurra.
Implementar el gitignore
Como hemos dicho, si algo caracteriza a gitignore es que es muy fácil de usar. Simplemente tienes que crear
un archivo que se llama ".gitignore" en la carpeta raíz de tu proyecto. Como puedes observar, es un archivo
oculto, ya que comienza por un punto ".".
Nota: Los archivos cuyo nombre comienza en punto "." son ocultos solamente en Linux y Mac. En
Windows los podrás ver perfectamente con el explorador de archivos.
Dentro del archivo .gitignore colocarás texto plano, con todas las carpetas que quieres que Git simplemente
ignore, así como los archivos.
bower_components/
*.DS_Store
Estaremos evitando que el sistema de control de versiones procese todos los archivos acabados de
.DS_Store, que son ficheros de esos que crea el sistema operativo del Mac (OS X) automáticamente.
Hay muchos tipos de patrones aplicables a la hora de especificar grupos de ficheros, con comodines
diversos, que puedes usar para poder indicar, de manera muy específica, lo que quieres que Git no procese
http://desarrolloweb.com/manuales/manual-de-git.html Página 25 de 54
Manual de Git
Dado que la mayoría de las veces los archivos que necesitas ignorar son siempre los mismos, atendiendo a
tu sistema operativo, lenguajes y tecnologías que uses para desarrollar, es muy sencillo crear un archivo
.gitginore por medio de una especie de plantillas.
Existe una herramienta online que yo uso siempre que se llama gitignore.io. Básicamente permite escribir en
un campo de búsqueda los nombres de todas las herramientas, sistemas, frameworks, lenguajes, etc. que
puedas estar usando. Seleccionas todos los valores y luego generas el archivo de manera automática.
Por ejemplo una alternativa sería escribir las siguientes palabras clave: OSX, Windows, Node, Polymer,
SublimeText.
Escribes cada una de las palabras y pulsas la tecla enter para ir creando los "chips". Te debe aparecer algo
como esto:
Una vez generado el código de tu gitignore, ya solo te queda copiarlo y pegarlo en tu archivo .gitignore, en
la raíz de tu proyecto.
Nos ha pasado a todos más de una vez que se nos olvida generar el correspondiente .gitignore después de
haber hecho un commit. Observerás que, por mucho que estés diciendo que ahora sí quieres ignorar ciertas
carpetas o rutas, éstas continúan en tu repositorio. Básicamente, ésto es así porque estaban allí antes de
informar que se debían ignorar. En los siguientes commits serán ignoradas todas las modificaciones de las
carpetas en cuestión, pero lo que había antes perdurará en el repositorio.
Por ejemplo, imagina que estás en un proyecto NodeJS. Olvidas de hacer el gitignore de la carpeta
"node_modules". Entonces haces un commit y metes un montón de dependencias a tu repositorio git, que
no debían estar. Si ves ahora en un sistema de interfaz gráfica tu repositorio (o subiéndolo a Github) podrás
observar que los archivos de "node_modules" están ahí.
Luego creas tu .gitignore con el código para node, que puede ser muy grande pero donde querrás al menos
ignorar los gestores de dependencias que puedas estar usando, como por ejemplo:
http://desarrolloweb.com/manuales/manual-de-git.html Página 26 de 54
Manual de Git
node_modules
jspm_packages
Nota: Las líneas que comienzan por "#" en un .gitignore son simplemente comentarios.
Ahora haces nuevos commits pero los archivos no se borran. ¿Qué hacer entonces?
Básicamente lo solucionas con un comando de Git llamado "rm" que básicamente funciona igual que el
comando del mismo nombre que usas para borrar archivos en una consola del estilo de Mac o Linux.
Luego tendrás que hacer un commit para que esos cambios se apliquen al sistema de control de versiones.
A partir de ahora esa carpeta no se verá en tu repositorio y gracias a tu .gitignore tampoco se tendrá en
cuenta en las siguientes operaciones que realices mediante Git.
Git log
Ver el historial de commits de un proyecto con git log, cómo hacerlo, cuáles son las opciones más
útiles para sacarle partido al log.
A veces necesitamos examinar la secuencia de commits (confirmaciones) que hemos realizado en la historia
de un proyecto, para saber dónde estamos y qué estados hemos tenido a lo largo de la vida del repositorio.
Esto lo conseguimos con el comando de Git "log".
Una vez tenemos el listado en nuestro terminal podemos observar los mensajes de los commits y su
identificador, pero también podríamos obtener más información de un commit en concreto, sus
modificaciones en el código, o tener la referencia para moverse hacia atrás en el histórico de commits. En
este artículo del Manual de Git vamos a ver algunas de estas acciones más comunes para empezar a practicar
con el log de Git.
http://desarrolloweb.com/manuales/manual-de-git.html Página 27 de 54
Manual de Git
El comando que podemos usar para ver el histórico de commits, estando situados en la carpeta de nuestro
proyecto, es:
git log
Con esto obtenemos una salida como la que sigue en la siguiente imagen:
http://desarrolloweb.com/manuales/manual-de-git.html Página 28 de 54
Manual de Git
Nota: El listado puede contener una cantidad de commits que no quepa en la ventana del terminal, en
ese caso podemos ir a la siguiente página con la barra espaciadora. O puedes moverte mediante los
cursores del teclado, arriba y abajo. Salimos de nuevo a la entrada de comandos con "CTRL + z".
Como puedes observar, el listado de commits está invertido, es decir, los últimos realizados aparecen los
primeros.
commit cd4bcc8bad230f895fcadd5baf258715466a8eaf
Es muy útil lanzar el log en una sola línea, lo que permite que veamos más cantidad de commits en la
pantalla y facilita mucho seguir la secuencia, en vez de tener que ver un montón de páginas de commits.
http://desarrolloweb.com/manuales/manual-de-git.html Página 29 de 54
Manual de Git
Nota: Esta opción en realidad es un atajo de escribir estas dos opciones: "--pretty=oneline --abbrev-
commit". La primera indica que justamente que pongas un commit por línea y la segunda te indica que
muestres la cadena resumida con el identificador del commit, en vez de la cadena de 40 bytes
hexadecimal normal. El identificador resumido es suficiente para referirse de manera inequívoca a un
commit, ya que el resto del identificador contiene información sobre el usuario que hizo el commit y
otros datos de control.
Si tu proyecto ya tiene muchos commits, decenas o cientos de ellos, quizás no quieras mostrarlos todos, ya
que generalmente no querrás ver cosas tan antiguas como el origen del repositorio. Para ver un número de
logs determinado introducimos ese número como opción, con el signo "-" delante (-1, -8, -12...).
git log -3
Si queremos que el log también nos muestre los cambios en el código de cada commit podemos usar la
opción -p. Esta opción genera una salida mucho más larga, por lo que seguramente nos tocará movernos en
la salida con los cursores y usaremos CTRL + Z para salir.
git log -2 -p
Eso nos mostrará los cambios en el código de los últimos dos commits. Sin embargo, si quieres ver los
cambios de cualquier otro commit que no sea tan reciente es mucho más cómodo usar otro comando de git
que te explicamos a continuación "git show".
Podemos ver qué cambios en el código se produjeron mediante un commit en concreto con el comando
"show". No es algo realmente relativo al propio log del commit, pero sí que necesitamos hacer log primero
para ver el identificador del commit que queremos examinar.
Realmente nos vale con indicarle el resumen de identificador del commit, que vimos con el modificador --
oneline.
Nota: Igual que en el log, para ver más cosas que no quepan en la pantalla, tenemos que usar los
cursores del teclado, o pasar a la siguiente página con la barra espaciadora. Salimos con "CTRL + z".
http://desarrolloweb.com/manuales/manual-de-git.html Página 30 de 54
Manual de Git
Podrás observar que al mostrar la información del commit te indica todas las líneas agregadas, en verde y
con el signo "+" al principio , y las líneas quitadas en rojo y con el signo "-" al principio.
Si tu repositorio tiene ramas (branch) y quieres que el log te muestre más información de las ramas
existentes, sus uniones (merges) y cosas así, puedes hacer uso de la opción --graph.
Ese comando te mostrará los commit en una línea y las ramas en las que estabas, con sus diferentes
operaciones. La salida del git log será algo como esto:
Nota: En el Manual de Git se explica en otro artículo el trabajo con ramas. De hecho, en este diagrama
se pueden ver las branch y merges que realizamos como práctica en aquel artículo.
Conclusión
Hemos visto algunas de las opciones más útiles y recurrentes cuando quieres revisar el log de un repositorio
Git. Pero hay decenas de otras configuraciones y opciones del comando existentes para conseguir infinidad
de nuevos comportamientos.
http://desarrolloweb.com/manuales/manual-de-git.html Página 31 de 54
Manual de Git
La referencia completa de opciones del comando "git log" la puedes ver en esta dirección: https://git-
scm.com/docs/git-log
En el día a día de Git hay una situación que se produce bastante a menudo y que podemos solucionar de
una manera elegante con una opción determinada de la acción de commit. Básicamente se trata de modificar
el último commit, en lugar de crear uno nuevo.
Imagina que estás editando tu proyecto, realizas una serie de cambios y luego haces el correspondiente
commit para confirmarlos en el repositorio. Casi enseguida te das cuenta que cometiste un error. Entonces
puedes arreglar tu código para solucionarlo y lanzar otro commit para confirmarlo. Está todo bien, lo que
pasa es que la funcionalidad que has agregado es solo una, lo que pasa es que se generaron dos commits
cuando lo más elegante es que hubiéramos creado solo uno, con la funcionalidad bien realizada.
La manera de solucionar esta situación es muy sencilla y merece la pena que la veamos, porque no supone
ningún esfuerzo y nos permite gestionar nuestro repositorio un poco mejor. Como seguramente estemos
empezando con Git, leyendo el Manual de Git de DesarrolloWeb.com, vamos a hacer una práctica completa
que a la vez nos servirá de repaso de todo lo aprendido.
git init
Ahora creamos un archivo llamado "README". En el que podemos colocar ya un poco de texto. Lo
http://desarrolloweb.com/manuales/manual-de-git.html Página 32 de 54
Manual de Git
puedes hacer también con la consola con este comando (aunque también lo puedes hacer, claro está, con tu
editor preferido).
Luego añado los archivos al staging area, para que estén trackeados por Git.
git add .
Ahora te das cuenta que no colocaste algo en el README y lo editas de nuevo para colocar cualquier
nuevo contenido, como tu nombre como autor del proyecto y tu email. Abres el archivo con tu editor y lo
modificas. Podemos ver los cambios recién realizados con el comando status:
git status
git add .
http://desarrolloweb.com/manuales/manual-de-git.html Página 33 de 54
Manual de Git
Nota: Como el archivo ya se encuentra en el repositorio, Git lo está trackeando, podrías ahorrarte un
paso, agregando el archivo y haciendo la confirmación de una única vez, con git commit -am 'indicado
nombre del autor'.
Pero justamente es lo que queremos evitar. No necesito dos commits para esta operación, ya que he creado
simplemente el README y me olvidé una cosa simple que no merece la pena tener en un commit
separado.
Entonces, vamos a alterar el commit anterior, ya que es lo lógico, en vez de producir un commit nuevo.
Simplemente indicamos la opción --amend.
Nota: Aunque lo hicimos en el anterior paso, no te olvides de hacer el "git add .", porque si no en el
commit no habrá nada que enviar. En este caso no ponemos mensaje, ya que el mensaje ya lo habíamos
indicado en el anterior commit. No obstante, Git nos abrirá un editor para que nosotros podamos editar
el mensaje y cambiarlo por el que nos guste más. Puedes ahorrarte el (para algunos fastidioso) editor de
línea de comandos indicando el mensaje en el commit con "-m". Aunque estés haciendo un "amend" y
ya tengas mensaje lo puedes sobreescribirlo directamente sin tener en cuenta lo indicado anteriormente:
git commit --amend -m 'Creado el readme editado el commit primero'
El editor puede variar dependiendo del sistema en el que te encuentres. Pero básicamente en todos los casos
podrás editar el texto del mensaje del commit y luego activar la opción para salir de edición del texto.
Nota: A mi me lo abre con Vim, por lo que tengo que, desde el modo comando (pulsas ESC para
asegurarte que estás en modo comando), escribes :wq y pulsas enter.
Listo, con esto hemos editado el anterior commit en vez de crear uno nuevo.
Por último, si haces "git log" podrás ver que efectivamente solo hay un commit en el repositorio, ya que el
que hicimos para arreglar el problema en el README realmente solo modificó el commit anterior.
http://desarrolloweb.com/manuales/manual-de-git.html Página 34 de 54
Manual de Git
Listo, eso es todo. Ya sabes modificar el último commit sin necesidad de hacer un commit nuevo e
innecesario.
http://desarrolloweb.com/manuales/manual-de-git.html Página 35 de 54
Manual de Git
Ahora que ya sabemos cómo subir código a los repositorios y sincronizarnos, en los siguientes artículos
vamos a ver operativas menos frecuentes con Git, pero que son fundamentales también en la gestión
habitual de proyectos. No son acciones que vas a realizar todos los días al usar el sistema de control de
versiones, pero son importantes para administrar el código de los proyectos y colaborar entre componentes
de equipos de trabajo o proyectos Open Source.
Git tiene la posibilidad de marcar estados importantes en la vida de un repositorio, algo que se suele usar
habitualmente para el manejo de las releases de un proyecto. A través del comando "git tag" lo podemos
hacer, en una operación que se conoce comúnmente con el nombre de "tagging". Es una operativa que
tiene muchas variantes y utilidades, nosotros veremos las más habituales que estamos seguros te agradará
conocer.
Este sistema del versionado es importante, porque algunos gestores de paquetes te obligan a usarlo para
poder publicar packages en ellos. Así pues, vamos a relatar las bases para trabajar con el sistema de tagging
de modo que puedas usarlo en tu día a día en el trabajo con Git.
Las versiones de los proyectos las define el desarrollador, pero no se deberían crear de manera arbitraria,
sino que se recomienda darles un valor semántico. Esto no tiene nada que ver con Git, pero lo indicamos
aquí porque es algo que consideramos interesante que sepas cuando empiezas a gestionar tus versiones en
proyectos.
Generalmente los cambios se pueden dividir en tres niveles de "importancia": Mayor, menor y pequeño
ajuste. Si tu versión de proyecto estaba en la 0.0.1 y haces un cambio que no altera la funcionalidad ni la
interfaz de trabajo entonces lo adecuado es versionar tu aplicación como 0.0.2.
Realmente importa poco ahora el tema de la semántica, porque queremos hablar de Git. Sin embargo lo
encuentras muy bien explicado en este documento Versionamiento Semántico 2.0.0-rc.2, por lo que, si te
interesa el tema, te recomendamos leerlo.
http://desarrolloweb.com/manuales/manual-de-git.html Página 36 de 54
Manual de Git
Crear un tag
Se supone que cuando comienzas con un repositorio no tienes ninguna numeración de versión y ningún tag,
por lo que empezaremos viendo cómo se crean.
Supongamos que empezamos por el número de versión 0.0.1. Entonces lanzarás el comando:
Como ves, es una manera de etiquetar estados del repositorio, en este caso para definir números de versión.
Los acompañas con un mensaje, igual que se envían mensajes en el commit.
Nota: Este es el mecanismo que se conoce como "Etiquetas ligeras", existen otros tipos de etiquetado
que es posible hacer mediante Git.
Después de haber creado tu primer tag, podrás lanzar el comando "git tag", sin más parámetros, que te
informará sobre las versiones que has etiquetado hasta el momento.
git tag
Si tienes un repositorio donde has etiquetado ya tres números de versiones, podría arrojar una salida como
la que ves en la siguiente imagen.
http://desarrolloweb.com/manuales/manual-de-git.html Página 37 de 54
Manual de Git
Otro comando interesante en el tema de versionado es "show" que te permite ver cómo estaba el
repositorio en cada estado que has etiquetado anteriormente, es decir, en cada versión.
tag v0.0.2
"
commit 8ef366190b73d56e267c5324aa8074db3c3f0ed9
...
Si quieres que tus tags creados en local se puedan enviar al repositorio en GitHub, puedes lanzar el push
con la opción --tag. Esto es una obligatoriedad, porque si no lo colocas, el comando push no va a enviar los
nuevos tags creados.
En concreto la opción --tag envía todas las nuevas tag creadas, aunque podrías también enviar una en
concreto mediante su especificación.
Además, en el caso de GitHub también puedes crear tags en los repositorios directamente desde la interfaz
web del servicio. Desde la página principal del repositorio, en el enlace que pone "releases", puedes acceder
a la información sobre las versiones etiquetadas en tu proyecto, así como etiquetar nuevas versiones.
http://desarrolloweb.com/manuales/manual-de-git.html Página 38 de 54
Manual de Git
Conclusión
Hemos aprendido a etiquetar estados de un proyecto con Git, algo que se realiza comúnmente para
informar en el sistema de control de versiones de las releases principales durante la vida de un software.
Estamos seguros que con esta información tendrás suficiente para comenzar, pero si te queda alguna duda
puedes consultar este artículo de la documentación de Git.
En el día a día del trabajo con Git una de las cosas útiles que podemos hacer es trabajar con ramas. Las
ramas son caminos que puede tomar el desarrollo de un software, algo que ocurre naturalmente para
resolver problemas o crear nuevas funcionalidades. En la práctica permiten que nuestro proyecto pueda
tener diversos estados y que los desarrolladores sean capaces de pasar de uno a otro de una manera ágil.
Ramas podrás usar en muchas situaciones. Por ejemplo imagina que estás trabajando en un proyecto y
quieres implementar una nueva funcionalidad en la que sabes que quizás tengas que invertir varios días.
Posiblemente sea algo experimental, que no sabes si llegarás a incorporar, o bien es algo que tienes claro que
vas a querer completar, pero que, dado que te va a ocupar un tiempo indeterminado, es posible que en
medio de tu trabajo tengas que tocar tu código, en el estado en el que lo tienes en producción.
Bajo el supuesto anterior lo que haces es crear una rama. Trabajas dentro de esa rama por un tiempo, pero
de repente se te cuelga el servidor y te das cuenta que hay cosas en el proyecto que no están funcionando
correctamente. Los cambios de la rama no están completos, así que no los puedes subir. En ese instante, lo
que las ramas Git te permiten es que, lanzando un sencillo comando, poner de nuevo el proyecto en el
estado original que tenías, antes de empezar a hacer esos cambios que no has terminado. Perfecto!
http://desarrolloweb.com/manuales/manual-de-git.html Página 39 de 54
Manual de Git
solucionas la incidencia, sobre el proyecto original y luego puedes volver a la rama experimental para seguir
trabajando en esa idea nueva.
Llegará un momento en el que, quizás, aquellos cambios experimentales los quieras subir a producción.
Entonces harás un proceso de fusionado entre la rama experimental y la rama original, operación que se
conoce como merge en Git.
Las aplicaciones de las ramas son, como puedes imaginar, bastante grandes. Espero haber podido explicar
bien una de ellas y que te hayas podido hacer una idea antes de seguir la lectura de este artículo.
Nota: Ten en cuenta que este artículo es un tanto avanzado, pensado para personas que ya trabajan con
Git. Puedes aprender cosas más básicas que damos por sabidas aquí en el Manual de Git.
La rama master
Cuando inicializamos un proyecto con Git automáticamente nos encontramos en una rama a la que se
denomina "master".
Puedes ver las rama en la que te encuentras en cada instante con el comando:
git branch
Esta rama es la principal de tu proyecto y a partir de la que podrás crear nuevas ramas cuando lo necesites.
Si has hecho algún commit en tu repositorio observarás que después de lanzar el comando "git branch" nos
informa el nombre de la rama como "master".
Nota: Si no has hecho un commit en tu proyecto observarás que no se ha creado todavía ninguna rama
y que el comando branch no produce ninguna salida.
El procedimiento para crear una nueva rama es bien simple. Usando el comando branch, seguido del
nombre de la rama que queremos crear.
http://desarrolloweb.com/manuales/manual-de-git.html Página 40 de 54
Manual de Git
Este comando en sí no produce ninguna salida, pero podrías ver las "branches" de un proyecto con el
comando:
git show-branch
Esto nos muestra todas las ramas del proyecto con sus commits realizados. La salida sería como la de la
siguiente imagen.
Para moverse entre ramas usamos el comando "git checkout" seguido del nombre de la rama que queremos
que sea la activa.
esta sencilla operación tiene mucha potencia, porque nos cambiará automáticamente todos los archivos de
nuestro proyecto, los de todas las carpetas, para que tengan el contenido en el que se encuentren en la
correspondiente rama.
De momento en nuestro ejemplo las dos ramas tenían exactamente el mismo contenido, pero ahora
podríamos empezar a hacer cambios en el proyecto experimental y sus correspondientes commit y entonces
los archivos tendrán códigos diferentes, de modo que puedas ver que al pasar de una rama a otra hay
cambios en los archivos.
Si estando en la rama experimental haces un par de commit, observarás que al hacer el show-branches te
mostrará nuevos datos:
El comando checkout tiene la posibilidad de permitirte crear una rama nueva y moverte a ella en un único
paso. Para crear una nueva rama y situarte sobre ella tendrás que darle un nombre y usar el parámetro -b.
http://desarrolloweb.com/manuales/manual-de-git.html Página 41 de 54
Manual de Git
Como salida obtendrás el mensaje Switched to a new branch 'otrarama'. Eso quiere decir que, además de
crear la rama, nuestra cabecera está apuntando hacia esta nueva rama.
Si te dedicas a editar tus ficheros, crear nuevos archivos y demás en las distintas ramas entonces podrás
observar que al moverte de una a otra con checkout el proyecto cambia automáticamente en tu editor,
mostrando el estado actual en cada una de las ramas donde te estás situando. Es algo divertido y, si eres
nuevo en Git verás que es una magia que resulta bastante sorprendente.
Como estás entendiendo, el proyecto puede tener varios estados en un momento dado y tú podrás moverte
de uno a otro con total libertad y sin tener que cambiar de carpeta ni nada parecido. Si usas un programa de
interfaz gráfica de Git, como SourceTree o cualquier otro, podrás ver las ramas en un esquema gráfico más
entendible que en la consola de comandos.
Fusionar ramas
A medida que crees ramas y cambies el estado del las carpetas o archivos tu proyecto empezará a divergir de
una rama a otra. Llegará el momento en el que te interese fusionar ramas para poder incorporar el trabajo
realizado a la rama master.
El proceso de fusionado se conoce como "merge" y puede llegar a ser muy simple o más complejo si se
encuentran cambios que Git no pueda procesar de manera automática. Git para procesar los merge usa un
antecesor común y comprueba los cambios que se han introducido al proyecto desde entonces, combinando
el código de ambas ramas.
Para hacer un merge nos situamos en una rama, en este caso la "master", y decimos con qué otra rama se
debe fusionar el código.
El siguiente comando, lanzado desde la rama "master", permite fusionarla con la rama "experimental".
Un merge necesita un mensaje, igual que ocurre con los commit, por lo que al realizar ese comando se
abrirá "Vim" en la consola para que introduzcas los comentarios que juzgues oportuno. Salir de Vim lo
consigues tecleando ":q" y pulsando enter para aceptar ese comando. Esta operativa de indicar el mensaje se
puede resumir con el comando:
http://desarrolloweb.com/manuales/manual-de-git.html Página 42 de 54
Manual de Git
En la siguiente imagen puedes ver una secuencia de comandos y su salida. Primero el cambio a la rama
master "git checkout master", luego el "git branch" para confirmar en qué rama nos encontramos y por
último el merge para fusionarla con la rama experimental.
Luego podremos comprobar que nuestra rama master tiene todo el código nuevo de la rama experimental y
podremos hacer nuevos commits en master para seguir el desarrollo de nuestro proyecto ya con la rama
principal, si es nuestro deseo.
Si tenemos un programa de Git por interfaz gráfica podremos ver el diagrama con el combinado de las
ramas.
Si subimos el proyecto a Github podremos ver también un diagrama de las ramas que hemos ido creando y
fusionando a master, en la sección Graps / Network.
http://desarrolloweb.com/manuales/manual-de-git.html Página 43 de 54
Manual de Git
Espero que estas notas te hayan ayudado a entender las ramas de Git y puedas experimentar por tu cuenta
para hacer algunos ejemplos e ir cogiendo soltura.
Para acabar te dejamos un enlace muy interesante y más detallado donde aprender más del proceso de
fusionado de ramas.
En el Manual de Git encontrarás también muchas otras informaciones y tutoriales para extraer lo mejor de
esta imprescindible herramienta.
En este artículo te vamos a explicar el mecanismo para contribuir en un proyecto Open Source que está
publicado en GitHub, enviando código para la inclusión en el repositorio mediante el mecanismo conocido
como Pull Request.
Es un proceso bastante sencillo, pero incluye varios pasos, comandos de consola, etc. Los describiremos, así
como algunos de los conceptos que debes conocer para poder entender los procedimientos de Git para la
gestión del código.
Al final del artículo además encontrarás un vídeo donde se demuestra todo este proceso, en vivo, paso por
paso.
http://desarrolloweb.com/manuales/manual-de-git.html Página 44 de 54
Manual de Git
Nota: Pull Request es la acción básica con la que podrás aportar código para un proyecto. Recuerda además
que GitHub es un escaparate excelente para un programador, pues es el mejor sitio donde se puede
demostrar los conocimientos, compartiendo código de calidad y contribuyendo activamente a proyectos
Open Source. Si quieres aprender a usar Git desde un punto de vista muy práctico infórmate de nuestro
curso de Git que comienza esta semana.
Fork de un proyecto
Como sabes, en Git se trabaja siempre en local, con la copia del repositorio en nuestro ordenador. Fíjate
que el repositorio que tienes en local no debe ser un clon de aquel con el que deseas contribuir, sino un fork
propio.
Puedes hacer un Fork desde la propia página de GitHub, entrando en un repositorio y pulsando el botón
"Fork", arriba a la derecha. Inmediatamente se creará en tu cuenta de GitHub un nuevo repositorio, el fork,
que es la copia de estado actual del repositorio original. Podrás ver la información del repositorio,
identificando que es un fork, en un área arriba de la página.
En tu fork se supone que habrás realizado diversos cambios en el código, en uno o más ficheros. Tendrás
entonces que hacer el commit para enviarlos a tu copia del repositorio en local.
Nota: Ya debes conocer la operación commit, si no, mira en el artículo Primer commit del Manual de Git.
Luego tendrás que enviar esos cambios a tu propio repositorio, el fork, publicado en GitHub. Eso lo
consigues con el comando git push, indicando el repo al que quieres enviar los cambios y la rama donde
enviarlos.
Con ese comando estás diciendo a Git: "haz un push a origin, que es el origen del repositorio en el servidor
remoto (GitHub), especificando la rama master".
Esto conectará por Git para subir aquellos cambios que acabas de realizar y podrás verlos en GitHub en tu
http://desarrolloweb.com/manuales/manual-de-git.html Página 45 de 54
Manual de Git
propio Fork.
El siguiente paso, una vez subido el commit, es realizar el Pull Request. En tu fork observarás un icono en
verde que sirve para comparar y revisar para crear un Pull Request.
Hacemos clic sobre ese botón y accedemos a una página donde está realizando la comparación contra el
repositorio original. Te aparecerá un detalle de todos los archivos que se han cambiado con los cambios
coloreados para que los puedas entender mejor, junto con un informe del número de commit realizados y
los colaboradores que los han enviado.
Luego puedes hacer clic sobre el icono "Create pull request" para lanzar la solicitud de fusión de nuestro
fork con el repositorio original.
http://desarrolloweb.com/manuales/manual-de-git.html Página 46 de 54
Manual de Git
Aparecemos entonces en una página donde encontramos un formulario que nos permite indicar un mensaje
sobre los motivos por los que quieres hacer el pull request y que comentes el detalle de los cambios que has
realizado, qué funcionalidad has agregado, que bug se ha solucionado, etc.
Nota: si en el proyecto donde estás haciendo un pull request tienen el CONTRIBUTING.md te saldrá un
enlace para conocer las políticas necesarias a seguir para poder hacer aportaciones al código. "Guidelines for
contributing". Puedes ver ese enlace en la imagen anterior.
Una vez enviado el formulario con las notas del pull request, que deben servir a los dueños del repositorio
original para entender tu código y valorar la posibilidad de aceptar la contribución. Al enviar el formulario
nos redirije a la página del pull request, dentro del repositorio original, donde encontrarás que tu usuario de
GitHub ha solicitado un merge al proyecto, junto con una serie de informaciones relacionadas, el
repositorio original, el fork que ha pedido el pull request, etc. En esa página no puedes hacer nada más,
salvo realizar alguna comunicación con los administradores del repositorio original, simplemente enviando
algún mensaje.
http://desarrolloweb.com/manuales/manual-de-git.html Página 47 de 54
Manual de Git
De manera automática, a los administradores les llegará un correo y una notificación a través del sitio de
GitHub para que revisen el pull request y acepten o no los cambios al código. Si además entras en la home
del repositorio verás que en la parte de la derecha aparece el número de pull request, donde debería haber al
menos uno, el que acabas de hacer.
En el caso que los administradores acepten el pull request que acabas de realizar, recibirás las
correspondientes notificaciones. Si ha sido aceptado el Pull Request se fusionará el código de tu propio fork
con el proyecto al que estés contribuyendo.
En la parte de la derecha observarás que el pull request ya no está, pero si pulsas sobre el enlace "Pull
request" encontrarás un histórico de las operaciones realizadas.
http://desarrolloweb.com/manuales/manual-de-git.html Página 48 de 54
Manual de Git
Si vas a los pull request cerrados (closed) encontrarás un listado de la actividad. Deberías localizar el tuyo y
un enlace que nos lleva a una página con algunas informaciones útiles del pull request cerrado.
El estado de tu Pull Request observarás que está en "Merged" y que el proceso está completado. Desde allí
podrás comunicar nuevamente con los gestores del repo original, enviando si lo deseas mensajes.
Con esta serie de pasos hemos aprendido a realizar una operación de Pull Request, aportando código en un
repositorio Open Source. Esperamos que puedas poner en práctica esta actividad que sin duda resultará
enriquecedora tanto para el software libre como para tu propio perfil de GitHub y tu formación profesional.
En el vídeo que puedes ver a continuación encontrarás todo este proceso paso por paso, relatado en mayor
detalle. Recuerda además que esta es una de las muchas cosas que vas a aprender y practicar en el próximo
Curso de Git Práctico para desarrolladores y diseñadores.
Para ver este vídeo es necesario visitar el artículo original en: http://desarrolloweb.com/articulos/pull-
request-git.html
http://desarrolloweb.com/manuales/manual-de-git.html Página 49 de 54
Manual de Git
Existen en el mercado numerosas herramientas basadas en Git que merece la pena conocer, ya que nos
ayudan a desarrollar muchas de las tareas habituales en el desarrollo de software. Muchos de estos
programas o servicios alientan el uso de buenas prácticas y proponen flujos de trabajo deseables para el
desarrollo de software moderno.
Introducción a GitLab
Qué es GitLab, qué le diferencia de sus competidores como GitHub o Bitbucket y qué
herramientas engloba, además de los repositorios remotos Git, para gestionar los proyectos de
desarrollo.
GitLab nació como un sistema de alojamiento de repositorios Git, es decir, un hosting para proyectos
gestionados por el sistema de versiones Git. Sin embargo, alrededor de esta herramienta han surgido
muchas otras herramientas muy interesantes para programadores y equipos de desarrollo, que envuelven
todo el flujo del desarrollo y el despliegue de aplicaciones, test, etc.
Sin duda, para dar una idea de lo que es GitLab, lo más rápido sería compararlo con uno de sus
competidores, GitHub, pues éste último es especialmente conocido en el mundo del desarrollo de software.
Todos más o menos estamos familiarizados con lo que ofrece, la gestión de repositorios, las issues, los pull
request, GitHub Pages, etc. GitLab sería algo muy similar a lo que encontramos en GitHub, aunque a veces
con otros nombres. Otras alternativas de programas o servicios para Git como Bitbucket están muy por
detrás en posibilidades.
La principal diferencia entre GitLab y sus competidores es que GitLab se ofrece como un software libre que
puedes descargar e instalar en cualquier servidor. Esta posibilidad permite usar GitLab para una empresa,
http://desarrolloweb.com/manuales/manual-de-git.html Página 50 de 54
Manual de Git
Nota: Obviamente, si instalas tu propio GitLab para usarlo en tu propia empresa, te obliga a mantener
el servidor, configurarlo, actualizar el software, etc. Trabajo que no deja de representar un gasto de
tiempo, lo que al final se traduce en dinero. Es el motivo por lo que muchas empresas prefieren acabar
pagando para disfrutar de GitLab como servicio.
La otra alternativa es usar GitLab directamente de GitLab.com, pagando por el servicio. Esto permite
disponer de todo el poder de GitLab y sus herramientas colindantes, sin invertir tiempo en configuración,
aprovechando sus ventajas desde el primer minuto. Además, las versiones del servicio "en la nube" tienen
muchas herramientas adicionales, funcionalidades que superan con diferencia a la versión que se ofrece para
instalar como software libre.
Por último, GitLab también se ofrece sin coste para publicar repositorios de software libre, igual que su
competidor GitHub. En este caso, aunque GitLab pueda disponer de algunos servicios extra que justifiquen
trabajar con la herramienta, lo cierto es que GitHub sigue siendo el sitio preferido donde ubicar un
proyecto, dado que diversos sistemas de gestión de dependencias, como npm, Composer, etc., trabajan
directamente contra ellos.
Nota: Para quien desee aprovechar las ventajas de GitLab en un proyecto publicado en GitHub existe la
posibilidad de hacer un espejo del repositorio. GitLab, cada vez que el repo se actualiza en GitHub es
capaz de traerse los cambios. Los desarrolladores desde GitLab, con el repositorio siempre actualizado,
pueden realizar uso de los servicios extra, como los procesos de integración continua o despliege
continuo.
En resumen, si queremos usar GitLab gratis, para alojar en remoto un repositorio Git en general, la mejor
alternativa es que lo instalemos gratuitamente en una de nuestras máquinas. Sin embargo, si queremos
ahorrarnos tiempo y no nos importa pagar un poco, la versión en la nube está mucho más completa y nos
permite olvidarnos del servicio y concentrarnos en el desarrollo de nuestros programas.
GitLab es una herramienta basada en Git, que usas de la misma manera que cualquier otra herramienta
similar. Generalmente usas Git a través de la línea de comandos, o a través de programas de interfaz gráfica,
o del propio editor de código. Toda esa operativa que ya conoces y que hemos explicado en el Manual de
Git, no cambia.
Además del hosting remoto para repositorios GitLab ofrece una interfaz web para controlar el repositorio y
muchas otras herramientas. Ofrece la posibilidad de examinar el código en cualquiera de sus versiones,
realizar acciones relacionadas con el sistema de repositorios como mergear el código de versiones de
proyecto o gestionar las "pull request" (que en GitLab se llaman "merge request"), gestionar problemática
de tu software diversa, automatizar procesos como el despliegue o la ejecución de pruebas del software, etc.
Toda esta operativa la realizas, o configuras, en GitLab por medio de una web.
http://desarrolloweb.com/manuales/manual-de-git.html Página 51 de 54
Manual de Git
Por tanto, para usar GitLab simplemente necesitas las mismas herramientas que ya utilizas en tu día a día, el
terminal o un programa de interfaz gráfica para gestionar tu repositorio, así como el navegador web para
acceder a el ecosistema de herramientas disponible en el sitio de GitLab. Por supuesto, todas estas
herramientas las puedes usar desde cualquier ordenador conectado a Internet, independientemente de su
sistema operativo.
Nota: ya, si nos referimos a cómo usar nuestra propia instalación de GitLab, y qué necesitamos para
instalar el software libre en nuestros propios servidores, la respuesta es que lo más normal es que
instales GitLab en un servidor Linux, ya que es su entorno natural. Generalmente instalar GitLab es tan
sencillo como instalar cualquier otro software en Linux, solo que necesitarás configurar además una serie
de programas adicionales, que usa GitLab por debajo, para que el servicio funcione de manera fina. Esta
parte puede que no sea tan fácil para una persona que no tenga conocimientos sólidos de administración
de sistemas.
Funcionalidades de GitLab
En GitLab podemos gestionar principalmente proyectos, Grupos y Sinppets. Los proyectos son los
protagonistas del sistema, básicamente repositorios de software gestionados por GitLab y todo el
ecosistema GitLab. Los grupos son básicamente empresas y usuarios. Los snippets por su parte son como
pedazos de código que puedes dejar para hacer cualquier cosa.
Como decimos, dentro de los proyectos es donde se aglutinan la mayoría de las funcionalidades que vamos
a resumir:
Overview:
Es un listado de todo el proyecto, los archivos, los README.md. Es parecido a lo que vemos cuando
accedemos a un proyecto con GitHub. Te da el resumen del repositorio, archivos, commits, etc.
Luego tiene dos subsecciones: En Activity del proyecto te ofrece toda la actividad, de una manera
estadística. En Cycle Analytics además te ofrece algo muy novedoso, no disponible en otras herramientas.
Básicamente informa el tiempo que se tarda en realizar una funcionalidad, desde que tienes la idea hasta que
se incorpora al software, de modo que cualquier persona, incluso sin conocimientos de programación,
puede saber el tiempo que ocupó el hacer las tareas. Una información muy valiosa que puede ayudar a
futuro a estimar mejor el tiempo de trabajo necesario para nuevas funcionalidades. Obviamente, cuantas
más issues tengas en el sistema, más datos tendrás para saber el tiempo que necesitas para las próximas
tareas.
Repository:
Dentro de la sección "Repository" tenemos varias opciones diversas que afectan al repositorio del proyecto.
Tenemos "Files", donde se puede navegar por los directorios y archivos, cuyo código podemos ver, e
incluso editar los ficheros. Está disponible una visualización por ramas y dispone de utilidades diversas para
poder hacer cosas relacionadas con el repositorio remoto, ahorrando la necesidad de lanzar comandos.
Tiene un buscador de archivos muy potente.
http://desarrolloweb.com/manuales/manual-de-git.html Página 52 de 54
Manual de Git
En "Commits" encontramos un listado de todos los commits realizados contra el repositorio, junto con
datos específicos de cada uno de ellos.
Las ramas "Branches" sirven para ver las ramas que tenemos en el repositorio.
La siguiente sección, "Tags", es importante también, pues es el mecanismo disponible en Git para definir
puntos del estado del código, correspondientes a cada release.
Además esta sección tiene otras áreas también importantes, que os dejamos para vuestra propia
investigación. Especialmente sería destacable la parte de "Locked files", disponible solo en GitLab como
servicio, que es algo que no ofrece el propio sistema de control de versiones Git pero que han
implementado dentro de GitLab, que permite bloquear un fichero para que solo ciertas personas lo puedan
editar.
Issues:
Este es otra de las grandes utilidades de GitLab, que permite definir cualquier problema que se detecta en el
software y darle seguimiento. Seguro que las conocemos porque es una de las partes fundamentales de
GitHub y habremos navegado por ellas en decenas de ocasiones.
Básicamente nos permite ver las issues generadas en un proyecto, mantener discusiones sobre ellas, y
controlar los flujos de trabajo para su resolución, permitiendo definir las personas que deben resolverla, el
tiempo estimado y el usado, la fecha límite, el peso de las tareas, etc.
En GitLab han publicado otra interesante innovación que es un tablero de issues (Issue Boards), que
permite visualizar las tareas, de una manera similar a los boards de Trello. Como gestores somos capaces de
definir los tableros y las etiquetas. GitLab, por medio de la gestión de las Issues, es capaz actualizar el estado
de las tareas, permitiendo visualizar su evolución por medio de los tableros.
Otra cosa muy interesante es el "Service desk", que te ofrece un email que lo puedes proporcionar al cliente.
Sin que el cliente se registre en GitLab, ni tenga acceso al proyecto, puede enviar mensajes a ese email,
adjuntando texto, imágenes y archivos. GitLab, al recibir el correo, da de alta automáticamente una issue
con ese contenido.
Merge Request:
Son como las Pull Request de GitHub. Te permiten controlar todas las solicitudes de combinación o unión
de código de distintas ramas o forks. Es muy importante que los merges se resuelvan mediante la interfaz
gráfica, ya que nos ofrece muchas posibilidades interesantes, como automatización de tests, la posibilidad de
revisión de los cambios por parte de componentes del equipo, implementar diversas políticas de control
sobre el código del proyecto, etc.
CI/CD:
Es una de las maravillas que dispone GitLab, una herramienta sencilla y muy útil para los procesos de
integración continua y despliegue continuo. Existen muchas herramientas que se pueden integrar para
automatizar los procesos y llegar a crear flujos de trabajo completamente automatizados. De modo que se
http://desarrolloweb.com/manuales/manual-de-git.html Página 53 de 54
Manual de Git
lancen los test y si todo va bien se puedan realizar una serie de tareas definida, que pueden llegar a producir
el despliegue automático de las aplicaciones.
Solo disponer de esta sección es suficiente motivo para pasarse a GitLab. No llega la complejidad de
herramientas específicas como Jenkins, pero resuelve de manera muy potente problemas similares.
Gitlab no se queda aquí, existen decenas de herramientas para hacer un montón de procesos, plugins,
integraciones con diversos servicios útiles en el día a día de los equipos de desarrollo, etc.
Tenemos un vídeo en el que explicamos con mucho más detalle todas las posibilidades de GitLab y lo
comparamos con otros sistemas similares. Además estamos impartiendo el Curso de GitLab en EscuelaIT,
en el que podrás aprender lo básico para comenzar con Git, pero sobre todo la manera de sacar todo el
partido de las herramientas disponibles en GitLab.
Puedes dar una vuelta por GitLab y examinar las opciones y posibilidades. Al ritmo que van, seguro que
cuando entres habrán sacado novedades representativas. Pero si quieres que te guiemos en esa visita, puedes
consultar el siguiente vídeo. También encontrarás en este vídeo un resumen de lo que se denomina el
"GitLab Flow", un conjunto de prácticas que son aconsejables para mantener un flujo adecuado en todo lo
que sería el desarrollo de software, que nos asegure la calidad y facilidad de mantenimiento y trabajo en
equipo.
http://desarrolloweb.com/manuales/manual-de-git.html Página 54 de 54