The Git, the Bad and the Ugly

Una guía para empezar a colaborar en proyectos usando Git.

Recopilacion
GLUO   Ismael Aguilar Octubre 2020
Tabla de contenido
¿Por qué quiero usar un gestor de versiones?..................................................................2
GitHub............................................................................................................................3
Contenidos...........................................................................................................................................................3
¿Qué es GitHub?...................................................................................................................................................4
Elementos principales en GitHub.........................................................................................................................4
Code.................................................................................................................................................................4
Issues...............................................................................................................................................................5
Fork..................................................................................................................................................................6
Pull Requests....................................................................................................................................................7
Projects............................................................................................................................................................8
Wiki..................................................................................................................................................................9
Graphs............................................................................................................................................................10
GitHub Pages.................................................................................................................................................10
Crear una cuenta de GitHub...............................................................................................................................11
Crear un repositorio en GitHub..........................................................................................................................14
Tutoriales de GitHub..........................................................................................................................................16

Usando Git....................................................................................................................17
Contenidos.........................................................................................................................................................17
Instalar Git..........................................................................................................................................................17
Creando un repo (local)......................................................................................................................................17
Crear un repositorio: git init..........................................................................................................................17
Añadir archivos al repositorio: git add / git commit......................................................................................19
Crear un repositorio remoto...............................................................................................................................22
Crear un repositorio en GitHub.....................................................................................................................22
Añadir la dirección del repositorio remoto a nuestro repositorio local (git remote add)............................22
Crear un repositorio local a partir del repositorio remoto (git clone)..........................................................24
Crear un repositorio remoto...............................................................................................................................25
Crear un repositorio en GitHub.....................................................................................................................25
Añadir la dirección del repositorio remoto a nuestro repositorio local (git remote add)............................25
Crear un repositorio local a partir del repositorio remoto (git clone)..........................................................26
Subir y bajar cambios a un repositorio remoto..................................................................................................28
Subir cambios al repositorio remoto: git push..............................................................................................28
 Bajar cambios del repositorio remoto: git pull..............................................................................................29
Bajar cambios y fusionarlos manualmente: git fetch y git merge.................................................................31
Trabajando con ramas.......................................................................................................................................32
¿Por qué usar ramas?....................................................................................................................................32
Creando ramas: git branch............................................................................................................................33
Cambiando de rama: git checkout.................................................................................................................33
Subiendo ramas al repositorio remoto.........................................................................................................35
Fusionando ramas: git merge........................................................................................................................40
Borrando ramas.............................................................................................................................................41
Usando etiquetas...............................................................................................................................................42
¿Por qué usar etiquetas?...............................................................................................................................43
Creando una etiqueta ligera (lightweight)....................................................................................................43
Creando una etiqueta anotada (annotated).................................................................................................43
Etiquetando un commit pasado....................................................................................................................43
Borrando etiquetas........................................................................................................................................43
Subiendo etiquetas al repositorio remoto....................................................................................................44

¿Y si uso Windows?.......................................................................................................44
GitHub Desktop..................................................................................................................................................44
Configurando GitHub Desktop...........................................................................................................................45
Clonar repositorios de GitHub............................................................................................................................47
Añadir archivos al repositorio (git add & git commit).......................................................................................48
Eliminar archivos del repositorio (git rm & git commit)....................................................................................49
Subir y bajar cambios desde el repositorio remoto (git push & git pull)............................................................50
Explora y experimenta.......................................................................................................................................51

Colaborando con proyectos en GitHub..........................................................................52

Forkeando un repositorio...................................................................................................................................52
Creando un fork desde GitHub......................................................................................................................52
Clonando el repositorio en nuestro PC.........................................................................................................53
(opcional) Añadiendo el repositorio original a los repositorios remotos.....................................................53
Forkeando un repositorio...................................................................................................................................54
Añadiendo cambios al repositorio.................................................................................................................54
Abriendo un pull request...............................................................................................................................57
Aceptando un pull request............................................................................................................................59
Creando Pull Request.........................................................................................................................................62
Añadiendo cambios al repositorio.................................................................................................................62
 Abriendo un pull request...............................................................................................................................64
Aceptando un pull request............................................................................................................................66

Buenas prácticas al trabajar con Git..............................................................................69

Sigue el GitFlow Workflow.................................................................................................................................69
Mensajes de commit..........................................................................................................................................69
Escribe mensajes de commit claros y concisos.............................................................................................70
Usa el mensaje de commit para aportar contexto y explicar el por qué detras de un cambio....................70

Recursos para aprender más.........................................................................................71

Bibliografía...................................................................................................................72

¿Por qué quiero usar un gestor de

versiones?
Git es un software de control de versiones (VCS) creado originalmente por  Linus
Tovalds para el desarrollo del kernel de Linux .

En lugar de tener en nuestros ordenadores varios archivos distintos por cada versión, lo
cual puede llevar a confusión y errores, Git se encarga de gestionar las distintas
versiones, almacenándolas y pudiendo revertir los archivos a cualquier versión anterior
de los mismos. Así evitamos tener varios archivos
llamados archivo.txt, archivo_v2.txt , archivo_definitivo.txt, archivo_definitivo
_v2.txt y no saber qué cambios hicimos en cada uno de ellos.
Como Git mantiene información de los cambios efectuados en cada versión, también es
más fácil saber qué versión fue la última que funcionaba o en cuál se introdujo cierto
bug. Esto supone una ventaja no sólo para nosotros como desarrolladores, sino también
para los usuarios, que pueden bajarse una versión estable del software mientras nosotros
seguimos añadiendo mejoras.

Si combinamos Git con un repositorio online, como los proporcionados

por github o bitbucket , podremos además trabajar de forma colaborativa con un equipo
de desarrolladores. En este caso, Git se encargará de coordinar los distintos cambios para
que varios desarrolladores puedan trabajar a la vez sobre un código.

