Git práctico

practical-git.md

Git práctico

Conceptos clave

Antes de empezar a soltar comandos como un bellaco, hay que explicar los conceptos clave que se necesitan conocer para trabajar con Git.

Comenzaremos con los diferentes estadios en los que puede encontrarse nuestro código (nuestros cambios sobre el contenido de los ficheros, en realidad).

1. Workspace: Es el estado real de nuestros ficheros. Tal y como los vemos en nuestro editor.
2. Stage: Aquí se encuentran los cambios sobre nuestros ficheros que se incluirán en el próximo commit. Cuando hacemos un git add, un git rm o un git mv, estamos introduciendo cambios en el stage, indicándole a Git que en el próximo commit esos cambios irán incluidos.
3. Commits (locales): Cada commit es un grupo de cambios sobre uno o varios ficheros, con una descripción, una fecha, un autor, etc. La gran diferencia con SVN es que los commits en Git son locales hasta que no se efectúa la subida al servidor. Estos commits locales (importante que sean locales) pueden ser modificados sin peligro (con modificados quiero decir que se les pueden añadir más cambios, actualizar su mensaje o incluso eliminarlos).
4. Commits (remotos): Cuando se suben cambios al servidor (o como se le llama en Git: el remoto), se considera que estos entran a formar parte del histórico compartido entre los desarrolladores del proyecto y, por lo tanto, no es buena práctica modificarlos del mismo modo en que se hace cuando los commits son locales (además hacerlo puede provocar importantes quebraderos de cabeza).

En resumen, el flow de trabajo con Git es:

1. Hago cambios en mis ficheros (workspace)
2. Añado al stage los cambios que quiero commitear
3. Hago el commit
4. Subo los cambios al remoto

Instalar plugin de Eclipse

Para trabajar con Git desde Eclipse podemos hacer uso del plugin Egit, que nos ofrece una interfaz gráfica integrada con el IDE desde la cual podemos hacer todas nuestras operaciones para gestionar el control de versiones de nuestros proyectos.

Para instalar el plugin Egit, añadiremos su URL de instalación a la lista de "Available Software Sites" situada en el menú "Help > Install New Software" de Eclipse. Una vez añadida, la seleccionamos de la lista, y elegimos los dos paquetes que necesitamos instalar:

• Eclipse Git Team Provider
• JGit

Una vez instalados y reiniciado Eclipse, ya tendremos disponible Egit en nuestro IDE.

Trabajando con Git

Clonar repositorios

Para bajarse un proyecto de un repositorio existente, necesitamos la URL de ese repositorio. Una vez la tengamos (y nos hayan dado los permisos pertinentes), podemos descargarlo con:

$ cd ~/dev/
$ git clone https://github.com/twbs/bootstrap.git
$ cd bootstrap/

Como veis, por defecto git clone nos mete el proyecto en un directorio con el nombre del repositorio. Si preferimos indicarle el nombre del directorio donde lo queremos meter, podemos hacer:

$ cd ~/dev/
$ mkdir my-awesome-bootstrap/
$ git clone https://github.com/twbs/bootstrap.git my-awesome-bootstrap
$ cd my-awesome-bootstrap/

Clonar desde Eclipse con Egit

Para clonar un repositorio desde Egit, accedemos a la vista "Git Repositories" y seleccionamos la opción "Clone a Git repository".

Cumplimentamos los datos correspondientes al repositorio que necesitamos clonar y seguimos los pasos del wizard.

Una vez clonado, nos aparecerá en la lista de la vista "Git repositories". Si queremos importarlo como projecto, podemos hacerlo seleccionado la opción "Import projects" al hacer click derecho encima del repositorio que deseamos importar.

Añadir un servidor a un repositorio local existente

A veces creamos un repositorio local (con git init) y no lo tenemos asociado a un repositorio remoto, por lo que no podremos hacer git push para subir cambios ya que no hay sitio donde hacerlo.

Si nos dan más adelante una URL para subir nuestro repositorio local a un repositorio remoto, podemos añadirlo como remote usando:

