Guia GIT 2.0

# todos los archivos son "rastreados" y en "staging area"
git clone urlrepositorio

# si creamos archivos, pero no los agregamos con "git add"
# su estado es: untracked files (archivos sin seguimiento), y NO estarán en el "área de stage"
touch promociones.txt descuentos.txt

# cambiamos el estado a "tracked files", y pasando al "área de stage"
# cambios pendientes de confirmar (commit)
git add .

# si modificamos un archivo rastreado
# pasa a un estado "unstaged changes" osea "cambios no rastreados, pendientes a agregar al area de stage"
#
# Obs: no confundir con el archivo no rastreado osea "untracked file",
# este nuevo estado hace referencia a los cambios
echo "descuentos para adultos" >> descuentos.txt

# si borramos un archivo rastreado,
# cambia de estado a "untracked files", se borra del "staging area"
# (el archivo no se borra del directorio)
git rm --cached promociones.txt

# hacemos que HEAD apunte al commit anterior del último commit
# - alternativa sería agregar el hash del commit que mencionamos
# Obs: master^ es equivalente a master~ y HEAD^ y también HEAD~
git checkout master^

# si revisamos el estado del directorio de trabajo
# dirá "HEAD está desacoplada en b30b31"
# (suponiendo que b30b31 es el hash del anteúltimo commit)
git status

# hacemos que HEAD apunte 3 commits atrás, respecto de donde apuntaba HEAD
git checkout HEAD~3

# si revisamos el estado del directorio de trabajo, dirá que HEAD está desacoplado
git status

# si revisamos el registro de commits, desaparecerán los últimos 3 cambios
git log --oneline --decorate --graph

# hacemos que HEAD apunte 2 commits atrás, respecto del nuevo commit al que apuntaba HEAD
git checkout HEAD~2

# hacemos que HEAD del master apunte 2 commits atrás,
# respecto del último al apuntaba HEAD en la rama master
git checkout master~2

# si revisamos el estado del directorio de trabajo, dirá que HEAD está desacoplado
git status

# si revisamos el registro de commits,
# desaparecerán los últimos 2 cambios que hicimos en la rama master
git log --oneline --decorate --graph

git checkout HEAD~3

# generamos algunos cambios
touch producto-{1,2,3}.txt

# agregamos los cambios, y confirmamos
git add . && git commit -m "Agregamos cambios olvidados?"

# creamos la rama y le asignamos el hash del commit 192abc3
# (suponiendo que 192abc3 fue el hash que se generó con el commit)
git branch nombreNuevaRama 192abc3

# clonamos el repositorio remoto
# que tendrá de nombre "origin"
# y tendremos la rama inicial llamada origin/master que apunta al repositorio remoto
git clone urlRepositorioRemoto

# clonamos el repositorio remoto
# que tendrá de nombre "pomposo" en vez de "origin"
# y tendremos la rama inicial llamada pomposo/master que apunta al repositorio remoto
# Obs: Podemos usar el atajo -o en vez de --origin
git clone --origin pomposo urlRepositorio

# chequeamos el nombre que le asignamos al repositorio remoto
# aparecerá en la primera columna
# Obs: Podemos usar el atajo -v en vez de --verbose
git remote --verbose

# agregamos el archivo al "Stage" (ó Index)
git add productos.csv

# agregamos archivos al Stage (ó Index)
# -p: lo hace de manera interactiva
git add -p

# sacamos los archivos del "Stage" (Area de stage)
# -p: lo hace de manera interactiva
git reset -p

# sacamos los archivos del árbol de trabajo "Working Tree"
# -p: lo hace de manera interactiva
git checkout -p

# Eliminamos del árbol de trabajo todos los archivos
# que no están bajo el control de versiones
# situandonos del directorio actual
#
# Observación:
# Se sugiere tener CUIDADO con el uso de este comando,
# porque también puede borrar archivos que están en el .gitignore (aquellos que no queremos subir al remoto)
#
# -d: Elimina los directorios  y archivos sin seguimiento (untracked files)
# -f: Forzar la acción de limpiar el directorio
git clean -df