Este manual te enseñará como usar los comandos básicos de Git de forma que puedas
beneficiarte de todas estas ventajas en tus proyectos.

GitHub
Esta sección se centra en explicar qué es GitHub, cómo funciona y cómo crearse una
cuenta para usarlo.
 Contenidos
 ¿Qué es GitHub?
 Elementos principales en GitHub
 Crear una cuenta de GitHub
 Crear un repositorio en GitHub
 Tutoriales de GitHub

¿Qué es GitHub?
GitHub es un lugar donde los desarrolladores suben sus proyectos y comprarten su
código. Cada proyecto se encuentra almacenado en un repositorio, que usa Git para el
control de las distintas versiones del proyecto.
GitHub nos permite tanto compartir nuestro proyecto con el resto del mundo, como
desarrollar un proyecto de forma colaborativa con otras personas. Para ello, además del
espacio de almacenamiento para nuestro proyecto, nos ofrece otras herramientas como
un gestor de bugs y la posibilidad de crear una wiki, un tablón de Kanban muy similar al
de Trello e incluso alojar nuestra propia página web estática para el proyecto de forma
gratuita.

Elementos principales en GitHub

GitHub tiene una serie de elementos muy útiles a la hora de trabajar con nuestro
proyecto, los cuales se describen a continuación.

Code
Code es la página principal de un repositorio en GitHub, la cual incluye la descripción
del proyecto, unas etiquetas para clasificar la temática del proyecto y una vista de
seguidores, estrellas, commits, branches, releases, etc del repositorio.
Esta página también presenta un explorador de archivos desde el que podemos ver los
archivos incluidos en el proyecto, y navegar por ellos. En la parte inferior de la página
podemos encontrar una visualización del archivo README.md, que suele contener
información útil sobre el repositorio.

Issues
GitHub tiene integrado un gestor de bugs en forma de Issues. Cada Issue representa un
problema o mejora del proyecto. Dentro de cada Issue se pueden poner comentarios en
los que informar de los progresos o debatir la mejor forma de solucionarla.
Para poner una nueva Issue, podemos hacer click en "New Issue", tras lo cual nos
aparece el siguiente formulario para rellenar. Desde él podemos añadir un título, una
descripción, asignar la Issue a una persona concreta (o varias) y etiquetar la Issue.

Fork
GitHub tiene un sistema de permisos que controla qué usuarios pueden subir código a
cada repositorio. Si deseamos hacer alguna modificación al software de una tercera
persona, pero no tenemos autorización para publicar en su repositorio, podemos hacer un
Fork de dicho repositorio. Un Fork no es más que una copia del repositorio, que pasa a
ser propiedad del usuario que hizo el Fork. De esta forma, ese usuario ya podría realizar
modificaciones sobre el código del repositorio en su copia, sin necesidad de tener
autorización para subir cambios.

Pull Requests
Si has hecho un Fork de un proyecto y has añadido modificaciones útiles para los
usuarios del repositorio original, puede ser interesante integrar esos cambios en ese
repositorio. Para ello, podemos hacer una petición al autor en forma de Pull Request,
mediante el botón "New Pull Request" de la pestaña "Code".

La primera pantalla que nos saldrá una vez pulsado el botón nos permitirá comparar
ramas del repositorio original con ramas de nuestro repositorio, para ver los cambios
realizados. Una vez comprobado, podemos usar el botón "Create Pull Request" para
proceder a crear una Pull Request.

En la siguiente pantalla nos aparecerá un formulario muy similar al de una nueva Issue,
en el que podremos explicar qué cambios hemos hecho y por qué. El mantenedor del
repositorio original podrá entonces revisar nuestros cambios y, si así lo decide,
integrarlos en el repositorio principal.
En proyectos grandes el uso de Forks y Pull Requests entre miembros del mismo equipo
ayuda a mejorar la coordinación y a reducir errores.

Projects
Un Project de GitHub es una forma de organizar tareas e Issues relacionadas entre sí.
Está inspirada en el método Kanban y tiene un aspecto muy similar al de los tablones
de Trello. A cada Project le podremos añadir tarjetas que pueden corresponder o no con
Issues del proyecto y moverlas entre las distintas columnas del tablón.

Wiki
GitHub nos permite también tener documentación asociada a un proyecto en una wiki
alojada en GitHub. Esta wiki se puede editar online, y está basada en Gollum.La wiki se
almacena en un repositorio independiente que podemos clonar y editar también
localmente. 

Graphs
La pestaña Graph nos permite ver distintas visualizaciones de datos relacionadas con
nuestro repositorio, como cuántas líneas de código/commits ha aportado cada
contribuidor o cuál es la franja horaria en la que se suelen hacer más commits. Uno de
los gráficos más útiles es el de Network, que muestra de forma gráfica los commits y
branches de nuestro proyecto, así como su estado.
 GitHub Pages
GitHub permite alojar una página web estática asociada a un repositorio, que puede
actuar como documentación o como web del proyecto. También nos permite tener una
web estática asociada a nuestro usuario, que podemos usar como web personal.

Una forma muy sencilla de generar esta página web es usar Jekyll para generar una web
estática a partir de archivos markdown.

La guía de configuración de las GitHub Pages se puede consultar aquí.

Crear una cuenta de GitHub

Crear una cuenta de GitHub es muy sencillo.

1. El primer paso es ir a la web de GitHub, en la que encontrarás la opción "Sign

up". Es probable que incluso te encuentres un formulario en el que meter los datos
directamente en la
 portada: 

2. Esa opción nos llevará a un formulario en el que introducir nuestros datos similar
a
 este: 

3. Por último, nos pedirá (de forma opcional) que aportemos algo de información
sobre nuestra experiencia previa e
 intereses. 

4. Una vez completado el proceso, GitHub nos ofrecerá leer la guía o comenzar un
proyecto: 
 Crear un repositorio en GitHub