$ git remote add origin https://github.com/twbs/bootstrap.git

Con esto creamos un remote llamado origin, asociado a la URL que le hemos pasado.

Para ver los remotes que tiene nuestro repositorio, podemos:

$ git remote -v
origin https://github.com/twbs/bootstrap.git (fetch)
origin https://github.com/twbs/bootstrap.git (push)

Ver el estado de nuestro stage y workspace

Un comando que se usa muy a menudo es git status, con el que obtenemos información sobre el estado de nuestro stage y nuestro workspace. Es decir, información sobre qué tenemos añadido para formar parte del próximo commit, qué no, qué ficheros son nuevos en el sistema y Git aún no conoce, etc.

Cuando ejecutamos git status, se nos mostrará algo como:

$ git status
On branch master

Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    file-deleted.txt
        modified:   file2-modified.txt

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   file1-modified.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        new-file.txt

Cada sección indica en qué estado están los cambios de nuestro workspace con respecto al stage.

• Changes to be commited: Esta sección muestra los cambios añadidos al stage, es decir, los que formarán parte del próximo commit. Junto a cada fichero se muestra qué se ha hecho con él: modified, deleted, added…
• Changes not staged for commit: En esta sección se muestran los cambios que se han hecho sobre nuestros ficheros, pero que no han sido añadidos al stage y por tanto no formarán parte del próximo commit. Al igual que en la sección anterior, se muestra el tipo de cambio que se ha hecho sobre cada fichero: modified, deleted, added…
• Untracked files: Aquí se ven los ficheros que están en nuestro workspace de los que Git no tiene conocimiento aún. Es decir, no forman parte del control de versiones y por tanto, lógicamente, no formarán parte del próximo commit.

Si leemos atentamente el resultado de git status, podemos ver que se nos ofrecen consejos sobre qué hacer con cada fichero en cada sección:

En Changes to be commited nos dice:

use "git reset HEAD <file>..." to unstage

Es decir, si queremos hacer unstage (sacar del stage) de los cambios sobre file2-modified.txt, debemos ejecutar git reset HEAD file2-modified.txt.

Una vez que estamos familiarizados con Git, el output de git status es demasiado grande, con más información de la que realmente se necesita. Podemos mostrar algo más reducido con:

$ git status -sb
M  file1.txt
D  file2.txt
?? file3.txt

De esta manera, podemos ver de manera directa y clara en qué estado está cada fichero (M para modificados, D para eliminados, ?? para ficheros no trackeados…). Y el color de esas letras nos indica si está en el stage (verde) o no (rojo).

Trabajar con ramas

Una de las características más potentes de Git son las ramas. Gracias a ellas podemos encapsular nuestro trabajo y mantenerlo separado de la línea de desarrollo principal, pudiendo trabajar sin problemas de actualización de código hasta la hora en que hayamos terminado. Esto, además, nos permite cambiar rápidamente de tarea sin que el código a medio terminar nos afecte.

Listar ramas

Para listar las ramas existentes en nuestro repositorio, usaremos:

$ git branch
* master
  dev

Esto nos mostrará únicamente las ramas locales, marcando con un asterisco la rama en la que nos encontremos en ese momento. Si queremos ver además las ramas remotas, podemos hacerlo con:

$ git branch -a
* master
  dev
  remotes/origin/master
  remotes/origin/dev

Para mostrar algo de información sobre las ramas, como por ejemplo el último commit que hay en cada una de ellas:

$ git branch -va
* master                  bed4c52 Sample commit
  dev                     bd81885 Another commit
  remotes/origin/master   bed4c52 Sample commit
  remotes/origin/dev      bed4c52 Sample commit

Crear ramas

Para crear una nueva rama en nuestro repositorio, y además movernos a ella, usaremos:

$ git checkout -b my-branch

