Skip to content

Commit

Permalink
Merge pull request #14 from craftsmanship-toledo/dev
Browse files Browse the repository at this point in the history
Merge dev to master to new release 0.1.0
  • Loading branch information
javierlopezdeancos committed Nov 26, 2015
2 parents 971aba5 + d449bca commit 5c1f9d9
Show file tree
Hide file tree
Showing 19 changed files with 735 additions and 0 deletions.
42 changes: 42 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# CURSO DE GIT - craftsmanship Toledo


### [Ejercicio 0 - Iniciar un proyecto git/git init/git clone/fork](ejercicios/zero/cero.md)

Cómo empezar una proyecto git, iniciar desde local o clonar un repositorio existente y en nuestro local. También hablaremos de cómo podemos usar extras, como forkear un repositorio con la interfaz de github para vitaminar nuestro workflow.

### [Ejercicio 1 - Uso de stage/commit/push](ejercicios/uno/uno.md)

Primera modificación de nuestro código, commit y subida al repositorio. Veremos qué es el stage y los diferentes estados que pasa un fichero desde que se añade al repositorio, modifica y acaba en el repositorio remoto.

### [Ejercicio 2 - Uso de pull/fecth, como mantener actualizados mis cambios](ejercicios/dos/dos.md)

Primera bajada de código del repositorio remoto, en principio haremos una sincronización sencilla sin conflictos o con rebase.

### [Ejercicio 3 - Gestión de ramas Locales/Remotas](ejercicios/tres/tres.md)

Crear una rama, cambio de ramas, listar ramas, saber en qué rama estamos trabajando, trackear una rama de un repositorio remoto

### [Ejercicio 4 - Gestión de repositorios remotos](ejercicios/cuatro/cuatro.md)

Gestión de repositorios remotos, el origin no lo es todo, git es un sistema de control de versiones distribuido, aprovechemos su potencia. Añadir, modificar , remover punteros remotos para poder hacer push/pull de cualquiera de ellos en cualquier momento que para el workflow de trabajo sea interesante.

### [Ejercicio 5 - ¿Qué es y para qué usar el stash?](ejercicios/cinco/cinco.md)

El stash, esa pila que nos puede ayudar en multitud de operaciones. Saber identificar los casos mas comunes en los que nos ayudaria, añadir a a pila nuestros cambios, sacar y aplicar de la pila nuestros cambios cuando estemos posicionados donde necesitamos etc.

### [Ejercicio 6 - Volver para atrás tus cambios](ejercicios/seis/seis.md)

Vale, me he equivocado añadiendo al stage un fichero, o me he equivocado commiteando un fichero que no quiero añadir en mi push, ¿Qué debo hacer? Aprenderemos a revisar el log y mover el puntero del estado de cada fichero, a quitarlo del stage, a resetear su estado.

### [Ejercicio 7 - Rebase y rebase interactivo](ejercicios/siete/siete.md)

Una de las cosas más importantes para un buen flujo de trabajo es conocer toda la potencia que git nos pone a nuestro alcance, dos de las más potentes son el rebase y el rebase interactivo, aprenderemos qué es, por qué se usa y cuándo es el momento en el flujo para hacerlo.

### [Ejercicio 8 - El merge y el mergetool](ejercicios/ocho/ocho.md)

Vale la cosa ha ido mal, es normal, tengo conflictos al actualizarme en algún fichero, tengo que mergear, aprenderemos como hacerlo, usar herramientas gráficas y como configurarlas.

### [Ejercicio 9 - Referencias y enlaces de interés](ejercicios/nueve/nueve.md)

Urls de manuales, documentación oficial.
64 changes: 64 additions & 0 deletions ejercicios/cinco/cinco.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,64 @@
# Ejercicio 5

## ¿Qué es y para qué usar el stash?

Stashing es un concepto super simple que es increíblemente útil y muy fácil de usar. Si estamos trabajando en nuestro código y necesitamos cambiar a otra rama por cualquier motivo o quizás al actualizar con un pull en el repositorio, y no queremos hacer un commit de nuestro trabajo porque se encuentra en un estado parcial, podemos usar stashing.

### Ver qué tenemos en el stash

```
$ git stash list
```

### Ver qué tenemos en el stash y en qué consisten sus cambios

```
$ git stash show stash@{#}
```

```
$ git stash show stash@{0}
http_request.py | 1 +
inform.py | 1 +
status.py | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
```

### Ver las diferencias de nuestros cambios en el stash

Podemos ver las diferencias de nuestros cambios que tenemos guardados en una posición de la pila del stash de la siguiente forma.

```
$ git diff stash@{0}
```

### Guardar cambios en el stash

Podemos guardar nuestros cambios en la pila del stash con el siguiente comando:

```
$ git stash
```

### Aplicar cambios del stash