Desde nuestra página principal, simplemente hacemos click en "Create new repository":

Si pertecemos a una asociación de GitHub, también disponemos de esta opción en la

página principal:

Para crear el respositorio, simplemente le damos un nombre y una descripción. En

nuestro caso lo hemos llamado test-respository. Podemos, también, añadir un archivo
de licencia y un README con nuestra descripción, de forma opcional:
Al aceptar, se creará nuestro repositorio vacío (o con un README / archivo de licencia
si hemos seleccionado esta opción). Una vez creado, disponemos de varias opciones para
empezar a trabajar con este repositorio online, las cuales veremos en la siguiente sección
de la guía.
 Tutoriales de GitHub
La misma web de GitHub tiene unos fantásticos tutoriales en inglés, muy útiles para
iniciarse en GitHub, aprender los comandos de Git y cómo realizar su configuración.

 Hello World - GitHub Guides

 GitHub Guides
 Set Up Git - GitHub Help
 Create a Repo - GitHub Help
 Fork a Repo - GitHub Help
 GitHub Help
Usando Git
Esta sección explica paso a paso cómo usar Git, desde la creación de un repositorio local
hasta la subida de archivos al repositorio remoto.

Contenidos
 Instalar Git
 Creando un repo (local)
 Crear un repositorio remoto
 Subir y bajar cambios a un repositorio remoto
 Trabajando con ramas
 Usando etiquetas

Instalar Git
Si trabajas en un entorno GNU/Linux con gestión de paquetes, esto es tan sencillo como
abrir una terminal y escribir:
$ sudo apt-get install git
Para otros entornos (Windows/Mac) encontrarás ayuda en este enlace: Instalando Git

Esta guía se centrará en el uso de git en GNU/Linux, aunque los comandos y las acciones
son muy similares en otros entornos (Windows/Mac) y sólo requieren pequeñas
modificaciones.

Creando un repo (local)

En este apartado veremos el primer paso trabajando con un gestor de versiones: crear un
repositorio.

Comandos básicos: git init, git clone

Crear un repositorio: git init

Para nuestro primer ejemplo, crearemos un repositorio local en el que empezar a
trabajar. Para ello crearemos una carpeta nueva que contendrá el repositorio, y usaremos
el comando 'git init':
$ mkdir test_repo
$ cd test_repo
$ git init
Tras introducir estos comandos, habremos creado un repositorio nuevo, que estará
disponible de forma local.
El repositorio está vacío, así que vamos a añadir nuestro primer archivo. Abriremos un
editor de texto y crearemos un archivo que se llame 'README.md'. Dentro,
escribiremos la frase 'Hola, mundo!'. Para aquellos que usen GNU/Linux, esto se puede
realizar usando el siguiente comando:
$ echo "Hola, mundo!" > README.md
Añadir archivos al repositorio: git add / git commit
Este achivo está creado, pero todavía no se ha marcado para añadir al repositorio.
El comando que nos permite marcar los archivos que se añadirán al repositorio es 'git
add '.
$ git add README.md
Ahora el archivo está marcado, pero todavía no se ha añadido al repositorio. Podemos
comprobarlo ejecutando el comando 'git status'.
$ git status

Una vez tengamos seleccionados todos los archivos que deseamos incluir en el
repositorio, hacemos un commit con el comando 'git commit'. Un commit guardará en
estado actual de los archivos que hemos marcado, y les asignará un mensaje que indica
los cambios realizados, así como un autor y un identificador.
$ git commit -m "Commit inicial"
Usando el flag '-m' podremos especificar el mensaje que indica los cambios. Si no
usamos el flag '-m', nos aparecerá una pantalla donde escribir el mensaje.
Todo los cambios que hemos hecho hasta ahora han sido únicamente en el repositorio de
nuestro ordenador. En el próximo apartado aprenderemos a subir estos cambios a un
repositorio online, y a descargar los posibles cambios que otros usuarios hayan hecho en
nuestro repositorio.

Crear un repositorio remoto

Para subir nuestro repositorio local a un repositorio online, primero deberemos crear un
repositorio en un sitio online como GitHub o bitbucket. En este apartado aprenderemos a
crear un repositorio online al que subir nuestro código para poder distribuir nuestro
código y además disponer de una copia de respaldo online.

Comandos: git remote add, git clone

Crear un repositorio en GitHub

Ver Crear un repositorio en GitHub .

Añadir la dirección del repositorio remoto a nuestro repositorio local (git remote add)
La primera opción para trabajar con nuestro repositorio remoto es añadir la dirección del
repositorio remoto que acabamos de crear a nuestro repositorio local. Esta es la opción
más lógica si ya disponemos de un repositorio local creado y con algunos contenidos,
como el que se creó en el apartado 02.

Estando dentro del repositorio que creamos en el apartado 02, ejecutaremos el siguiente
comando:
$ git remote add origin <url de nuestro repo>
En el caso del repositorio que yo he creado, el comando quedaría de la siguiente forma:
$ git remote add origin https://github.com/UC3Music-e/test-repository.git
Si deseamos usar https como protocolo para subir y bajar código, o:
$ git remote add origin git@github.com:UC3Music-e/test-repository.git
Si preferimos usar ssh. Para usar ssh deberemos configurar ssh previamente, generando y
añadiendo nuestras claves a github.

Si nos fijamos en la última captura del apartado anterior, la url de nuestro repositorio
aparece en el segundo apartado de las sugerencias que github nos ha hecho para crear el
repositorio local.

Como podemos ver en la imagen, el nombre del directorio donde está almacenado el
repositorio es irrelevante, y aunque no coincide el local con el remoto (test_repo vs test-
repository), git no ha devuelto ningún mensaje de error y la operación se ha llevado a
cabo correctamente.

Crear un repositorio local a partir del repositorio remoto (git clone)