Es muy importante saber que la nueva rama que estamos creando estará basada en la rama en la que nos encontremos en ese momento. Es decir, si nos encontramos en master, cuyo último commit es el bed4c52, la rama my-branch recién creada será una copia de master, con ese mismo commit como último.

También hay que tener en cuenta que al crear nuevas ramas, los cambios sobre el workspace y sobre el stage que tengamos en ese momento se mantienen.

Crear una rama local a partir de una rama remota

Hay ocasiones en las que nos interesa crear una nueva rama local basándonos en el contenido de una rama remota en lugar de el contenido de la rama en la que nos encontremos en ese momento (que como se ha explicado en el punto anterior, es el comportamiento por defecto).

Para este fin, haremos lo siguiente:

$ git fetch
$ git checkout -b my-branch origin/my-branch

Lo primero ha sido actualizar nuestras referencias a las ramas remotas usando git fetch, para así tener los últimos cambios del servidor disponibles en dichas referencias.

A partir de ahí ya podemos crear la rama con el comando mencionado, en el cual my-branch es el nombre de la rama local que queremos crear y origin/my-branch es el nombre de la referencia a la rama remota en la que queremos basarnos para crear nuestra rama local.

Movernos entre ramas

Para movernos entre ramas tan sólo tenemos que usar:

$ git checkout another-branch

Es importante tener en cuenta que al movernos entre ramas, los cambios sobre el workspace y sobre el stage que tengamos en ese momento se mantienen, salvo que se vean afectados por el estado de la rama destino. Es decir, si la rama a la que vamos afecta (entra en conflicto) a los cambios que tengamos en nuestro workspace o stage, no se realizará el cambio de rama.

Para poder hacerlo tendremos que limpiar el workspace y el stage antes de movernos de rama. Para ello podemos seguir dos estrategias diferentes:

• Hacer un commit de todos los cambios: No es lo recomendado, ya que estaremos haciendo un commit con algo que, presumiblemente, aún no está terminado.
• Meter los cambios en el stash: Guardamos los cambios en el stash para sacarlos posteriormente (aún no hemos hablado del stash, pero lo haremos pronto).

Con cualquiera de estas dos estrategias, limpiaremos nuestro stage y workspace y podremos movernos de rama sin problemas.

Eliminar ramas

Para eliminar una rama, usaremos:

$ git branch -D my-branch

Trabajar con ramas desde Eclipse

Para trabajar con ramas desde el plugin Egit para Eclipse, podemos usar la sección "Branches" dentro de la información del repositorio en la vista "Git repositories".

Esta sección está dividida en dos partes: "Local" y "Remote tracking".

La primera corresponde con las ramas locales que están disponibles en nuestro repositorio clonado.

La segunda corresponde con las ramas remotas, las que están subidas al servidor.

Desde aquí podemos cambiar fácilmente entre ramas haciendo doble click sobre la que necesitemos.

Mostrar el histórico de commits

Para mostrar un listado con los commits de la rama en la que estemos en ese momento, debemos usar git log:

$ git log
commit bed4c52fedbb1faf9989e2410b5f0726d24c7e9c
Author: Juan G. Hurtado <[email protected]>
Date:   Thu Jul 10 13:31:28 2014 +0200

    Update FormPreview styles to match Builder

commit 4de89ea88baad0169bc49d69041fb68095e27c21
Author: Juan G. Hurtado <[email protected]>
Date:   Wed Jul 9 12:28:44 2014 +0200

    Remove unwanted attrs from Items on creation

commit d818852126e890394612ce5509fb9d5f679f7ff0
Author: Juan G. Hurtado <[email protected]>
Date:   Wed Jul 9 12:05:59 2014 +0200

    Version bump: v0.0.3

Como podéis ver, se muestra un listado con todos los commits de la rama en la que estamos, ordenado cronológicamente, con los más actuales arriba.

Por cada commit se muestra su identificador, el autor, la fecha en la que se hizo y el mensaje que se le dió.

La manera por defecto con la que git log muestra el histórico de commits no me parece la más cómoda. Personalmente prefiero:

