Alberto Dorta
ÍNDICE

Git…………………………………………………………………………………………….…………..3

Configuración…………………………………………………………………..……………………… 5

Repositorio Git…………………………………………………………………….………………….…6

Ignorando Archivos……………………………………………………………………………………. 8

Eliminar / Mover Archivos…………………………………………………………………………….. 9

Deshacer……………………………………………………………………………………………..…10

Repositorios Remotos……………………………………………………………………..………….11

Ramas…………………………………………………………………………….……………………. 13

Ramificar y Fusionar……………………………………………………………………………………17

Ramas Remotas………………………………………………………………………….……………. 23

Reorganización………………………………………………………………………………………… 27

SSH……………………………………………………………………………….………………………31

Otros Comandos………………………………………………………………………………………..32

Volver a un commit/versión anterior…………………………………………………………………..33


2
 GIT

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o
conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas
más adelante

Los VCSs (Version Control System) permiten revertir archivos a un estado anterior, revertir el
proyecto entero a un estado anterior, comparar cambios a lo largo del tiempo, ver quién modificó
por última vez algo que puede estar causando un problema, quién introdujo un error y cuándo, y
mucho más.

Sistemas de Control de Versiones Locales

Si hay un fallo no voy a poder recuperar lo que tenía porque esta todo guardado en el mismo
sitio, en la máquina. Es fácil olvidar en qué directorio te encuentras, y guardar accidentalmente en
el archivo equivocado o sobrescribir archivos que no querías. Ej: rcs

Sistemas de Control de Versiones Centralizados

Los CVCs (Centralized Version Control System) mejoran el anterior. Cuando guardamos la primera
versión del fichero lo que guarda es la diferencia que había entre el fichero original y el fichero
nuevo, no guarda todo el fichero. Se basan en el almacenamiento de diferencia. Tienen un único
servidor que contiene todos los archivos versionados, y varios clientes que descargan los
archivos de ese lugar central (más fácil que tener que lidiar con bases de datos locales en cada
cliente). Ej: cvs, subversion, perforce..


3
Sistemas de Control de Versiones Distribuidos

En los DVCs (Distributed Version Control Systems) los clientes no sólo descargan la última
instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y
estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes
puede copiarse en el servidor para restaurarlo. Lo que ocurre es que además de tener un fichero
en cada maquina, también tiene la base de datos. La base de datos del servidor esta replicada en
todas las maquinas en las que voy a trabajar. Cada uno de los participantes es a su vez un
servidor. Ej: Git, Mercurial, Bazaar..

Git modela sus datos como un conjunto de instantáneas de un mini sistema de archivos. Cada
vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente hace
una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa
instantánea. Para ser eficiente, si los archivos no se han modificado, Git no almacena el archivo
de nuevo

El flujo de trabajo básico en Git es algo así:

1. Modificas una serie de archivos en tu directorio de trabajo.

2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de preparación.

3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación,
y almacena esa instantánea de manera permanente en tu directorio de Git.

4
• Configuración

git config

…:~$ ~/.gitconfig ==> fichero de configuración global del usuario

…:~$ git config --global user.name “Alberto Dorta” ==> configurar nombre de
usuario

…:~$ git config --global user.email “[email protected]” ==> configurar email

asociado

…:~$ git config --global credential.helper cache ==> para que no sea necesario
introducir la contraseña cada vez

…:~$ git config --global push.default "matching" ==> que todos los cambios se
empujen en el repositorio git

…:~$ git config --global branch.autosetuprebase always ==> para evitar

confirmaciones innecesarias

…:~$ git config --global core.editor vi ==> configura el editor de texto por defecto

…:~$ git config --global color.ui true ==> colorea los resultados que muestre

…:~$ git config --global color.diff “blue bold” ==> asigna colores a partes
específicas

color.branch cyan dim

color.diff magenta blink
color.status

git config --unset color.ui ==> deshace la configuración de esa propiedad

git config --unset core.editor

Esto lo hace de forma global. Para hacerlo en local añadir --local antes del --unset

Comprobar configuración

…:~$ cat ~/.gitconfig

…:~$ git config --list

…:~$ git config user.name