La segunda opción, adecuada cuando hemos creado el repositorio remoto en github, pero
todavía no existe el repositorio local, es usar el comando git clone para hacer un clon
local del remositorio remoto, descargando todos aquellos archivos que se encuentren ya
subidos al repositorio. Este es el método que usaremos también cuando queramos
bajarnos algún repositorio de github para usarlo.
Para clonar el repositorio, podremos usar el protocolo https:
$ git clone https://github.com/UC3Music-e/test-repository.git
o el protocolo ssh:
$ git clone git@github.com:UC3Music-e/test-repository.git
Al hacer un clone de un repositorio vacío, git nos avisará:

Si el repositorio no está vacío, el mensaje devuelto será distinto:

 Crear un repositorio remoto
Para subir nuestro repositorio local a un repositorio online, primero deberemos crear un
repositorio en un sitio online como GitHub o bitbucket. En este apartado aprenderemos a
crear un repositorio online al que subir nuestro código para poder distribuir nuestro
código y además disponer de una copia de respaldo online.

Comandos: git remote add, git clone

Crear un repositorio en GitHub
Ver Crear un repositorio en GitHub .

Añadir la dirección del repositorio remoto a nuestro repositorio local (git remote add)
La primera opción para trabajar con nuestro repositorio remoto es añadir la dirección del
repositorio remoto que acabamos de crear a nuestro repositorio local. Esta es la opción
más lógica si ya disponemos de un repositorio local creado y con algunos contenidos,
como el que se creó en el apartado 02.

Estando dentro del repositorio que creamos en el apartado 02, ejecutaremos el siguiente
comando:
$ git remote add origin <url de nuestro repo>
En el caso del repositorio que yo he creado, el comando quedaría de la siguiente forma:
$ git remote add origin https://github.com/UC3Music-e/test-repository.git
Si deseamos usar https como protocolo para subir y bajar código, o:
$ git remote add origin git@github.com:UC3Music-e/test-repository.git
Si preferimos usar ssh. Para usar ssh deberemos configurar ssh previamente, generando y
añadiendo nuestras claves a github.

Si nos fijamos en la última captura del apartado anterior, la url de nuestro repositorio
aparece en el segundo apartado de las sugerencias que github nos ha hecho para crear el
repositorio local.

Como podemos ver en la imagen, el nombre del directorio donde está almacenado el
repositorio es irrelevante, y aunque no coincide el local con el remoto (test_repo vs test-
repository), git no ha devuelto ningún mensaje de error y la operación se ha llevado a
cabo correctamente.

Crear un repositorio local a partir del repositorio remoto (git clone)

La segunda opción, adecuada cuando hemos creado el repositorio remoto en github, pero
todavía no existe el repositorio local, es usar el comando git clone para hacer un clon
local del remositorio remoto, descargando todos aquellos archivos que se encuentren ya
subidos al repositorio. Este es el método que usaremos también cuando queramos
bajarnos algún repositorio de github para usarlo.

Para clonar el repositorio, podremos usar el protocolo https:

$ git clone https://github.com/UC3Music-e/test-repository.git
o el protocolo ssh:
$ git clone git@github.com:UC3Music-e/test-repository.git
Al hacer un clone de un repositorio vacío, git nos avisará:

Si el repositorio no está vacío, el mensaje devuelto será distinto:

 Subir y bajar cambios a un repositorio remoto
Una vez disponemos de un respositorio local y uno remoto en los que trabajar, vamos a
aprender a subir los cambios que hemos hecho en nuestro repositorio local a nuestro
repositorio remoto. También aprenderemos a mantener nuestro repositorio actualizado
con cambios que puedan haber hecho otros usuarios.

Comandos: git push, git pull, git fetch, git merge

Subir cambios al repositorio remoto: git push

El repositorio remoto que creamos en el apartado 03 está vacío, vamos a actualizarlo
subiendo el README que habíamos creado en el repositorio local. Para ello, una vez
hemos hecho un git commit, debemos usar el comando git push:
$ git push origin <branch>
Donde es la rama que queremos subir al repositorio remoto. En el próximo
apartado hablaremos de las ramas en git, pero de momento lo único que hay que saber es
que la rama principal por defecto siempre es master. Nuestro comando quedaría así:
$ git push origin master
Git nos pedirá nuestras credenciales en el repositorio remoto y, si son correctas, subirá
los cambios al servidor:
Si visitamos la web de nuestro repo en GitHub, podremos ver que los cambios se han
subido correctamente:

Bajar cambios del repositorio remoto: git pull

Imaginemos ahora que queremos actualizar nuestro repositorio local con los posibles
cambios que se hayan podido producir en el repositorio remoto. Si trabajamos en un
mismo repositorio con más gente, este es un paso imprescindible para mantener nuestra
copia local del repositorio al día. De hecho, si existen cambios en el repositorio remoto,
Git no nos dejará subir cambios al repositorio hasta que hayamos descargado la versión
más reciente y la hayamos fusionado con nuestra versión local. Incluso si trabajamos
solos, es posible que subamos cambios desde más de un ordenador, por lo que saber
cómo descargar los cambios del repositorio remoto también resulta útil.

La forma más sencilla de actualizar el repositorio local es mediante el comando git pull:
$ git pull
Si existen cambios, éstos se descargarán y se fusionarán con nuestros cambios locales
automáticamente. Es posible, no obstante, que git nos muestre un error como el
siguiente:

Este error ocurre porque una rama local de nuestro repositorio no tiene asignada una
rama del repositorio remoto. Podremos especificar a qué rama remota corresponde la
rama local con el siguiente comando:
$ git branch --set-upstream-to=origin/master master
Este comando será explicado con más detalle en la próxima sección, dedicada a las
ramas. Una vez resuelto el problema, al hacer pull nos debería aparecer una pantalla
similar a ésta:
Usando el comando git log, podremos ver los cambios que se han efectuado, junto con
sus mensajes de commit:
git log