* bed4c52 - (HEAD, master, dev) Update FormPreview styles to match Builder (2 days ago) <Juan G. Hurtado>
* 4de89ea - Remove unwanted attrs from Items on creation (3 days ago) <Juan G. Hurtado>
* d818852 - (tag: v0.0.3, origin/master) Version bump: v0.0.3 (2 weeks ago) <Juan G. Hurtado>

Para conseguirlo sólo hay que escribir el siguiente comando:

$ git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

Mucho mejor, ¿verdad? Y mucho más cómodo…

Vale, vale, es broma. Para poder usar cómodamente este comando para mostrar el histórico de commits podéis crear un alias de la siguiente forma:

$ git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"

Y a partir de ahí usar git lg para ver el histórico.

Ver el histórico de commits desde Eclipse

Para ver el log de commits, seleccionaremos la opción "Show in history" dentro de la sección "Team" que aparece al hacer click derecho sobre nuestro proyecto en Eclipse.

Añadir cambios al stage

Una vez hemos editado nuestros ficheros, podemos añadir los cambios al stage usando:

$ git add .
$ git add file1.txt file2.js file3.html

Si lo que queremos es mover ficheros, podemos hacerlo directamente desde Git:

$ git mv file.txt renamed.txt
$ git mv file.txt other/folder/

Pero lo normal es que lo hagamos desde nuestro editor, o desde el explorador de ficheros del sistema operativo. Si lo hacemos así, Git no sabrá cuál era el nombre antiguo del fichero y cuál es el nuevo (o cuál era la ruta antigua y cuál es la nueva). Pensará que hay un fichero nuevo en el sistema (el nombre o ruta nueva), y uno que hemos eliminado (el nombre o ruta antigua).

En estos casos, para indicarle a Git el renombrado (o movimiento de ficheros), tenemos que decirle que añada el nuevo nombre y elimine el antiguo:

$ mv file.txt renamed.txt
$ git add renamed.txt
$ git rm file.txt

Otra cosa que podemos querer hacer es eliminar ficheros. Hacerlo desde Git es tan simple como:

$ git rm file.txt file2.txt

Al igual que cuando movemos ficheros, lo normal es hacerlo desde fuera de Git (nuestro editor, el explorador de ficherso…). Si lo hemos hecho así, la forma de añadir esa eliminación al stage es la misma:

$ rm file.txt
$ git rm file.txt

Algo que suele ocurrir, es que queramos añadir al stage modificaciones sobre ficheros, así como la eliminación de otros tantos. Para ello, con lo explicado hasta ahora habría que hacerlo en dos pasos:

$ git add modified-file1.txt modified-file2.txt
$ git rm deleted-file.txt deleted-file2.txt

Pero si queremos ahorrarnos estos pasos y añadir todos los cambios sobre los ficheros que Git conoce y no están añadidos al stage, podemos hacerlo de golpe con:

$ git add --all

### Sacar cambios del stage

Como ya hemos visto antes gracias a la información de git status, para sacar cambios que estén añadidos al stage podemos usar git reset HEAD file.txt.

Para sacar todos los cambios del stage:

$ git reset HEAD .

Para sacar cambios concretos:

$ git reset HEAD file1.txt file2.js file3.html

Deshacer cambios sobre ficheros del workspace

En muchas ocasiones nos encontraremos con que hemos hecho cambios sobre ficheros, o que hemos eliminado ficheros, y queremos volver a la versión previa a esos cambios.

Para deshacer los cambios sobre todos los ficheros:

$ git checkout -- .

Para deshacer los cambios sobre ficheros concretos:

$ git checkout -- file1.txt file2.js file3.html

Crear commits

Una vez tenemos los cambios en nuestro stage, el siguiente paso es hacer el commit.

La manera más simple es:

$ git commit

Al hacerlo así se abrirá el editor del sistema para que escribamos el mensaje asociado al commit. Este editor normalmente será vim o nano en entornos UNIX. Una vez escrito el mensaje, en la primera línea del fichero de texto abierto, sólo tenemos que guardar y cerrar el editor para que el commit se cree.