# creamos el archivo
# - estado del archivo: unstaged, por tanto también untracked (sin seguimiento de los cambios)
touch productos.csv

# agregamos el archivo al "area de staged"
# - estado del archivo: staged, por tanto también tracked (en seguimiento de los cambios)
# - estado de los cambios: unstaged (porque no se modificó)
git add productos.csv

# agregamos algunos cambios
# - estado del archivo: staged
# - estado de los cambios: unstaged (porque se modificó, pero ahora hay que agregarlos con git add)
echo "banana, $500" >> productos.csv

# agregamos ambos
# - estado del archivo: staged
# - estado de los cambios: staged
git add .

# deshacemos los cambios de los archivos que estén en el "area de staged"
# - estado del archivo: staged
# - estado de los cambios del archivo: unstaged
#
# Observación:
# Deshace los cambios que estén en "area de staged"
# pero aún se conservan en el árbol de trabajo (the working tree)
git reset --patch

# OJO..! WARNING "podemos perder los cambios, y no los recuperamos"
#
# deshacemos los cambios de los archivos del árbol de trabajo
# a diferencia del "git reset --patch", estos cambios se perderán
git checkout --patch

# Deshacemos los cambios de manera "interactiva"
# git nos pregunta que cambios queremos deshacer ó conservar
# y muestra las diferencias de las modificaciones
#
# Observación:
# - Cuando nos pregunte si queremos deshacer los cambios, elegimos yes
# - NO sirve si el estado del cambio es "unstaged changes" (cambios que no se agregaron con git add)
git reset --patch

# Sólo sirve para archivos del "area de staged" que fueron modificados
# pero que tienen estado "unstaged" (osea piden que hagas un git add)
#
# Git nos pregunta de cuales archivos queremos deshacer los cambios
# de manera interactiva (esto es gracias al parámetro --patch)
#
# ATENCIÓN..!
# Esto modifica el árbol de trabajo, los cambios que deshagamos no se pueden recuperar
git checkout --patch

# Deshacemos los cambios de TODOS los archivos del árbol de trabajo (the working tree)
# que fueron modificados
#
git checkout -- .

# mostramos las diferencia de los archivos del area de staged
# contra la última confirmacion (commit)
git diff --staged

# Creamos un nuevo branch,
# y hacemos que HEAD cambie su referencia (apunte) al nuevo branch
# - Al cambiar la referencia de HEAD, los nuevos commits (cambios) se aplicarán al branch que apunte HEAD
# - Al pasar el parámetro --branch, git crea primero el branch y luego el checkout a ese branch
git checkout -b nombreNuevoBranch

# luego de hacer los cambios
# pusheamos el branch al repositorio remoto
# git push origin -u origin new_feature_name # yo usé este, pero la -u que hace?
git push origin nombreBranch

# Si queremos que el branch local tenga otro nombre en el repositorio remoto
#
# 1. nos traemos los cambios del servidor, sin modificar nuestro directorio de trabajo
# para luego fusionarlo/integrarlo cuando queramos (merge)
git fetch origin
# 2. listamos todos los branches (locales y remotos) por si queremos subir los cambios a otro branch remoto
git branch --all
# 3. subimos los cambios
git push origin branchLocal:branchRemoto

# Cambiamos la referencia de HEAD, apuntando al branch principal (osea master)
# - Los commits (cambios) que hagamos, se aplicaran al branch al que apunta HEAD
# - Al cambiar de branch, se verán cambios en la ruta del repositorio local (nueva estructura, archivos modificados, ...)
git checkout master
# Integramos/fusionamos los cambios del branch, a la rama actual (a la que apunte HEAD)
# - en nuestro caso sería master, porque habiamos hecho el checkout master
git merge origin/nombreBranch
# subimos los cambios (el master fusionado con el branch)
git push

# Recuperamos (fetch) las referencias/punteros de las ramas de repositorio remoto, sin modificar nuestro directorio de trabajo
# - los cambios que se hayan realizado en las ramas remotas, no alteran las nuestras
# - solo nos traemos y actualizamos los punteros/referencias no editables, que podemos ver con "git branch --remotes"
git fetch origin