Bajar cambios y fusionarlos manualmente: git fetch y git merge

Al hacer git pull los cambios que hubiese en el servidor remoto se bajarán y fusionarán
automáticamente. Si en lugar de eso, queremos bajar los cambios y fusionarlos de
manera manual, podemos usar el comando git fetch :
$ git fetch
Veremos que en este caso los cambios no se fusionan, sino que quedan en una rama
nueva llamada origin/master:
Para aplicar los cambios usaremos el comando git merge, que explicaremos en la sección
dedicada a las ramas de Git:
$ git merge origin/master

Trabajando con ramas

En este apartado aprenderemos qué son las ramas de Git y cómo usarlas.

Comandos: git branch, git checkout, git merge

¿Por qué usar ramas?

Un rama (branch) en Git es una forma de separar nuestro trabajo del trabajo ya existente
en el repositorio. Imaginemos, por ejemplo, que queremos trabajar en algo que no es
definitivo o estable y no lo queremos subir a master por si rompemos algo que funciona.
En este caso crearíamos una rama aparte en la que trabajar, y cuando nuestro trabajo esté
listo, la fusionaríamos con master.

Esto permite también que si, por ejemplo, encontrásemos un bug en la rama master
mientras trabajamos en nuestra otra rama, podríamos crear una rama para solucionar el
bug. Una vez resuelto, esta rama se podría integrar con master y con la otra rama que
habíamos creado.

Por ello, cada vez que añadimos una feature nueva a nuestro código, es conveniente
crear una rama nueva en el repositorio en la que trabajar.

Creando ramas: git branch

Para crear una rama nueva, usaremos el comando git branch:
$ git branch <nombre_rama>
En nuestro caso crearemos una rama llamada test:
$ git branch test
Podremos ver las ramas que están creadas mediante el comando git branch, sin indicar
un nombre. El asterisco señala nuestra rama actual:
$ git branch

Cambiando de rama: git checkout

Hemos creado nuestra rama, pero seguimos trabajando en la rama master. Para cambiar a
la nueva rama que hemos creado, usaremos el comando `git checkout :
$ git checkout <nombre_rama>
En nuestro caso:
$ git checkout test

Podemos también crear la rama y cambiar de ella en un solo comando, usando la opción
"-b":
$ git checkout -b <nombre_rama>
En nuestro caso:
$ git checkout -b test
Subiendo ramas al repositorio remoto
Las ramas que hemos creado hasta ahora sólo existen en nuestro repositorio local, si
queremos que se actualicen en el repositorio remoto, tendremos que subirlas con git
push:
$ git push origin <rama>
Para ello, crearemos un nuevo archivo y lo añadiremos al repositorio local en la rama
que acabamos de crear. Crearemos un archivo llamado prueba.txt con los siguientes
contenidos:"Probando las ramas de git!":
Y lo añadiremos al repositorio local en la rama test:
$ git add prueba.txt
$ git commit -m 'Añadido archivo de prueba en rama test'
Una vez añadidos los cambios, podremos subirlos al repositorio remoto en una nueva
rama:
$ git push origin test
Veremos que git nos informa de que sea ha creado una nueva rama en el repositorio
remoto, que se llama igual que la rama local, test:
Si vamos al repositorio en GitHub, veremos que ha aparecido una nueva rama en la
portada del repositorio:
Y que también aparece en el apartado branches:

Por último, en el apartado network, tenemos una vista gráfica de la nueva rama creada,
en la que se ve que los cambios de la rama test no han afectado a la rama master:

Podemos comprobar que esto es cierto cambiando a la rama master en el repositorio

local:
$ git checkout master
Si hacemos un ls en el directorio, veremos que el archivo prueba.txt no existe en la rama
master:
Fusionando ramas: git merge
Tras haber realizado los cambios en la rama test, y haberlos probado, la rama test ya
habrá cumplido su función, y pasaremos a integrar estos cambios en la rama master. Para
ello, nos aseguramos de estar en la rama master, y usamos el comando git merge:
$ git checkout <rama_base>
$ git merge <rama_a_fusionar>
En nuestro caso:
$ git checkout master
$ git merge test
En la mayoría de casos, Git es suficientemente listo como para saber cómo fusionar dos
ramas automáticamente, aunque hayamos hecho cambios al mismo fichero en ambas
ramas. A veces, sin embargo, Git nos dice que ha encontrado conflictos entre ambas
versiones que no sabe solucionar, y nos pide que los resolvamos manualmente. En
próximas secciones trataremos la resolución manual de conflictos en Git.

Borrando ramas
Una vez hemos fusionado los cambios de nuestra rama test con la rama master podremos
seguir trabajando en ella o, si ya no nos es útil, borrarla. Las ramas creadas se pueden
borrar con el comando git branch, usando la opción "-d":
$ git branch -d <rama_a_borrar>
En nuestro caso:
$ git branch -d test
Este cambio no afectará al repositorio remotor, que seguirá teniendo la rama test. Si
queremos borrar el repositorio remoto, usaremos el comando git push:
$ git push origin :<rama_a_borrar>
Este comando se basa en que una misma rama se puede llamar de forma distinta en el
repositorio local que en el remoto, de forma que si quisiéramos subir los cambios de esa
rama, tendríamos que especificar ambos nombres:
$ git push origin <rama_local>:<rama_remota>
Si en lugar de especificar un nombre, dejamos ese término en blanco, Git eliminará la
rama remota. En nuestro caso, el comando sería:
$ git push origin :test
Y el resultado sería:
Visitando el repositorio en github podremos comprobar que la rama ya no existe:

Usando etiquetas
En este apartado aprenderemos qué son las etiquetas de git y cómo usarlas.

Comandos: git tag

¿Por qué usar etiquetas?

Las etiquetas de git se usan para marcar un commit específico. Imagina que acabas de
hacer un commit con el que completas la versión 1.0 de tu software. Resulta interesante
marcar el commit con una etiqueta que indique que es la versión 1.0 para ser capaz de
encontrar esa release de forma sencilla entre todos los commits. También sería útil para
los usuarios de nuestro repositorio, porque distinguirían fácilmente entre el código que
está siendo desarrollado y las distintas releases.

En git existen dos tipos de etiqueta: ligera (lightweight) y anotada (annotated). Una
etiqueta ligera es un puntero a un commit, de forma parecida a una rama, pero fija en ese
commit. Sería como asignar un nombre lógico a un commit. Las etiquetas anotadas
tienen la misma función, pero se almacenan como objetos de git, con checksum, nombre
del autor, fecha y mensaje de etiquetado. Debido a todos estos datos extra se suele
recomendar usar etiquetas anotadas, aunque si quieres una etiqueta rápida puedes usar
una etiqueta ligera.

Creando una etiqueta ligera (lightweight)

Para crear una etiqueta ligera se usa el comando git tag sin ningún flag extra:
$ git tag <nombre_etiqueta>
Por ejemplo:
$ git tag etiqueta_ligera
Podremos ver las etiquetas creadas con el comando `git tag :
$ git tag
Creando una etiqueta anotada (annotated)
Si en lugar de una etiqueta ligera queremos crear una etiqueta anotada, añadimos el flag
"-a". Las etiquetas anotadas son objetos de Git, como los commits, y tiene asociados un
autor y un mensaje.
$ git tag -a <nombre_etiqueta> -m "Mensaje descriptivo aquí"
Etiquetando un commit pasado
Al crear una etiqueta con el comando tag, por defecto estamos etiquetando el commit
más reciente. Si queremos etiquetar un commit pasado distinto, bastará con usar el hash
de ese commit al ejecutar el comando:
$ git tag -a <nombre_etiqueta> <hash_commit>
Borrando etiquetas
Para borrar una etiqueta en nuestro repositorio local usaremos el flag "-d", de forma
similar a las ramas:
$ git tag -d <nombre_etiqueta>
Si la etiqueta que queremos borrar está en un repositorio remoto, el comando a ejecutar
es el siguiente:
$ git push origin :refs/tags/<nombre_etiqueta>
Subiendo etiquetas al repositorio remoto
Hay dos formas de subir etiquetas al repositorio remoto. La primera es subiendo cada
etiqueta de forma individual, usando su nombre:
$ git push origin <nombre_etiqueta>
Si en lugar de subirlas una a una queremos subirlas todas de golpe, añadimos el flag "--
tags":
$ git push origin --tags