Podemos aplicar los cambios del stash de la posición de la pila que queramos, en este ejemplo 0:

```
$ git stash apply stash@{0}
```

Un atajo que podemos utilizar para aplicar la primera posición de la pila del stash es el siguiente comando:

```
$ git stash pop
```
que utiliza la operación `pop` de la pila para sacar los cambios correspondientes, aplicándolos al proyecto.

### Limpiar el stash

Podemos limpiar toda la pila del stash con el siguiente comando:

```
$ git stash clear
```
Empty file added ejercicios/cinco/cinco.txt
Empty file.
65 changes: 65 additions & 0 deletions ejercicios/cuatro/cuatro.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# Ejercicio 4

## Gestión de repositorios remotos

Ya hemos comentado en anteriores capítulos que podemos enlazar a nuestro repositorio git cualquier proyecto git remoto o local.

Al hacer un clone de un proyecto, por defecto git nos enlaza automáticamente el repositorio del cual estamos clonando en nuestro local como el remoto `origin` por defecto.

### Listar los repositorios enlazados a nuestro repositorio local

Podemos listar los repositorios enlazados en nuestro repositorio local de la siguiente forma:

```
$ git remote
```
Tendríamos algo parecido a esto

```
$ git remote
desarrolladorPablo
origin
zero
```

Como véis tendríamos tres repositorios enlazados, `origin`, el repositorio de nuestro fork del cual hemos clonado nuestra copia en local, lo hace automáticamente git, el `zero`, que es un alias que ponemos para enlazar el repositorio central del cual hicimos nuestro fork y en el que, al final, todos iremos pasando nuestro código de nuestros forks y el `desarrolladorPablo`, que es un enlace al fork que el desarrollador Pablo hizo del repositorio central, del cual nos podremos traer cambios antes de que sean mergeados con este repositorio central.

Podréis entender ahora la potencia de git, podemos traer o empujar cambios a cualquiera de esos repositorios o los que vayamos añadiendo.

Esto permite una enorme flexibilidad a la hora de tener un buen workflow, probar features en las que varios desarrolladores esten haciendo cada uno distintas partes, o simplemente que la feature de un desarrollador dependa de otra feature que está desarrollando otro desarrollador.

También podemos hacer un listado más completo, con las urls a las cuales estan asociados los atajos origin, zero etc...

```
$ git remote -v
desarrolladorPablo [email protected]:pablo/curso-de-git.git (fetch)
desarrolladorPablo [email protected]:pablo/curso-de-git.git (push)
origin [email protected]:javierlopezdeancos/curso-de-git.git (fetch)
origin [email protected]:javierlopezdeancos/curso-de-git.git (push)
zero [email protected]:craftsmanship-toledo/curso-de-git.git (fetch)
zero [email protected]:craftsmanship-toledo/curso-de-git.git (push)
```

### Enlazar con un shortcurt un repositorio remoto

```
$ git remote add luis [email protected]:luis/curso-de-git.git
```

### Borrar un shortcurt enlazado a un repositorio remoto

```
$ git remote remove luis
```

### Cambiar un shortcut de un repositorio remoto enlazado

```
$ git remote rename viejoLuis nuevoLuis
```

### Cambiar el enlace a un shortcut que ya hemos añadido

```
git remote set-url desarrolladorPablo [email protected]:pabloNuevo/curso-de-git.git
```
Empty file added ejercicios/cuatro/cuatro.txt
Empty file.
46 changes: 46 additions & 0 deletions ejercicios/dos/dos.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Ejercicio 2

## Uso de fecth/merge/pull, como mantener actualizados mis cambios

Cuando trabajamos en equipo, necesitamos tener actualizados nuestro repositorio en la rama en la que estemos trabajando para evitar tener muchos conflictos al final de nuestro desarrollo, es mucho más sencillo actualizar poco a poco los cambios que los demás desarrolladores están mergeando en la rama **dev** para así poder resolver los conflictos (si los tuviésemos) de una manera mucho más trivial: divide y vencerás.

### fecth

Podemos usar el comando **fecth**. Con este comando podremos traermos los cambios de otros desarrolladores de cualquier repositorio enlazado a nuestro repositorio local en la rama que necesitemos por ejemplo:

```
$ git fecth zero dev
```

En el ejemplo nos estamos trayendo los cambios del repositorio del que hicimos el *fork*, que lo hemos enlazado con el pseudónimo zero en su rama *dev*. En teoría, los desarrolladores deberían mergear el código de sus forks a este repositorio centralizado del que todos hemos ido haciendo nuestros propios forks y después clonándolos en una copia en local.

Sobre cómo enlazar repositorios a nuestro repositorio local lo trataremos en el [ejercicio 4, gestión de repositorios remotos](../cuatro/cuatro.md).