Si queremos ahorrarnos el paso del editor, podemos especificar el mensaje directamente desde el comando:

$ git commit -m 'My cool and descriptive message'

Crear commits desde Eclipse

Una vez hemos hecho cambios sobre los ficheros de nuestro proyecto, podemos hacer commits seleccionando la opción "Commit", dentro de la sección "Team" que aparece al hacer click derecho sobre nuestro proyecto en Eclipse.

Se mostrará una ventana desde donde podremos seleccionar los ficheros que queremos incluir en nuestro commit, y una caja de texto para insertar el mensaje que queramos darle.

Modificar el último commit

Si nos hemos olvidado de añadir algo al último commit y aún no lo hemos subido al servidor, podemos arreglarlo de la siguiente forma:

$ git add forgotten-file.txt
$ git commit --amend

Al hacerlo, se nos abrirá el editor con el mensaje del último commit listo para ser modificado (si queremos). Una vez guardado y cerrado el editor, se modificará el commit con los cambios sobre forgotten-file.txt añadidos.

Si queremos modificar el commit y reutilizar su mensaje, ahorrándonos todo el tema del editor, podemos hacerlo con:

$ git commit --amend -C HEAD

Eliminar commits

Algo que también se hace relativamente a menudo es eliminar commits. Es muy importante tener en cuenta que no se deben eliminar commits que ya se hayan subido al remoto. Lo normal es querer eliminar el último commit (o los últimos hasta un punto) que aún no se han subido.

Para hacerlo debemos usar git reset, dándole el identificador del commit al que queremos volver. Esto es importante, ya que reset significa "llévame hasta este commit, eliminando los que hay por encima".

$ git reset 4de89ea

Una manera rápida de eliminar el último commit sin tener que buscar el identificador del commit anterior es:

$ git reset HEAD~1

Hay que tener en cuenta que por defecto, después de ejecutar git reset, los cambios de los commits eliminados se mantienen en el workspace. Es decir: no se pierden. A esto se le llama soft reset.

Si queremos eliminar los cambios de los commits además de los commits en si mismos, debemos informar a git reset de que queremos hacer un hard reset:

$ git reset --hard 4de89ea

Y de nuevo, lo repito para que quede muy claro, no se deben eliminar commits que ya se han subido al servidor. Si lo hacemos, podemos poner a los compañeros y a nosotros mismos en un buen problema lleno de quebraderos de cabeza.

Eliminar commits desde Eclipse

Para eliminar un commit elegiremos la opción "Reset" que nos aparecerá al hacer click derecho sobre el commit del histórico (el log) al que queramos movernos, eliminando todos los que estén por encima de este.

Deshacer commits

Otra cosa muy común es querer deshacer un commit. ¿Qué significa esto? Que queramos revertir los cambios que se introdujeron en un commit concreto.

Con un ejemplo concreto se entiende mejor: Imaginad que hicimos un commit donde metimos un Javascript que añadía un tooltip a todos los enlaces de la página, pero más adelante nos damos cuenta de que no queremos más ese comportamiento.

Podríamos eliminar manualmente esa librería y crear un nuevo commit, pero Git es más inteligente que eso y nos deja hacerlo automáticamente:

$ git revert 4de89ea

Al hacer esto se creará un nuevo commit deshaciendo los cambios introducidos en el commit 4de89ea. Se abrirá el editor con un mensaje de commit predeterminado que podremos modificar y, al guardar y cerrar el editor, el commit deshaciendo los cambios quedará creado.

Deshacer commits desde Eclipse

Para deshacer un commit elegiremos la opción "Revert commit" que nos aparecerá al hacer click derecho sobre el commit del histórico (el log) que queramos deshacer.

Subir cambios al servidor

Una vez que tenemos preparados una serie de commits en local, podemos subirlos al servidor de la siguiente manera:

$ git push origin master

Donde master es el nombre de la rama que queremos subir y origin el nombre del remoto.