¿Y si uso Windows?
Aunque esta guía se centra principalmente en el uso de Git desde la consola de
comandos en un sistema GNU/Linux, también existen otras alternativas para usar Git
desde Windows.

GitHub Desktop
GitHub posee una aplicación llamada GitHub Desktop que nos permite gestionar
repositorios de Git de forma gráfica desde Windows.

Configurando GitHub Desktop

Tras instalar GitHub Desktop en nuestro sistema, el programa nos pedirá nuestros datos
de GitHub para su configuración.
Tras la configuración se nos mostrará la pantalla principal del programa con un
repositorio de prueba con el que aprender a usar GitHub
Desktop. 

Si la configuración no ha sido correcta, o si deseamos cambiarla, podemos usar la

pantalla de opciones de GitHub
Desktop. 

Clonar repositorios de GitHub

Para clonar un repositorio de GitHub, pulsaremos en el símbolo "+" que aparece en la
esquina superior izquierda.

En el menú desplegable podremos ver los repositorios que tenemos en nuestra cuenta de
GitHub. Seleccionaremos el que deseemos clonar y el programa nos preguntará en qué
carpeta local queremos que se almacenen los archivos del repositorio.
Una vez seleccionada la carpeta, nos mostrará una pantalla de carga mientras GitHub
Desktop descarga nuestro repositorio.

Añadir archivos al repositorio (git add & git commit)

Si creamos archivos o editamos archivos existentes en el directorio del repositorio,
GitHub Desktop lo reconocerá y nos oferecerá la posibilidad de añadirlos al commit
actual. Esto sería equivalente a ejecutar un comando git add en la
terminal. 

Una vez están seleccionados los archivos, podremos escribir un mensaje de commit y
una descripción, igual que haríamos con un comando git commit desde la terminal.
Pulsando el botón "Commit to master" crearía el commit en la rama
master. 

Eliminar archivos del repositorio (git rm & git commit)

Para eliminar archivos del repositorio, primero debemos borrarlos de la carpeta local del
repositorio. Una vez borrados, la pantalla principal de GitHub Desktop nos ofrecerá un
diálogo similar al de añadir archivos, que podremos usar para hacer un commit en el que
se borren dichos archivos del
repositorio. 

Subir y bajar cambios desde el repositorio remoto (git push & git pull)
Para subir y bajar cambios desde el repositorio remoto, GitHub Desktop dispone de un
botón "sync" en la parte superior
derecha. 
Al hacer click veremos como el botón para a poner "syncing", lo cual nos indica que está
sincronizando datos con el repositorio

remoto. 

Explora y experimenta
En esta sección hemos cubierto los comandos básicos de Git realizados desde GitHub
Desktop, pero la aplicación permite llevar a cabo muchas más acciones. Explora y
experimenta con la interfaz para descubrilas, o usa la guía online de GitHub Desktop .
Colaborando con proyectos en GitHub
Esta sección explica cómo colaborar con proyectos alojados en GitHub usando las
principales herramientas que nos proporciona GitHub: los forks y los pull requests.

Contenidos:

 Colaborando con proyectos en GitHub

 Forkeando un repositorio
 Creando un pull request

Forkeando un repositorio
El primer paso para colaborar con un proyecto en GitHub es hacer un fork. Un fork es
una copia de un repositorio de GitHub independiente del repositorio original. Nosotros
somos los dueños de ese fork, por lo que podemos hacer todos los cambios que
queramos, aunque no tengamos permisos de escritura en el repositorio original.