Alberto Dorta

Ver manual para cualquier comando:

…:~$ git help <comando>

…:~$ git <comando> --help
…:~$ man git-<comando>

5
Repositorio Git

Un repositorio es un espacio centralizado donde se almacena, organiza, mantiene y difunde

información digital, habitualmente archivos informáticos, que pueden contener trabajos
científicos, conjuntos de datos o software.

Para inicializar un repositorio en un directorio existente, me sitúo en el directorio y escribo:

…:~$ git init

Esto crea un subdirectorio llamado .git que contiene todos los archivos necesarios del
repositorio (esqueleto de repositorio). Aunque, todavía no hay nada en el proyecto.

Cada fichero tiene dos entradas: untracked y tracked.

Para que pase de untracked a tracked hago git add file1

Para controlar versiones de archivos existentes comenzaremos haciendo el seguimiento de esos

archivos (add) y confirmándolos (commit):

…:~$ git add *.c ==> Añade todos los archivos terminados en .c

…:~$ git add README ==> Añade el fichero README

…:~$ git add . ==> Añade todos los ficheros y subdirectorios del directorio actual
al índice del repositorio git


Una vez hecho el add, se añaden a la carpeta oculta /.git y pasan al estado stage.

…:~$ git commit -m “Initial Version” ==> Confirma los cambios del índice en el
repositorio git local


Lo que hay en el directorio /directorio_de_trabajo es el estado del trabajo y lo que hay en

el directorio /.git es lo que hay en el control de versiones

Clonando un Repositorio existente

Para obtener una copia de un repositorio Git existente usamos git clone:

…:~$ git clone [URL]

…:~$ git clone https://github.com/aldordar/test.git

Esto crea un directorio test, inicializa un directorio .git en su interior, descarga toda la
información de ese repositorio, y saca una copia de trabajo de la última versión. Si te metes en el
nuevo directorio test, verás que están los archivos del proyecto, listos para ser utilizados.

…:~$ git clone https://github.com/aldordar/test.git prueba

Ese comando hace lo mismo que el anterior, pero el directorio de destino se llamará prueba

Para saber el estado del repositorio git local de nuestros archivos usamos (qué ficheros han
cambiado, cuáles son nuevos y cuáles han sido borrados) :

…:~$ git status

# On branch master
nothing to commit (working directory clean)

Directorio de trabajo limpio. Otro ejemplo:

…:~$ git add README.md (“md” formato markdown)

git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to
unstage)
#
# new file: README

…:~$ vi test.cpp ==> modifico archivo

…:~$ git status

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: README

# Changed but not updated:

# (use "git add <file>..." to update what will
be committed)
#
# modified: test.cpp
7
Ignorando archivos

Normalmente, tendremos algún tipo de archivo que no queremos que Git añada. Para ello
creamos el fichero .gitignore:

…:~$ touch .gitignore (creamos)

…:~$ vi .gitignore (editamos)

…:~$ cat .gitignore

*.[oa] ==> ignora archivos terminados en o o a (archivos de compilación)

*~ ==> archivos terminados en ~ (archivos temporales)

*.a # no .a files
!lib.a # but do track lib.a, even though you're ignoring .a files above
/TODO # only ignore the root TODO file, not subdir/TODO
build/ # ignore all files in the build/ directory
doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt

Para saber exactamente lo que ha cambiado usamos:

…:~$ git diff

OJO!!! Este comando solo muestra los cambios que todavía no están preparados. Para hacerlo:

…:~$ git diff --cached

Confirmar cambios

Cualquier archivo sobre el que no se haya ejecutado git add desde su última edición, no se
incluirá en la confirmación. (git status para ver que todo está preparado)

…:~$ git commit