# integramos/fusionamos (merge) los confirmaciones/cambios de la rama remota "serverfix" a la rama actual
# - si querés cambiar el branch actual a otro, debemos hacer "git checkout nombreRama"
# - si queres saber en que rama estás ejecutamos "git branches --all"
# - decimos que "serverfix" es una rama remota porque "origin" es el nombre por defecto del repositorio remoto
git merge origin/serverfix

# Cambiamos de rama local a "serverfix"
# - la referencia de "HEAD" apuntará a esa rama a la que cambiamos, osea "serverfix"
# - el directorio de trabajo cambiará o no, segun las confirmaciones/cambios aplicados que tenga esta rama
# - los cambios/confirmaciones que hagamos se harán en esta rama local
git checkout serverfix
# Le agregamos a la rama local la referencia/puntero hacia la rama remota "serverfix" del repositorio remoto "origin"
git branch -u origin/serverfix

# Si tenemos más repositorios remotos aparte del origin,
# podemos hacer seguimiento de una rama hacia ese otro repositorio remoto
# Es decir cambiamos la referencia/puntero del repositorio por defecto "origin", por otro distinto que es servidor2
# (suponiendo que ese servidor2 aparece en el listado de "git remote --verbose")
git branch -u servidor2/serverfix

# Fusionamos/Integramos (merge) nuestra rama local "serverfix" con la rama remota "serverfix"
#
# 1. Creamos un branch llamado "severfix"
# 2. Traemos los cambios del branch remoto "serverfix"
#    - Es una rama remota, porque "origin" apunta al repositorio remoto (servidor) por defecto
#    - Aunque diga checkout, al tener el parámetro -b se crea primero el branch local, y luego hace el checkout
#      a esa rama
git checkout -b serverfix origin/serverfix

# Si queremos que se agreguen los cambios en otra rama local,
# modificamos el primer argumento, en este caso le pusimos el nombre "issuefix01"
git checkout -b issuefix01 origin/serverfix

# recuperamos los datos del servidor
# aunque no los aplica en el repositorio remoto, nosotros
# decidimos si subir los cambios (push) ó fusionar/integrar los cambios (merge)
git fetch origin

# si decidimos subir los cambios
# suponiendo que la rama de seguimiento tiene N confirmaciones delante
# (esas N confirmaciones delante, representan cambios locales que queremos subir al servidor)
git push nombreRemoto nombreRama

# si decidimos fusionar los cambios
# suponiendo que la rama de segumiento tiene N confirmaciones detrás
# (esas N confirmaciones detrás, representan cambios en el servidor, que debemos recuperar a nuestro entorno)
git merge nombreRemoto/nombreRama

# actualizamos las referencias
git fetch origin

# listamos todos los branches (locales y remotos)
git branch -a

# eliminamos una rama local
# Obs: podemos cambiar --delete por su forma abreviada -d
git branch --delete nombreRama

# eliminamos de manera forzosa
# -D sería similar a --force --delete
git branch -D nombreRama

# actualizamos las referencias
git fetch origin

# listamos todos los branches (locales y remotos)
git branch -a

# borramos la rama remota
# git push (remoto) (rama)
git push origin --delete nombreRama

# configuramos por defecto diff3
git config --global merge.conflictstyle diff3

git checkout master
# creamos y agregamos contenido al archivo
vim productos.csv
# agregamos el archivo modificado, y confirmamos el cambio
git add productos.csv && git commit -m "Agregamos los productos"

git checkout -b feature-precios
# modificamos el archivo, agregamos una columna con los precios
vim productos.csv
# agregamos el archivo modificado, y confirmamos el cambio
git add productos.csv && git commit -m "Agregamos los productos"

git checkout master

git checkout -b feature-descuentos
# modificamos el archivo, modificamos columna con los descuentos
# y borramos una de las filas
vim productos.csv
# agregamos el archivo modificado, y confirmamos el cambio
git add productos.csv && git commit -m "Agregamos los precios y borramos un producto"

