Descartar todos los cambios no pusheados

Para descartar todos los cambios no pusheados (y hacer de cuenta que no se commiteo nada)

git reset --hard origin/master

Explicacion

git reset es el comando que permite cambiar a que commit apunta la rama en la cual se esta trabajando, por ejemplo, el siguiente comando ocasionara que la rama en la que estan trabajando retroceda un commit:

git reset --hard HEAD^

Lo que se hace para deshacer todos los commits que no se pushearon hasta el momento, es asignar a la rama master el mismo commit al que apunta la rama remota: origin/master, esto es lo que hace el comando git reset --hard origin/master
La opcion --hard, sirve para indicar que reinicie tambien el indice y el working tree a esa version.

Deshacer

Si se arrepintieron de descartar sus cambios, lo unico que hay que hacer es restaurar la ref (el puntero de la rama) a su valor original, que se puede hacer asi

git reset --hard HEAD@{1}

HEAD@{1} es el valor que tuvo HEAD antes de que sea cambiado por el otro git reset, eso se puede verificar mas claramente con el comendo git reflog

Obtener el codigo del pasado, Parte II: Tags

Como se vio en Obtener codigo del pasado, es posible obtener el codigo de cualquier commit arbitrario que se haya realizado, con solo localizarlo y checkoutearlo.

Segun la situacion, localizar commits puede ser tedioso, por eso existen los tags, que son la herramienta para marcar commits a los que se desea ir con frecuencia.

LOCALMENTE

Para taguear el commit en el que estamos parados:

git tag nombre_del_tag

Para taguear otro commit

git tag nombre_del_tag 012345679abcde

git tag nombre_del_tag nombre_del_branch

git tag nombre_del_tag nombre_de_otro_tag

git tag nombre_del_tag HEAD^

(ese ultimo taguea el parent del commit en el que estamos parados)

Para ver el contenido del tag

git checkout nombre_del_tag

REMOTAMENTE

Es posible crear tags en un repositorio remoto, asi:

git push origin HEAD:refs/tags/nombre_del_tag

Para que cualquiera apuntando a ese repositorio se baje ese tag, tiene que hacer:

git fetch --tags

Actualizacion: HEAD podria reemplazarze con cualquier SHA de commit, nombre de branch o tag ya existente (por ejemplo, uno local que se quiere hacer remoto)

Saludos, y Felices Fiestas!

Links:

* Post anterior: Obtener codigo del pasado

* Pagina de manual de git-tag

Descommitear

Commitearon pero se arrepintieron (y todavia no subieron nada a ninguna parte)

Para descommitear mantiendo el working tree sin modificar (por si lo necesitan):

git reset HEAD^

Para descartar los cambios del working tree

git checkout HEAD .

Para hacer las dos cosas en un solo comando (descommitear y descartar los cambios del working tree):

git reset --hard HEAD^

Para la proxima, voy a explicar como des-descommitear y como descommitear despues de subir los cambios

Obtener el codigo del pasado

Es natural encontrarse con situaciones en las que necesitemos ver al pasado y obtener todo el trabajo de una version, por ejemplo, de hace dos semanas.

En ese caso lo primero sera localizar esa version en el historial, usando git-log

--format=oneline indica que solo se muestre una linea por commit y HEAD~20..HEAD indica el rango de commits que se van a mostrar, que indica que se muestren los ultimos 20 commits

Ahora supongamos que queremos ver el contenido del commit que dice "evalhook v0.1.0", observamos que el hash correspondiente a ese commit que es 34f8b706... y ejecutamos

Observar que no hubo necesidad de poner todo el SHA (el choclo hexadecimal) completo con poner la version abreviada ya alcanza, siempre y cuando no se produzcan ambigueadades (si se especifica una abreviacion demasiado corta o si existe una cantidad inmensa de commits en el repositorio)

Ahora, con este comando, se trajo todo el contenido que estaba en esa version para que sea examinado o para crear branches a partir de el, para volver a trabajar en la ultima version, hay que volver con el comando:

NOTA: Lo que explique es comun usarlo cuando se examina el repositorio para analizar codigo anterior y otras cosas, pero para navegar por releases (por ej. la version 0.1.0 del proyecto) es mas practico usar tags

NOTA 2: La advertencia que aparece cuando se hace el primer checkout para volver al commit pasado aparece porque se cambio a un "detached HEAD", es decir, que no se esta trabajando en ningun branch y si bien se puede commitear desde ese punto, esos commits no perteneceran a ningun branch (salvo que se cree uno). En el ultimo commit, se "re-attacheo" el HEAD al branch master para que los commits que se hagan pertenezcan a ese branch

--amend hermano

La opcion --amend del comando commit permite deshacer el ultimo commit y volver a commitear con otra informacion diferente (por ej, si se olvidaron de agregar un archivo)

La forma mas comun que tengo de usar el comando es la siguiente:

git commit --amend -C HEAD

Que commitea lo que se agrego al indice, pero añadiendo el contenido al ultimo commit en lugar de crear uno nuevo

Ejemplo:

Observar la salida del comando git log --raw:



















Me olvide de commitear test2.txt, lo mejor sera corregir eso ya que hay comando para hacerlo:


























NOTA: Es mejor hacer esto antes de haber pusheado a otro repositorio, pero en caso de que ya se haya pusheado, no pasa nada, solo ocurrira un merge trivial que se resolvera con el proximo "git pull"

NOTA2: La opcion -C indica que se va a usar como comentario del commit el comentario de otro commit ya existente, en este caso "HEAD", es decir, el commit en el que se esta trabajando

NOTA3: git commit --amend es equivalente a (extraido del manual):

git reset --soft HEAD^
... do something else to come up with the right tree ...
git commit -c ORIG_HEAD

Links

Manual de git-commit


--amend

¡Habemus Blog!

Hola hermanos y hermanas que me estan leyendo, hice este blog para traerles la buena nueva de que ya no es necesario sufrir por sistemas de versionamiento cerrados (ej. ClearCase) que cuestan un ojo de la cara y para colmo son extremadamente dolorosos.

Tampoco es necesario padecer por sistemas de versionamiento que aunque sean libres son un obstaculo en el camino a la alegria, como lo son por ej SVN... buen versionador pero que produce una sensacion de vacio existencial, una falta de noseque (se explica detalladamente en proximas entradas de este blog)

Ni hablar de los que estan en el limbo de los que nunca versionaron, el contenido de este blog tambien es para ellos y que se sumen al rebaño y tambien conozcan la gloria del GIT, la puerta grande al mundo del versioning.

Inicialmente, existiran estas categorias principales de entradas:

• Versioning: evangelism dedicado a quienes no conocen el versioning en lo absoluto
  
• GIT: evangelism dedicado a quienes si conocen versioning, pero no conocen GIT y sufren por eso
• Tips: evangelism dedicado a quienes trabajan con GIT por algun motivo, pero no conocen todas las facultades que tiene
• SCM: El Plan de GIT y sus enseñanzas acerca de los procesos de desarrollo en la nueva era
  

--amend