Se abrirá el editor de texto (git config --global core.editor) donde aparece git status
comentado (#). Podemos borrarlo y escribir nuestro propio mensaje de confirmación o:

…:~$ git commit -m “First Version”

Una vez hecho nos da información de rama (master), suma de comprobación (463dc4f),
cuántos archivos se modificaron y estadísticas.

Saltar el área de preparación:

…:~$ git commit -a -m “First Version”

Hace que prepare todo archivo que estaba en seguimiento antes de la confirmación, y luego lo
confirma.

8
Eliminar / Mover archivos

…:~$ rm file ==> modificado pero no actualizado

…:~$ git rm file ==> modificado actualizado, desaparecerá en el próximo commit

Si ya habíamos modificado el archivo y lo tenías en el área de preparación, deberás forzar su

eliminación:

…:~$ git rm -f file

Para mantener el archivo en el área de trabajo pero eliminarlo del área de preparación:

…:~$ git rm --cached file

Para mover:

…:~$ git mv file_from file_to

…:~$ git mv README.txt README.md ==> cambia el nombre

…:~$ git status

# On branch master
# Your branch is ahead of 'origin/master' by 1
commit.
#
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#

# renamed: README.txt -> README.md

#

Equivale a
…:~$ mv README.txt README.md
…:~$ git rm README.txt
…:~$ git add README.md

Historial de Confirmaciones

Para mirar qué confirmaciones y qué modificaciones se han llevado a cabo:

…:~$ git log

…:~$ git log -p -2 ==> -p muestra diferencias y -2 las últimas 2 confirmaciones

Lista las confirmaciones hechas sobre ese repositorio en orden cronológico inverso.

En cada confirmación aparece su suma de comprobación SHA-1 (Secure Hash Algorithm), el

autor y correo, y la fecha:

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Alberto Dorta <[email protected]>
Date: Sat Mar 15 10:31:28 2008 -0700

9
Deshacer

• Modificar última confirmación

…:~$ git commit -m “some commit”

…:~$ git add forgotten_file
…:~$ git commit --amend

Estos tres comandos acabarán convirtiéndose en una única confirmación. Se abrirá el editor de
texto (nano) para modificar el nombre “some commit”.

• Deshacer preparación de un archivo

…:~$ git status

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README.txt
# modified: test.rb

…:~$ git reset HEAD test.rb

…:~$ git status

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: README.txt
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)

# modified: test.rb

• Deshacer modificación de un archivo

…:~$ git checkout -- test.rb

• Eliminar el último commit

Eliminar solo el commit, los ficheros que se habían
confirmado se quedarán ahora en el estado untracked
…:~$ git reset HEAD~1
…:~$ git reset HEAD^ --hard Eliminar el commit y los ficheros o
modificaciones de los ficheros del último commit

10
Repositorios Remotos

Los repositorios remotos son versiones de tu proyecto que se encuentran alojados en Internet o
en algún punto de la red. Lo que hacemos es agregar a GitHub un repositorio que ya existe.

Para añadir un repositorio remoto (usar enlaces de los repositorios de github.com )

(New Repository):

Lugar donde
enviaremos nuestros
git remote add [nombre/alias] [URL] commits

…:~$ git remote add test https://github.com/aldordar/test_2.git

Para mostrar los repositorios remotos usar:

Lugar donde estará el
repositorio de manera
…:~$ git remote remota
…:~$ git remote -v ==> Muestra la URL asociada

OJO!

Si clonamos un repositorio, deberíamos ver el nombre “origin” (nombre predeterminado Git) en

nuestros repositorios remotos.

…:~$ git clone https://github.com/aldordar/prueba.git

…
…
… GitHub prueba .gitignore

README.md

100% done. LICENSE

…:~$ cd prueba ==> git clone crea un directorio

local
prueba en local

…:~$ git remote -v

origin https://github.com/aldordar/prueba.git

• Recuperar datos de repositorios remotos

Comando:

git fetch [nombre_repo_remoto] ==> Descarga los datos del proyecto

que no tenemos todavía

…:~$ git fetch origin

Si clonas un repositorio, el comando añade automáticamente ese repositorio remoto con el

nombre de "origin". Por tanto, git fetch origin permite descargar cambios que han
sucedido en el repositorio remoto (de GitHub a local). Es importante tener en cuenta que el
comando fetch sólo recupera la información y la pone en tu repositorio local, no la une
automáticamente con tu trabajo ni modifica aquello en lo que estás trabajando.

11
• Enviando a repositorios remotos

git push [nombre_remoto] [nombre_rama]