git checkout master

# fusionamos
git merge feature-precios
# fusionamos una segunda vez (tendrá un conflicto)
git merge feature-descuentos

# separamos los últimos cambios no confirmados (que no hicimos commit)
# (se podria decir que se guarda en una pila de cambios)
git stash

# abortamos la fusión
git merge --abort

# podemos revisar el listado (opcional)
# (vemos la pila de cambios)
git stash list

# retomamos los cambios que habiamos separado
# (sacamos los últimos cambios separados de la pila de cambios)
git stash pop

# activamos la rama master (por si acaso que estémos en otra rama)
git checkout master

# creamos una rama para agregar los precios
git checkout -b feature/precios
# generamos algunos cambios
echo "prod1 $500" > productos.txt
echo "prod1 $300" >> productos.txt
# agregamos el archivo modificado y confirmamos los cambios
git add productos.txt && git commit -m "agregamos los precios"

# volvemos a activar la rama master
git checkout master

# nos creamos una nueva rama basada en la rama master
git checkout -b feature/promociones
# modificamos los datos
vim productos.txt
# agregamos el archivo modificado y confirmamos los cambios
git add productos.txt && git commit -m "agregamos las promociones"

# activamos la rama de los descuentos
git checkout feature/descuentos
# sobreescribimos el registro de confirmaciones
# para que la última confirmación sea la de feature/descuentos
git rebase master

# retomamos la rama master
# y nos traemos los cambios reorganizados de la rama feature/descuentos
git checkout master
git rebase feature/descuentos

# repetimos las operaciones anteriores
git checkout feature/promociones
git rebase master
# si aparece un conflicto, lo solucionamos
# y le avisamos a git que siga con el rebase
git rebase --continue # esto es solo si aparece un conflicto

git checkout master
git rebase feature/descuentos

# al usar el parámetro --hard
# deshacemos los cambios, y no mantenemos los cambios
git reset --hard HEAD~1

# deshacemos el merge anterior
# restauramos el directorio y los archivos que se modificaron con el merge anterior
git merge --abort

#
git checkout merge-into-ours

#
git merge from-theirs

# nos evitamos buscar las diferencias con "git mergetool"
# nos quedamos solo con nuestro cambio
git checkout --ours README.md

# suponiendo que cambian de parecer
# y nos dicen que la revisión correcta, NO es la nuestra
git checkout --theirs README.md

# agregamos el archivo modificado
git add README.md

git commit -am "Conflicto solucionado"

# Mostramos las confirmaciones que tienen conflicto
# más en detalle de un archivo específico (suponiendo que ese archivo generó el conflicto)
git log --merge -p README.md

# Stage #1 is the common ancestor of the files
# Common base version of the file.
# archivo ancestro en común
git show :1:README.md

# Stage #2 is the target-branch version
# 'Ours' version of the file.
# archivo del repositorio local, el nuestro
git show :2:README.md

# Es el MERGE_HEAD
# Stage #3 is the version you are merging from
# 'Theirs' version of the file.
# archivo del repositorio remoto (aunque puede ser local y venir de otra rama local)
# archivo que queremos fusionar
git show :3:README.md

git mergetool

# creamos la rama, y la activamos
git checkout -b feature/anuncios

# hacemos varios cambios
mkdir anuncios && cd anuncios && touch anuncio{1..5}.txt && cd ..
git commit -am "agregamos varios anuncios"

mkdir imagenes && touch imagenes/imagen{1,3,7}.png
git commit -am "agregamos imagenes de los anuncios"

# publicamos nuestra rama (opcional)
git push origin feature/anuncios

# activamos la rama master
git checkout master

# fusionamos los cambios de la rama feature/anuncios en la rama master
# - pero todos los commits de esa rama, aparecerán como un solo commit
# - si no le pasamos squash, el master tendrá todos los commits que hicimos en esa rama
git merge --squash feature/anuncios

git commit -m "Agregamos varios anuncios"