Creando un fork desde GitHub

Crear un fork desde GitHub es muy sencillo. Ve a la página principal del repositorio del
que quieras hacer un fork y pulsa el botón fork.

Una vez completado el fork, nos aparecerá en nuestra cuenta el repositorio "forkeado":
Clonando el repositorio en nuestro PC
Una vez creado, podemos hacer una copia del repositorio en nuestro PC para editarlo.
Para ello, abrimos una terminal e introducimos los siguientes comandos:
$ git clone <url_del_repo>
En mi caso:
$ git clone git@github.com:David-Estevez/test-repository.git

(opcional) Añadiendo el repositorio original a los repositorios remotos

Un repositorio remoto (remote) es un repositorio online desde el que descargar nuestros
cambios en el repositorio local. Al clonar un repositorio, se crea un remoto
llamado origin, que corresponde a nuestro fork. Para poder disponer de los cambios que
se hagan en el repositorio principal, podemos añadir un remoto upstream que apunte al
repositorio original:
$ git remote add upstream <url_del_repo_original>
Una vez añadido, podemos bajar cambios del repositorio original con un pull:
$ git pull upstream <rama_a_descargar>
En mi caso:
$ git remote add upstream git@github.com:UC3Music/test-repository.git
$ git pull remote master
El resultado de ambos pasos debería ser el
siguiente: 

Forkeando un repositorio
Una vez hemos creado nuestro fork y hemos añadido los cambios oportunos, el siguiente paso es
proponer al dueño del repositorio original que los incluya en su proyecto. Para ello existen en GitHub
los pull request.

Añadiendo cambios al repositorio

Antes de hacer un pull request hay que tener algún cambio en nuestro repositorio. A modo de
ejemplo, podemos crear un archivo fork.md
Al igual que en la sección usando Git, esto se puede hacer con un editor de texto, o directamente
desde la terminal:
$ echo "Cambios hechos desde un fork" > fork.md
A continuación, creamos un commit con estos cambios y lo subimos a nuestro fork ( origin):
$ git add fork.md
$ git commit -m 'Añadidos cambios al fork'
$ git push origin master
Una vez subidos los cambios, aparecerán en nuestro repositorio en GitHub:

Abriendo un pull request

Para abrir un pull request vamos a la web del repositorio original a partir del cual hicimos nuestro
fork, y hacemos click en "New pull request".
GitHub nos llevará a una página en la que podremos comparar los cambios entre las diversas ramas
y, seleccionando la opción "compare across forks" también entre los forks del repositorio. A
continuación, seleccionaremos como "base fork" la rama master del repositorio original, y
como "head fork" la rama `master de nuestro fork.

GitHub nos mostrará una página similar a la que nos muestra al crear una issue. Es esta página
podremos resumir y explicar los cambios realizados para que al autor del repositorio original le
resulte más sencillo saber qué cambios hemos hecho y con qué fin. También podremos pedir a
usuarios concretos de GitHub que revisen los cambios para darles el visto bueno. Normalmente estos
usuarios serán las personas encargadas de mantener el proyecto.
Una vez rellenado el formulario, hacemos click en "Create pull request". Ya sólo queda esperar a
que nos acepten los cambios (o nos pidan una revisión).

Aceptando un pull request

Una vez creado, el pull request aparecerá en la pestaña "Pull requests". Para aceptar un pull request
es necesario tener permisos de escritura en el repositorio. Si no los tienes no te quedará más remedio
que esperar a que sea aceptado por las personas encargadas de mantener el proyecto. Para aceptar el
pull request, una vez revisado, sólo hay que hacer click en "Merge pull request".
En caso de que se haya llevado a cabo la integración con éxito de nuestros cambios, el pull request
pasará estar marcado como "merged".
Visitando la página principal podremos comprobar que los cambios se han aplicado con éxito al
repositorio original:
 Creando Pull Request
Una vez hemos creado nuestro fork y hemos añadido los cambios oportunos, el siguiente
paso es proponer al dueño del repositorio original que los incluya en su proyecto. Para
ello existen en GitHub los pull request.

Añadiendo cambios al repositorio

Antes de hacer un pull request hay que tener algún cambio en nuestro repositorio. A
modo de ejemplo, podemos crear un archivo fork.md
Al igual que en la sección usando Git, esto se puede hacer con un editor de texto, o
directamente desde la terminal:
$ echo "Cambios hechos desde un fork" > fork.md

A continuación, creamos un commit con estos cambios y lo subimos a nuestro fork

(origin):
$ git add fork.md
$ git commit -m 'Añadidos cambios al fork'
$ git push origin master
Una vez subidos los cambios, aparecerán en nuestro repositorio en GitHub:
Abriendo un pull request
Para abrir un pull request vamos a la web del repositorio original a partir del cual
hicimos nuestro fork, y hacemos click en "New pull request".

GitHub nos llevará a una página en la que podremos comparar los cambios entre las
diversas ramas y, seleccionando la opción "compare across forks" también entre los
forks del repositorio. A continuación, seleccionaremos como "base fork" la
rama master del repositorio original, y como "head fork" la rama `master de nuestro
fork.
GitHub nos mostrará una página similar a la que nos muestra al crear una issue. Es esta
página podremos resumir y explicar los cambios realizados para que al autor del
repositorio original le resulte más sencillo saber qué cambios hemos hecho y con qué fin.
También podremos pedir a usuarios concretos de GitHub que revisen los cambios para
darles el visto bueno. Normalmente estos usuarios serán las personas encargadas de
mantener el proyecto.
Una vez rellenado el formulario, hacemos click en "Create pull request". Ya sólo
queda esperar a que nos acepten los cambios (o nos pidan una revisión).

Aceptando un pull request