…:~$ git push origin master

***Sube cambios hacia el repositorio***

Este comando funciona únicamente si hemos clonado de un servidor en el que tienes permiso de
escritura, y nadie ha enviado información mientras tanto.

Para inspeccionar un repositorio remoto:

git remote show [nombre_remoto]

…:~$ git remote show prueba

…:~$ git remote rename prueba test ==> Cambia el nombre de prueba a test

…:~$ git remote rm prueba ==> Eliminar el repositorio remoto




4 personas 1 proyecto

- Repositorio local_1

- Repositorio local_2
- Repositorio GitHub (remoto)
- Repositorio local_3

- Repositorio local_4

• Cada vez que alguien quiera hacer cambios tendrá que hacer fetch para verificar si hay
cambios realizados por otra persona.

• Luego para push para subir sus cambios.

GitHub

local

origin
PROJECT

master

12
RAMAS

Una rama Git es un apuntador móvil apuntando a una de las confirmaciones (commit).

• La rama por defecto de Git es master.

• Con la primera confirmación (commit) se creará esta rama principal apuntando a dicha
confirmación.

• La rama irá avanzando automáticamente con cada confirmación que realicemos.

• La rama master siempre apuntará a la última confirmación realizada.

Cuando creamos una rama nueva simplemente se crea un nuevo apuntador para moverlo
libremente. Para crear una rama nueva:

git branch [nombre_rama]

…:~$ git branch testing

Esto creará un nuevo apuntador apuntando al mismo commit donde estés actualmente.

13
• ¿Cómo sabemos en qué rama estamos?

Existe un apuntador especial denominado HEAD ==> apuntador rama local actual.

…:~$ git branch ==> muestra la rama activa

* master
testing

git branch solamente crea una nueva rama, y no salta a ella. Para saltar de una rama a otra:

git checkout [wanted_rama]

…:~$ git checkout testing

14
Ahora realizamos cambios:

…:~$ vi test.rb
…:~$ git commit -a -m “Make a Change”

La rama apuntada por HEAD avanza con cada confirmación de cambios.

Realizamos cambios en la rama master:

…:~$ git checkout master ==> Para realizar cambios primero nos movemos a ella

15
…:~$ vi test.rb
…:~$ git commit -a -m “Make another Change”

Los cambios realizados en cada sesión están aislados en ramas independientes:

16
RAMIFICAR Y FUISONAR

Trabajaremos sobre un proyecto. (Tenemos varias confirmaciones realizadas)

Ahora deberemos trabajar sobre un problema o error #53 del sistema de la empresa (issue).
Creamos una nueva rama y saltamos a ella:

…:~$ git checkout -b iss53 ==> crea una nueva rama y salta a ella

Switched to a new branch “iss53”

Shortcut of:

…:~$ git branch iss53

…:~$ git checkout iss53

Trabajamos sobre la nueva rama:

…:~$ vi index.html
…:~$ git commit -a -m “Added a New Footer [issue 53]"

17
Seguidamente, deberemos resolver otro problema, sin mezclarlo con los cambios realizados en el
error #53. (debemos ir a la rama master y seguir trabajando a partir de ella)

OJO! Git no nos permitirá saltar a otra rama si tenemos cambios no confirmados en el directorio
de trabajo o en el área de preparación.

…:~$ git checkout master ==> HEAD -> master

…:~$ Switched to branch master

Creamos rama hotfix para trabajar en la resolución del nuevo problema:

…:~$ git checkout -b hotfix

Switched to a new branch "hotfix"
…:~$ vi index.html
…:~$ git commit -a -m “Fixed the Broken Email Address”
[hotfix]: created 3a0874c: "Fixed the Broken Email Address"
1 files changed, 0 insertions(+), 1 deletions(-)

Para incorporar cambios en la rama master y ponerlos en producción, usamos:

…:~$ git checkout master ==> me sitúo en la rama master

…:~$ git merge hotfix ==> une mi rama actual (master) con la rama deseada (hotfix)

Esto es un

FAST FORWARD
Tras la fusión, la rama master
apunta al mismo sitio que la
rama hotfix.