De la misma forma, podemos traernos cambios de cualquier repositorio enlazado, en cualquiera de sus ramas.

### merge

Podemos usar el comando **merge**. Con este comando podremos mezclar los cambios de otros desarrolladores con los nuestros, por ejemplo:

```
$ git checkout ramaA
$ proyecto - ramaA > git merge ramaB
```

En este ejemplo estamos cambiandonos de rama, a la rama `ramaA` y estamos mezclando la rama `ramaB` en ella.

### pull

Podemos usar el comando **pull**. Con este comando podremos traermos los cambios de otros desarrolladores de cualquier repositorio enlazado a nuestro repositorio local en la rama que necesitemos y mezclarlos con nuestros cambios, por ejemplo:

```
$ git pull zero dev
```
Notemos entonces que el **pull es un fetch más un merge** en la misma operación.

Es posible que al traernos estos cambios podamos tener conflictos en nuestros cambios y los de otros desarrolladores. Esto se debe a que ambos abrimos rama en el mismo punto en la rama dev, con lo cual, el merge automático no sabe exactamente con qué cambio de cuál commit quedarse, ya que ninguno en principio estaría por encima del otro.

Cuando tenemos esta situación tendremos que hacer un merge manual, normalmente con una herramienta configurada para ello, pero esto lo veremos en el [capítulo 8 - El merge y el mergetool](../ocho/ocho.md).
Empty file added ejercicios/dos/dos.txt
Empty file.
31 changes: 31 additions & 0 deletions ejercicios/nueve/nueve.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
# Ejericio 9

## Referencias y enlaces de interés

### Documentacion

[Documentation oficial](http://git-scm.com/book/en/v2)

[Pro git book spanish](http://git-scm.com/book/es/v2)

[A git guide example](http://rogerdudler.github.io/git-guide/)

### Tutorials

[git immersion tutorial](http://gitimmersion.com/)

[Atlassian git tutorial](https://es.atlassian.com/git/tutorials/setting-up-a-repository)

[Recetas de git](http://firstaidgit.io/#/)

### Herramientas de ayuda en el shell

[Bash git prompt](https://github.com/magicmonty/bash-git-prompt)

[Oh my git](https://github.com/arialdomartini/oh-my-git)

### Herramientas gráficas

[Sourcetree](https://www.sourcetreeapp.com/)

[giHub Desktop](https://desktop.github.com/)
66 changes: 66 additions & 0 deletions ejercicios/ocho/ocho.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# Ejercicio 8

## El merge y el mergetool

Vale tenemos conflictos, el merge automático no funciona y debemos mergear manualmente.

### Lanzar el mergetool

Cuando existe algún conflicto, git nos lo informa en consola, nosotros simplemente tendremos que resolverlo con el mergetool que tengamos configurado y salvarlo

```
$ git mergetool
```

### Configurar el mergetool

En git podemos poner cualquier herramienta de merge manual que queramos, tan solo tenemos que configurarla, las hay de muy diferentes tipo, consola, gráficas, libres, de pago, incluso se puede mergear con un simple editor de texto, aunque la experiencia no sea muy agradable y aconsejable para los que esteis empezando. Os enseñamos en este ejemplo a configurar para mac una herramienta gratuita [p4merge](http://www.perforce.com/perforce/products/merge.html), aunque tenéis de todo tipo y cada una de ellas de una manera u otra hay algún manual que explica como configurarla para que sea vuestro mergetool por default.

1. Descargar p4merge e instalarlo
2. Crear Scripts para ejecutar p4merge

Crear un nuevo fichero de texto en **/usr/local/bin** llamado p4merge con el contenido:

```
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
```
3. Hacer el script ejecutable

```
chmod +x p4merge
p4diff*
Create a new text file in /usr/local/bin called p4diff and add the following lines:
```

4. Configurar git para usar este script:

Abrir el fichero de configuración de git con un editor, probablemente en **~/.gitconig** y añadir estas líneas:

```
[merge]
keepBackup = false;
tool = p4merge
[mergetool "p4merge"]
cmd = p4merge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
keepTemporaries = false
trustExitCode = false
keepBackup = false
[diff]
external = p4diff
```

### Mergear una rama manualmente contra otra

A veces queremos hacer un proceso de merge manual, no tiene que ver con traernos cambios con un fetch, simplemente por algunas razones queremos mergear una rama contra otra, para ello:

1. Vamos a la ramaA en la que quiero mergear los cambios de la ramaB

```
$ git checkout ramaA
```
2. Una vez posicionados nos traemos los cambios de la ramaB para mergearlos con la rama en la que estamos posicionados, en este caso la ramaA

```
$ git git merge --no-ff
```
Empty file added ejercicios/ocho/ocho.txt
Empty file.
Loading

0 comments on commit 5c1f9d9

Please sign in to comment.