Habrá ocasiones en las que el servidor no nos permita subir debido a que existan arriba cambios que aún no tenemos. Para ello nos deberemos traer los cambios antes de subir (ver siguiente sección).

Subir cambios al servidor desde Eclipse

Para subir cambios al servidor, elegiremos la opción "Push to upstream" desde la sección "Team" que aparece al hacer click derecho sobre nuestro proyecto en Eclipse.

### Traer cambios del servidor

Para traernos los cambios existentes en el servidor hacia nuestra rama, usaremos:

$ git pull origin master

Traer cambios del servidor desde Eclipse

Para traer cambios del servidor, elegiremos la opción "Fetch from upstream" desde la sección "Team" que aparece al hacer click derecho sobre nuestro proyecto en Eclipse.

Mezclar ramas

Algo muy común cuando se trabaja con Git es mezclar ramas. Imaginemos que estamos trabajando en una feature sobre una rama de desarrollo, y cuando hemos acabado queremos llevar nuestro fantástico código a la rama principal del proyecto. ¿Cómo lo hacemos?

$ git checkout master
$ git merge my-feature

El primer paso es movernos a la rama a la que queremos llevar tus cambios, y el segundo es llamar a git merge diciéndole de dónde queremos traer los cambios.

Conceptualmente, git merge se trae los cambios de la rama que se le diga a la rama en la que nos encontramos.

Mezclar ramas desde Eclipse

Para mezclar ramas desde Eclipse nos deberemos situar en la vista "Git repositories" y, estando situados en la rama a la que queremos traernos los cambios, hacemos click derecho encima de la rama de la que queremos traer los cambios, y seleccionamos la opción "Merge".

Solucionar conflictos

Después de realizar algunas operaciones (como pueden ser git merge o git pull) es posible que haya conflictos entre nuestro código y el código que nos hemos traído.

Cuando esto ocurra, después de realizar la operación Git nos avisará con un mensaje del tipo:

$ git pull origin master

From https://github.com/twbs/bootstrap.git
 * branch            master     -> FETCH_HEAD
Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

Y si hacemos un git status veremos algo tal que:

$ git status
# On branch branch-b
# You have unmerged paths.
#   (fix conflicts and run "git commit")
#
# Unmerged paths:
#   (use "git add ..." to mark resolution)
#
# both modified:      file.txt
#
# no changes added to commit (use "git add" and/or "git commit -a")

Aquí vemos como file.txt se encuentra dentro de la sección Unmerged paths, y está marcada como both modified. Eso significa que hay conflictos en ese fichero.

Si abrimos este fichero con alguna herramienta de diff (como vimdiff) podremos ver de manera visual cuáles son los conflictos, y resolverlos como nos convenga.

Si abrimos el fichero con un editor de texto, veremos los conflictos de la siguiente manera:

the number of planets are
<<<<<<< HEAD
nine
=======
eight
>>>>>>> branch-a

Esas marcas indican cuáles son nuestros cambios (los de la sección HEAD) y cuáles son los cambios de otra persona (en este caso, los marcados en branch-a). Para elegir uno de ellos, sólo tenemos que borrar las líneas que no nos interesen y dejar el fichero tal y como lo queramos (borrando las marcas de conflicto y todo lo que no queramos: el objetivo es dejar el fichero tal y como queramos que se quede).

Puede ocurrir que en lugar de mezclar los cambios, necesitemos quedarnos con el fichero tal y como lo teníamos previamente:

$ git checkout --ours file.txt

O tal vez queramos quedarnos con el fichero en el estado en el que estaba en la otra rama, olvidándonos de nuestros cambios:

$ git checkout --theirs file.txt

Una vez solucionados los conflictos, podemos proceder a decirle a Git qué ficheros quedan marcados como resueltos. Para ello usaremos:

$ git add file.txt

Cuando ya están todos los conflictos solucionados y marcados como tal, ya se puede crear el commit con la resolución:

$ git commit