18
Ahora podemos volver al trabajo donde estábamos (issue #53), pero antes, borraremos la rama
hotfix puesto que no la vamos a necesitar más:

…:~$ git branch -d hotfix ==> Elimina rama hotfix

Deleted branch hotfix (3a0874c)

Y regresamos sobre el problema #53:

…:~$ git checkout iss53

Switched to branch "iss53"
…:~$ vi index.html
…:~$ git commit -a -m “Finished the New Footer [issue 53]'
[iss53]: created ad82d7a: "Finished the New Footer [issue 53]"
1 files changed, 1 insertions(+), 0 deletions(-)

• Procedimientos de Fusión

Suponemos que el problema #53 ya está solucionado y queremos fusionarlo con la rama
master.

…:~$ git checkout master

…:~$ git merge iss53
Merge made by recursive.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

Esta fusión es diferente a la realizada con hotfix, puesto que la confirmación en la rama actual
no es ancestro directo de la rama que pretendemos fusionar. Git hará una fusión a 3 bandas.

19


Nos referimos a este proceso como “Fusión Confirmada”.

Git crea automáticamente una nueva confirmación para la fusión:

Ahora que todo el trabajo está fusionado con la rama principal, ya podemos borrar la rama
iss53:

…:~$ git branch -d iss53

20
• Problemas en las Fusiones

Si hay modificaciones dispares en una porción de un mismo archivo en las dos ramas que se
quieren fusionar, Git no será capaz de fusionarlas directamente.

Ej: #53 ==> index.html hotfix ==> index.html

…:~$ git checkout master

…:~$ git merge iss53
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Git no crea la fusión confirmada (commit del merge) sino que hace una pausa en el proceso,
esperando a que tu resuelvas el problema. Para verlo:

…:~$ git status

index.html: needs merge
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# unmerged: index.html
#

Todo lo que no se ha podido resolver se marca como “unmerged”. Git añade a los archivos
conflictivos unas marcas especias de resolución de conflictos:

<<<<<<< HEAD:index.html
<div id="footer">contact : [email protected]</div>
=======
<div id="footer">
please contact us at [email protected]
</div>
>>>>>>> iss53:index.html

Nos dice que la version HEAD (master) contiene lo indicado antes de (====) y la versión iss53
el resto. Podemos quedarnos solo con una de las dos partes (la del iss53 por ejemplo):

Tras solucionarlo:

…:~$ git status

# On branch master Ahora al hacer git commit
# Changes to be committed: confirmamos la fusión
# (use "git reset HEAD <file>..." to unstage)
#
# modified: index.html
# 21
Para ver la última confirmación de cambios en cada rama:

…:~$ git branch -v

iss53 93b412c fix javascript issue
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes

…:~$ git branch --merged ==> muestra las ramas que han sido fusionadas
iss53
* master

…:~$ git branch --no-merged ==> muestra las ramas que no han sido fusionadas
testing

Si hacemos git branch -d testing no nos deja porque tenemos trabajos sin fusionar, entonces:

…:~$ git branch -D testing ==> fuerza el borrado

Ejemplo múltiples ramificaciones:

22
RAMAS REMOTAS

Las ramas remotas son referencias al estado de ramas en tus repositorios remotos.

- No se pueden mover

- Se mueven cuando estableces comunicaciones en la red

- Funcionan como marcadores que te recuerdan en qué estado estaban tus repositorios la última
vez que conectaste con ellos.

Supongamos:

Un clone de Git proporciona una rama master y otra rama origin/master apuntando a la
rama master original.

23
Si trabajamos en la rama master local y alguien más lleva su trabajo (push) al servidor, los
registros avanzan de forma diferente. Además, el apuntador a la rama origin/master no se
moverá.

Para sincronizarnos:

…:~$ git fetch origin ==> Descarga cualquier dato presente en el servidor que no
tengamos y actualiza la base de datos local, moviendo la rama origin/master

24
Imaginamos que tenemos otro servidor al que nos conectamos haciendo una referencia remota
git remote add:

Ahora usamos el comando git fetch teamone para descargar todo lo que no tenemos:

25
Para publicar los cambios que yo he hecho en local

git push (remoto) (rama)

…:~$ git push origin master ==> las ramas deben de estar sincronizadas

Imaginemos que estoy trabajando en una rama desarrollo y la publico:

…:~$ git push origin desarrollo

Counting objects: 20, done.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 1.74 KiB, done.
Total 15 (delta 5), reused 0 (delta 0)
To [email protected]:schacon/simplegit.git
* [new branch] desarrollo -> desarrollo

…:~$ git push origin desarrollo:develope ==> lleva la rama local (desarrollo con otro
nombre al remoto (develope)

Ahora, cuando los colaboradores recuperen del servidor:

…:~$ git fetch origin

remote: Counting objects: 20, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 15 (delta 5), reused 0 (delta 0)
Unpacking objects: 100% (15/15), done.
From [email protected]:schacon/simplegit
* [new branch] desarrollo -> origin/desarrollo

Obtendrán un puntero no editable a origin/desarrollo

Para integrar esto en su actual rama de trabajo, deben crear una rama basándose en la rama
remota:

…:~$ git checkout -b desarrollo origin/desarrollo

Esto les da una rama local donde pueden trabajar, comenzando donde origin/desarrollo estaba en
ese momento.

Para borrar una rama remota:

git push [nombre_remoto] :[rama_remota]

…:~$ git push origin :desarrollo ==> Desaparece la rama desarrollo en el servidor

26
REORGANIZACIÓN

Ej:

Integramos ambas ramas con una fusión confirmada:

…:~$ git checkout master

…:~$ git merge experiment

27
Podemos integrar las ramas de forma diferente:

…:~$ git checkout experiment

…:~$ git rebase master

Esto hace que vaya al ancestro común de ambas ramas, saca sus diferencias y las guarda en
archivos temporales, reinicie la rama actual hasta llevarla a la misma confirmación en la rama de
donde queremos reorganizar y finalmente, aplica ordenadamente los cambios

Y ahora podemos hacer un Fast Forward:

C3’ es lo mismo que la C5 de la fusión confirmada. No hay ninguna diferencia en el resultado final
de la integración, pero el haberla hecho reorganizando nos deja un registro más claro. Si
examinas el registro de una rama reorganizada, este aparece siempre como un registro lineal:
como si todo el trabajo se hubiera realizado en series, aunque realmente se haya hecho en
paralelo.

Aplicaremos esta vía cuando queramos estar seguros de que nuestras confirmaciones se pueden
aplicar limpiamente sobre una rama remota (proyectos como colaborador). En casos como esos,
puedes trabajar sobre una rama y luego reorgainzar lo realizado en la rama origin/master cuando
lo tengas todo listo para enviarlo al proyecto principal. De esta forma, la persona que mantiene el
proyecto no necesitará hacer ninguna integración con tu trabajo; le bastará con un avance rápido
o una incorporación limpia.

28
Otro ejemplo:

Ramificamos de forma puntual la rama server, añadimos funcionalidades al proyecto y luego

volvemos a la rama original para hacer otros cambios en la rama cliente. Por último, volvemos
a la rama server y hacemos varios cambios más.

Ahora decidimos incorporar los cambios de la parte del cliente sobre el proyecto principal, pero
no queremos lanzar aún los cambios de la parte server porque no están suficientemente
probados.

Podemos coger los cambios del cliente que no estén en server y replicarlos sobre la rama
principal:

…:~$ git rebase --onto master server client ==> Activa la rama client, averigua
los cambios desde el ancestro común entre las ramas client y server, y los aplicamos en la
rama master

29
Avanzamos a la rama principal:

…:~$ git checkout master

…:~$ git merge client

Ahora decidimos traerlos también sobre la rama server. Lo haremos sin necesidad de
comprobarlo previamente usando el comando git rebase [rama_base] [rama_puntual]. El
cual activa la rama server y la aplica sobre la rama master (en este caso)

…:~$ git rebase master server

…:~$ git checkout master …:~$ git branch -d client

…:~$ git merge server …:~$ git branch -d server

30
SSH

SSH es probablemente el protocolo más habitual para Git. Debido a disponibilidad en la mayor
parte de los servidores; (si no estuviera disponible, además es sencillo habilitarlo). Por otro lado,
SSH es el único protocolo de red con el que puedes fácilmente tanto leer como escribir. Los otros
dos protocolos de red (HTTP y Git) suelen ser normalmente protocolos de solo-lectura; de tal
forma que, aunque los tengas disponibles para el público en general, sigues necesitando SSH
para tu propio uso en escritura. 

Por defecto, las claves de cualquier usuario SSH se guardan en la carpeta ~/.ssh de dicho
usuario. Puedes verificar si tienes ya unas claves, simplemente situandote sobre dicha carpeta y
viendo su contenido. Si no, crearla (mkdir ~/.ssh)

…:~$ cd ~/.ssh
…:~$ ls

El fichero .pub es nuestra clave pública. Si no existen debemos usar:

…:~$ ssh-keygen -t rsa

Responder a todas las
preguntas con tecla
Enter

Tras generarla, cada usuario ha de encargarse de enviar su clave pública a quienquiera que
administre el servidor Git. La clave pública será una serie de números, letras y signos, algo así
como esto:

…:~$ cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU
GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3
Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA
t3FaoJoAsncM1Q9x5+3V0Ww68/eIFmb1zuUFljQJKprrX88XypNDvjYNby6vw/Pb0rwert/En
mZ+AW4OZPnTPI89ZPmVMLuayrD2cE86Z/il8b+gw3r3+1nKatmIkjn2so1d01QraTlMqVSsbx
NrRFi9wrf+M7Q== [email protected]

Una vez hecho, debemos añadir nuestra clave pública (copiar cat ~/.ssh/id_rsa.pub | pbcopy y
pegar el texto que muestra el cat) a GitHub:

1. Icono de usuario (parte derecha)

2. Settings

3. SSH and GPG keys

4. New SSH key

5. Pegar el contenido del id_rsa.pub (situado en /home/user/.ssh)

6. Add SSH key

31
• Otros comandos

…:~$ git --version ==> Muestra la version de Git instalada

…:~$ git log --pretty=oneline ==> Muestra la salida formateada (Sin fecha ni autor)

…:~$ git show ==> Muestra información del último commit en la rama actual (equivalente a
git show HEAD) ==> git show HEAD~1 muestra el penúltimo, HEAD~2 el atepenúltimo…

…:~$ git log --graph --abbrev-commit --decorate ==> Muestre las confirmaciones
realizadas en el repositorio hasta el momento (commit abreviado y línea tipo grafo)

…:~$ git log --oneline --decorate --date=relative --all ==>Muestra en una

línea las confirmaciones realizadas en el repositorio hasta el momento (incluso las borradas)

…:~$ git log --oneline ==> Muestra los commits en una línea y abreviado

git pull [rama_remota] [rama_local]

…:~$ git pull origin master

Es básicamente una combinación de los comandos git fetch y git merge, donde Git
descargará desde el repositorio remoto especificado y a continuación, de forma inmediata
intentará combinarlo en la rama en la que te encuentres.

• Volver a un commit anterior

Primero debemos copiar el hash (número de confirmación) del commit al que queramos ir. Basta
con copiar los 7 primeros. Nos lo dará el comando git log --oneline:

…:~$ git log

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon <[email protected]>
Date: Sat Mar 15 16:40:33 2008 -0700

Removido código de prueba innecesario

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon <[email protected]>
Date: Sat Mar 15 10:31:28 2008 -0700

Primera confirmación

…:~$ git checkout a11bef0
 Ahora estamos en el commit anterior, y tenemos acceso
a manipular sus ficheros y directorios
Para volver al último commit, simplemente situarnos en la última rama:


…:~$ git branch

…:~$ git checkout master

32
• Volver a un commit/versión anterior (GitHub)

- Para volver a una versión anterior de nuestro proyecto debemos situarnos primero en el
repositorio del proyecto.

- Una vez en nuestro repositorio debemos entrar en la pestaña de los commits que hemos
realizado

- Cuando estemos en la lista de confirmaciones (commits) podemos:

Copiar el Código Hash

(número confirmación)
Ver las modificaciones

Acceder al código
de dicha versión

33