Una vez creado, el pull request aparecerá en la pestaña "Pull requests". Para aceptar un
pull request es necesario tener permisos de escritura en el repositorio. Si no los tienes no
te quedará más remedio que esperar a que sea aceptado por las personas encargadas de
mantener el proyecto. Para aceptar el pull request, una vez revisado, sólo hay que hacer
click en "Merge pull request".
En caso de que se haya llevado a cabo la integración con éxito de nuestros cambios, el
pull request pasará estar marcado como "merged".
Visitando la página principal podremos comprobar que los cambios se han aplicado con
éxito al repositorio original:
 Buenas prácticas al trabajar con Git
Sigue el GitFlow Workflow
El GitFlow Workflow es una metodología de trabajo basada en el división de las
distintas etapas de producción de software en distintas ramas del repositorio:

 master: En la rama máster se encuentran las releases estables de nuestro

software. Esta es la rama que un usuario típico se descargará para usar nuestro software,
por lo que todo lo que hay en esta rama debería ser funcional. Sin embargo, puede que
las últimas mejoras introducidas en el software no estén disponibles todavía en esta
rama.
 develop: En esta rama surge de la última release de master. En ella se van
integrando todas las nuevas características hasta la siguiente release.
 feature-X: Cada nueva mejora o característica que vayamos a introducir en
nuestro software tendrá una rama que contendrá su desarrollo. Las ramas
de feature salen de la rama develop y una vez completado el desarrollo de la mejora, se
vuelven a integrar en develop.
 release-X: Las ramas de release se crean cuando se va a publicar la siguiente
versión del software y surgen de la rama develop . En estas ramas, el desarrollo de
nuevas características se congela, y se trabaja en arreglar bugs y generar documentación.
Una vez listo para la publicación, se integra en master y se etiqueta con el número de
versión correspondiente. Se integran también con develop, ya que su contenido ha
podido cambiar debido a nuevas mejoras.
 hotfix-X: Si nuestro código contiene bugs críticos que es necesario parchear de
manera inmediata, es posible crear una rama hotfix a partir de la publicación
correspondiente en la rama master. Esta rama contendrá únicamente los cambios que
haya que realizar para parchear el bug. Una vez arreglado, se integrará en master, con su
etiqueta de versión correspondiente y en develop.

Mensajes de commit
Los mensajes de commit son una herramienta muy útil para el desarrollo de software, ya
que nos permiten encontrar cambios concretos en la historia de nuestro repositorio. No
obstante, muchas veces no les prestamos toda la atención que se merecen, y escribrimos
mensajes de commit que son de muy poca ayuda para nuestros compañeros y para
nuestros yo del futuro. Esta sección aporta buenas prácticas a seguir para aprovechar los
mensajes de commit al máximo.

Escribe mensajes de commit claros y concisos

Las siguentes reglas de estilo harán que tus mensajes de commit sean más claros y
concisos:

 Los mensajes de commit tienes dos partes principales: un asunto y un mensaje

(como los correos electrónicos). Si el contenido del commit se puede explicar en el
 asunto, no es necesario incluir un mensaje. Ambas partes deben ir separadas por una
línea en blanco.
 La línea de asunto no debería extenderse más de 50 caracteres, y el cuerpo del
mensaje debería tener una extensión máxima (por línea) de 72 caracteres. Esto ayuda a
su visualización en distintas plataformas y dispositivos.
 La línea de asunto debe comenzar con letra mayúscula y terminar sin punto.
Piensa, por ejemplo, en el asunto de un correo electrónico.
 Usa el imperativo en el mensaje de commit. Internamente Git usa el imperativo
en los mensajes que genera. Por ejemplo, Merge branch 'feature-refactor'  tras
fusionar la rama feature-refactor . Para mantener la coherencia de todos los mensajes
de commit, adoptaremos la convención de Git de usar el imperativo.

Usa el mensaje de commit para aportar contexto y explicar el por qué detras de un cambio.
La principal utilidad de un mensaje de commit no es explicar cuáles son los cambios que
realizará ese commit, ya que se pueden consultar en el diff del commit. La principal
utilidad del mensaje de commit es explicar el por qué detras de esos cambios.

Por tanto, cuando el por qué de un cambio no quede suficientemente claro con el asunto
y el diff del commit, usaremos el cuerpo del mensaje de commit para aportar un contexto
y un por qué a dichos cambios. Esto es especialmente importante si existen soluciones
alternativas a la implementada en el commit, ya que así los futuros mantenedores del
código pueden saber por qué se elegió esa solución frente a otras alternativas.

Si el cambio realizado, además, puede tener consecuencias inesperadas o efectos

secundarios en el resto del código, es importante especificarlo también en el mensaje de
commit.

Recursos para aprender más

Si este manual te ha sabido a poco, aquí tienes algunos recursos con los que aprender
más.

 Pro Git: un manual de git completo en inglés, del cual existe una traducción
parcial en español .
 Tutoriales de GitHub : esta sección de este manual ofrece links a distintas guías y
tutoriales dentro de GitHub.
  Atlassian Git Tutorials : una completa serie de tutoriales sobre Git.
 Comparing Workflows: guía sobre los distintos flujos de trabajo posibles con Git.
 Open Source Guides : guías para desarrollar o contribuir a proyectos Open
Source.
 Tutorial GitHub y Freecad : una serie de videotutoriales hechos por el maestro
Obijuan en los que aprender a usar GitHub a través de objetos creados en
Freecad.
 Guía online de GitHub Desktop .
 How to Write a Git Commit Message : artículo con buenas prácticas para escribir
mensajes de commit. La sección sobre mensajes de commit del capítulo Buenas
prácticas al trabajar con Git  de este manual se basa en este artículo.
 WhatTheCommit : Mensajes de commit aleatorios.

Bibliografía
https://david-estevez.gitbooks.io/the-git-the-bad-and-the-ugly/content/es/