Como se puede ver, no le hemos especificado un mensaje al commit, por lo que se abrirá el editor del sistema para que escribamos un mensaje. En este caso, al tratarse de un commit de resolución de conflictos, el mensaje ya viene pre-cargado (aunque podemos modificarlo).

Solucionar conflictos desde Eclipse

Cuando ocurren conflictos después de alguna operación (como puede ser pull o merge), Eclipse nos avisará sobe qué ficheros tienen conflictos, y nos permitirá abrirlos para revisarlos.

Para abrirlos con la herramienta de resolución de conflictos, haremos click derecho sobre el fichero en cuestión y seleccionaremos la opción "Merge tool" en la sección "Team". Esto nos abrirá la vista de resolución, con los cambios conflictivos a cada lado.

Una vez resueltos los conflictos, añadimos los ficheros ("Team > Add to Index") y procedemos a realizar el commit con la resolución.

Trabajar con el stash

Como hemos comentado antes, hay ocasiones en las que necesitamos guardar los cambios del workspace y del stage para realizar alguna operación (actualizar cambios desde el servidor, cambiar de rama, etc.). Para ello usaremos el stash.

Podemos pensar en el stash como una lista que contiene grupos de cambios temporales, que podemos consultar, aplicar en el workspace actual, etc.

Para añadir los cambios actuales al stash, usaremos:

$ git stash

Para aplicar en nuestro workspace el último stash guardado:

$ git stash pop

Hay más comandos para trabajar con el stash, pero lo más habitual es tener únicamente un elemento en la lista y aplicarlo inmediatamente después del problema que hayamos intentado solventar (cambiar de rama, actualizar con los últimos cambios del remoto, etc.).

Alias útiles

A la hora de trabajar con Git, es muy cómodo crear algunos alias para las tareas más habituales (o más tediosas), para así perder menos tiempo escribiendo comandos y más tiempo haciendo cosas de verdad.

Para crear alias sólo tenemos que crearlos en nuestro fichero .gitconfig, que estará situado en el $HOME de nuestro usuario.

Dentro de este fichero, crearemos una sección para los alias de la siguiente forma:

[alias]
  name = command

A continuación enumero algunos alias útiles:

• st = status -sb: Muestra el estado de nuestro workspace de manera resumida: git st
• ci = commit: Forma resumida para crear commits: git ci
• cm = commit -m: Forma resumida para crear commits con mensaje: git cm "My cool commit"
• amend = commit --amend -C HEAD: Forma abreviada para modificar el último commit realizado, reutilizando su mensaje: git amend
• co = checkout: Forma abreviada para checkout: git co
• br = branch -va: Mostrar el listado de branches de nuestro repositorio, incluyendo los remotos: git br
• brd = branch -D: Forma abreviada para borrar branches: git brd my-branch
• undo = reset --soft HEAD^: Deshacer el último commit realizado: git undo
• unmerged = ls-files --unmerged: Listar los ficheros no mezclados (con conflictos): git unmerged
• untracked = ls-files --other --exclude-standard: Listar los ficheros no gestionados por Git (untracked): git untracked
• ignored = ls-files --ignored --exclude-standard: Listar los ficheros ignorados por Git: git ignored
• l5 = log --max-count=5: Muestra los 5 últimos commits realizados
• l10 = log --max-count=10: Muestra los últimos 10 commits realizados
• last = log -1: Muestra el último commit realizado
• since-last-tag = log `git describe --tags --abbrev=0`..HEAD: Muestra los commits realizados desde el último tag creado
• archive-last-tag = !git archive --format=zip `git describe --tags --abbrev=0` > `git describe --tags --abbrev=0`.zip: Crea un fichero ZIP con el último tag creado

como puedo hacer, que el archivo que estoy trabajando a los demás no les deje modificar, hasta liberarlo, no se si se puede.

Excelente, muy bueno, en especial la parte donde pusiste

empezar a soltar comandos como un bellaco

jajaj, excelente, saludos

Excelente, Gracias