git.readme.es.txt

Creado: 18-May-2014
Autor: Daniel Mastropietro

Traducido por: Fernando Mastropietro (Septiembre 2022)

Descripción: Ejemplos de uso de git. Todos los comandos utilizados deben ejecutarse desde un entorno Git BASH.
Suposiciones: Git BASH y, opcionalmente, Git GUI están instalados en una máquina local.

Ref:
http://git-scm.com/
https://help.github.com/
https://www.atlassian.com/git/tutorials/comparing-workflows (agregado el 31 de octubre de 2017: buena vista de diferentes escenarios de trabajo con ejemplos y comandos útiles de git)
https://sethrobertson.github.io/GitFixUm/fixup.html (agregado el 24 de julio de 2018: muy buen sitio sobre cómo arreglar el historial de github (por ejemplo, cuando hacemos una confirmación que no teníamos la intención de hacer) donde el autor guía al usuario a diferentes caminos de solución dependiendo de lo que haya hecho mal. ¡MUY AGRADABLE!)
[2019] https://github.com/lorenzwalthert/w-c4ds/blob/master/01-learning_resources/command_line_git.Rmd (agregado el 17 de febrero de 2019: contiene un archivo de ayuda para Git, similar a la ayuda archivos que escribo para mí mismo, ¡pero este está en Markdown! Fue mencionado en un artículo que vi en R-Bloggers sobre cómo convertirse en un mejor programador (https://www.r-bloggers.com/mastering-your-day -como-programador-3/))
[2019] https://towardsdatascience.com/10-git-commands-you-should-know-df54bea1595c (agregado el 21 de marzo de 2019: contiene una lista no trivial de comandos git útiles. Es bueno tenerlo como referencia. Podría requerir REGISTRARSE aunque...)
[2019] https://zoom.us/recording/play/f9nAjPUhnIMBRwjDFk6OH7PXWg0Cb0ena17cqEN6bgidewC67zC6fbfK-IzDFKfY?continueMode=true (agregado el 30 de octubre de 2019: seminario web de 1 hora de Git Tower titulado "17 formas de deshacer cosas en Git" -- más información en el correo electrónico de Git Tower Client guardado en la carpeta "Cursos..." en Outlook con fecha 07 de octubre de 2019 y 30 de octubre de 2019. Vi el seminario web y lo encontré muy claro y útil para tener como referencia Ej.: deshacer un reinicio --duro, deshacer una rama eliminada, git rebase (¡¡la navaja suiza!!), etc. Ref: www.git-tower.com/learn/git/first-aid-kit )




======================================================================
ÍNDICE

Cosas básicas (comienza en el elemento 0)
-----------
0.- Principales comandos diarios
1.- Inicializar el repositorio del servidor desnudo (hasta donde podemos 'push')
2.- Clonar un repositorio del servidor
3.- Confirmar cambios localmente
4.- Actualizar un repositorio de servidor desnudo (PUSH)
5.- Obtener cambios del repositorio del servidor remoto y resolver conflictos (FETCH)
6.- Fusionar MASTER con una rama TEST
7.- Volver a una versión anterior del PROYECTO (es decir, un compromiso anterior)
8.- Volver a una versión anterior de un ARCHIVO
9.- Ver los archivos que están RASTREADOS (es decir, están en el árbol de trabajo)
10.- Ver TODO el árbol de trabajo (incluidas las ramas que están fuera de alcance)
11.- Ver las diferencias históricas de un solo archivo
12.- Mira cómo cambió HEAD con el tiempo

Cosas adicionales (comienza en el artículo 100)
----------------
100.- Cambiar mensajes de commit en commits pasados
101.- Guarda el trabajo actual y trabaja en otra cosa
102.- Eliminar un commit anterior
103.- Sobre líneas de código eliminadas por otros desarrolladores
104.- Claves SSH
================================================== ====================


********************************************* Cosas básicas *** ***************************************
0.- Principales comandos diarios
-----------------------
Los siguientes comandos se enumeran en el orden en que normalmente se ejecutan desde una consola de Git Bash:

1) CUANDO HEMOS REALIZADO CAMBIOS QUE QUEREMOS PUBLICAR AL REPOSITORIO REMOTO (opcional)
	git pull --> opcionalmente ejecute esto para actualizar el repositorio local con cualquier cambio realizado en el servidor remoto

	(siempre)
	git status --> enumera los archivos que forman parte de la confirmación que se debe realizar (verde significa que el archivo se incluirá, rojo significa que NO se incluirá)
	git add -u --> agrega los archivos modificados a la lista de archivos a confirmar (cambia los archivos rojos a verdes)
	git add <archivo> --> agrega nuevos archivos que aún no se han rastreado para ser rastreados y, por lo tanto, serán parte de la confirmación
	git commit --> confirma los cambios locales en el repositorio LOCAL (abre un editor de vim donde se escribe una línea corta que describe la confirmación)

	(si 'git pull' no se ejecutó como se muestra arriba, el siguiente PUSH puede ser rechazado por el repositorio remoto)
	git push --> envía los cambios locales al repositorio REMOTE (si esto es rechazado, primero debemos hacer PULL a los datos del repositorio remoto --ver el artículo (2) a continuación)

2) CUANDO QUEREMOS ACTUALIZAR NUESTRO REPOSITORIO LOCAL CON EL ESTADO ACTUAL DEL REPOSITORIO REMOTO
	git pull --> lee el estado del repositorio remoto y actualiza el repositorio local (con combinación automática si es necesario)
	(si no estamos seguros de si nos gustaría fusionar los cambios en el repositorio remoto con los cambios locales, podemos ver qué se actualizará usando 'git fetch' y, si nos sentimos cómodos con los cambios, ejecute 'git merge FETCH_HEAD ')

	Si hay conflictos durante el proceso PULL, debemos resolverlos editando los archivos en conflicto y resolviendo los lugares encerrados entre símbolos como "<<<<< HEAD" y ">>>>> efc314" o similar.
	Una vez que se han resuelto los conflictos, podemos confirmar los cambios en el repositorio local (se etiqueta automáticamente como una confirmación MERGE) y continuar trabajando.


1.- Inicializar el repositorio del servidor desnudo (hasta donde podemos 'empujar')
-------------------------------------------------- ------------
Ref: http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server
1) Inicializar el repositorio BARE en el servidor
	# p.ej. en el directorio de Dropbox (¡si no hay otro servidor disponible!)
	mkdir git
	cd git
	git init --bare CMP.git
	## RESULTADO: Se crea un repositorio de git desnudo llamado CMP.git para el proyecto CMP en el servidor (servidor = Dropbox). Su tamaño es de ~ 15 KB.

	Usando el menú desplegable de Git en Explorer: (i) cree el directorio CMP.git, (ii) haga clic derecho sobre él y seleccione "Git Create repository here...", (iii) marque la casilla "Bare" (que está marcada por defecto si el directorio termina en .git!)

2) Inicializar el repositorio local de git
	# En el directorio local (con un proyecto ya en funcionamiento llamado CMP)
	CD CMP
	git init
	## RESULTADO: Se creó un repositorio git en la máquina local (veremos un directorio oculto .git)

	Usando el menú desplegable de Git en Explorer: (i) cd a CMP.git, (ii) haga clic derecho en un espacio vacío y seleccione "Git init here...".

3) Agregar una lista de archivos ignorados (es decir, archivos que se excluirán del seguimiento)
	En el repositorio local (SOLO), abra el archivo .git/info/exclude para agregar archivos o directorios para excluir del seguimiento.
	Agregué una nueva línea 'datos/' para excluir el directorio de datos (archivos posiblemente demasiado grandes).

	Otra opción para ignorar archivos (y directorios) es crear un archivo .gitignore en el directorio raíz del proyecto donde se enumeran las exclusiones. SIN EMBARGO tenga en cuenta que:
	- Los archivos que YA fueron RASTREADOS antes de agregar su exclusión en el archivo .gitignore no se ven afectados. Es decir. todavía van a ser rastreados. Solo se ven afectados los archivos sin seguimiento y los archivos nuevos que coincidan con el patrón de ignorar. Para dejar de rastrear un archivo que ya está rastreado, use `git rm --cached` (Ref: https://git-scm.com/docs/gitignore)
	- Por el contrario, los archivos que YA FUERON IGNORADOS antes de un cambio en .gitignore que deja de ignorarlos NO se rastrean automáticamente. Necesitamos FORZAR su adición al árbol usando `git add -f <files>`.

	Tenga en cuenta que si uno de los patrones de ignorar es ignorar todos los archivos ocultos (agregando una entrada .*), en principio NO debemos ignorar el archivo .gitignore en sí (si queremos que todos los miembros del equipo ignoren los mismos archivos). Para hacer esto, agregue la siguiente línea a .gitignore:
	!.gitignore

	La referencia a continuación también explica cómo hacer que .gitignore ignore archivos que no son nuevos (donde "not new" significa que estos son archivos que se rastrean actualmente, a diferencia de los archivos que ya existían antes de la creación del archivo .gitignore).
	Referencia: http://stackoverflow.com/questions/8021441/gitignore-hidden-dot-directories

¿DÓNDE DEBEMOS COLOCAR UN PATRÓN DE IGNORAR?
La logica es como sigue:
	- Use .gitignore para enumerar archivos para ignorar que deben compartirse con el equipo (es decir, que deben rastrearse)
	- Use info/exclude para enumerar archivos para ignorar localmente (es decir, NO se debe rastrear)
	Más información en la documentación de git-ignore:
	archivo:///C:/Programa%20Archivos%20%28x86%29/Git/doc/git/html/gitignore.html

4) Agregue archivos y primero confirme
	# En el directorio del proyecto local
	CD CMP
	git add .
	git commit
	## ( add ), Agregue la línea: "Proyecto creado"
	## RESULTADO: Todos los archivos en el directorio CMP excepto aquellos excluidos en .git/info/exclude están comprometidos.

5) Definir el repositorio remoto
	# En el repositorio local de CMP
	git remote add origen /e/Dropbox/Daniel/Projects/Lundin/git/CMP.git
	# NOTA: Si el repositorio remoto debe almacenarse en GitHub, debemos:
	# - primero crea un repositorio vacío en GitHub
	# - luego ejecute el comando 'git remote' anterior usando la URL indicada para el repositorio en GitHub (enlace HTTPS o SSH)
	# Ej: git remote add origin git@github.com:<YourGitHub>/Git.git

	# Lista de controles remotos y su ruta
	git remote -v
	## RESULTADO: el directorio remoto que contiene el repositorio del servidor se agregó al repositorio local de git

	CÓMO ACTUALIZAR UNA DIRECCIÓN DE REPOSITOR:
	Si en algún momento la ubicación del repositorio remoto ha cambiado, podemos actualizar la dirección remota de una de las siguientes maneras:
	- ejecutando 'git remote set-url <name> <new-path>' (donde <name> es el nombre del control remoto a cambiar (típicamente 'origin')
	(Tenga en cuenta que incluso si la ruta no es una URL (sino una ruta de directorio), todavía usamos la opción set-url)
	- actualizar el valor de la propiedad 'url' en el archivo .git/config a la nueva ruta.

6) Enviar cambios en el repositorio local al servidor
	# En el repositorio local de git CMP
	git push --set-upstream origin master
	## RESULTADO: el contenido del directorio CMP local fue enviado (copiado) al repositorio del servidor desnudo remoto (identificado como origen)
	## y al usar la opción --set-upstream, la rama 'master' local se configura para rastrear la rama 'master' del servidor.

	NOTA: (2015/05/27) usar 'git push' solo podría hacer el mismo truco siempre que trabajemos con ramas de seguimiento (es decir, para la rama en la que estamos trabajando ahora hay una rama remota a la que está vinculada la versión local y la información sobre qué tan adelante o atrás está la sucursal remota de la sucursal local, por ejemplo, en EGit (git para Eclipse)). Pero ANTES DE UTILIZAR ESTO, VERIFIQUE LA CONFIGURACIÓN DE LA OPCIÓN push.default EN EL ARCHIVO DE CONFIGURACIÓN.
	Para hacer esto:
	# Listar los ajustes de configuración actuales
	
	git config --list
	# Cambie la opción push.default a una opción adecuada, en este caso 'upstream' que es lo que funciona para mí
	git config push.default corriente arriba

	Notas:
	- 'upstream' significa que, de forma predeterminada, la rama actual se envía a la rama rastreada, INDEPENDIENTEMENTE de si los nombres de las ramas local y remota son los mismos. Si queremos que la acción predeterminada se envíe a sucursales remotas que tengan el MISMO NOMBRE, use la opción 'simple', que es la predeterminada para iniciar Git 2.0.
	- podemos agregar una referencia ascendente (seguimiento) (es decir, referir una rama en el repositorio remoto para que sea rastreada a la rama local) usando la opción -u como en 'git push -u origin master'. Esto es similar a usar el comando 'git checkout --track <remote-branch>' que se explica a continuación para hacer una copia de una rama remota mientras la rastrea, pero en la dirección opuesta: es decir, estamos indicando a git que cree *en el control remoto repositorio* una rama que se establece como rama de seguimiento a la rama local que estamos enviando (en este caso, se creará la rama remota 'origin/master' y rastreará la rama local 'master').

	Ref: página de manual para git-config, página de manual para git-push.


2.- Clonar un repositorio del servidor
--------------------------------------------
	# En el directorio local donde queremos crear el clon (por ejemplo, E:\Daniel\Projects\Lundin) ejecute:
	clon de git /e/Dropbox/Daniel/Proyectos/Lundin/git/CMP.git
	# y esto creará el directorio llamado CMP dentro del directorio de trabajo.

	Para clonar un repositorio que está en GitHub debemos usar la URL indicada en el repositorio de GitHub en "Clonar".

	NOTA: Es posible conocer el tamaño del repositorio ANTES de clonarlo ejecutando la API de GitHub:
		curl https://api.github.com/repos/[:organización]/[:repo]
	donde [:organización] y [:repo] deben reemplazarse con el nombre real de la organización/usuario y el nombre del repositorio, respectivamente.
	Ej: soy una organización = "mastropi" y tengo un repositorio = "envnames".
	
	Lo anterior devuelve una salida JSON donde podemos buscar la palabra clave 'tamaño' usando grep.
	Ej:
		curl https://api.github.com/repos/MJeremy2017/Reinforcement-Learning-Implementation | grep-ni tamaño
		El tamaño de salida podría estar en MB o kB dependiendo del tamaño del repositorio (!)

		Si el repositorio es privado, primero debemos generar un token en https://github.com/settings/tokens y luego usar el token como en el siguiente ejemplo:
		
		curl -u git:[:token] https://api.github.com/repos/[:propietario]/[:name] 2> /dev/null | tamaño de grupo

	Ref: https://stackoverflow.com/questions/8646517/see-the-size-of-a-github-repo-before-cloning-it


3.- Confirmar cambios localmente
--------------------------
1) Ir al repositorio local donde he estado trabajando
	cd /e/USER/Proyectos/Lundin/CMP

2) Agregar los archivos modificados a la lista de cambios a confirmar
	git add --update :/
	## Nota: ':/' puede no ser necesario
	
	## o equivalente:
	git add -u

3) Confirmar los cambios
	git commit
	## Agregue una línea de menos de 50 caracteres en la parte superior, deje la siguiente línea en blanco y describa los cambios relacionados con la confirmación


4.- Actualizar un repositorio de servidor desnudo (PUSH)
---------------------------------------------------------
1) Inserte los cambios en el repositorio del servidor remoto (¡esto solo es posible cuando el repositorio remoto está DESNUDO! Es decir, contiene solo un directorio .git; de lo contrario, los cambios deben extraerse del repositorio)
	# En el repositorio local
	git push origin master
	## RESULTADO: El repositorio del servidor remoto se ha actualizado con los cambios realizados localmente

	NOTA: Este paso solo funciona cuando el empuje da como resultado un avance rápido (es decir, la nueva versión, en la rama local maestra, es un *descendiente directo* de la versión maestra remota, lo que permite un avance rápido). Si este no es el caso, primero tendríamos que EXTRAER los cambios del repositorio remoto y fusionarlos con los cambios locales.

	SIN EMBARGO, un caso muy común en el que este paso no funciona (y nos gustaría que funcionara) es cuando modificamos una confirmación anterior (a través de 'git commit --amend'), por ejemplo, cuando solo queremos olvidar un comentario que queremos agregar a los cambios comprometidos recientemente. Cuando este es el caso y **cuando somos los únicos usuarios del repositorio o sabemos que nadie está usando el repositorio**, podemos hacer un 'git push --force' para forzar el PUSH incluso si es NO es un avance rápido. ¡Esto sin embargo produce una pérdida de la historia!
	De lo contrario, tendríamos que proceder como antes, primero extraer los cambios del repositorio remoto (¡tenga en cuenta que mientras tanto alguien puede haber estado trabajando en ello!), Combinar y luego empujar.

	Ejemplo de un empujón forzado:
	git push --force origin master

	Más información sobre este problema y avance rápido en:
	http://git-scm.com/docs/git-push ("Nota sobre avance rápido") --> ¡el último párrafo de esta sección describe exactamente este problema!
	http://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repo (la respuesta principal da un ejemplo de los pasos a seguir si realmente queremos tirar, fusionar y luego empujar, incluso cuando se trata de una enmienda)
	http://stackoverflow.com/questions/6897600/git-push-failed-non-fast-forward-updates-were-rejected (da un ejemplo de tirar, fusionar y empujar)


2) Agregue las mismas exclusiones utilizadas en el repositorio local al archivo de información/exclusión en el repositorio del servidor
	¡Esto se hace para que cualquier usuario que clone el repositorio del servidor también obtenga esas exclusiones!
	Tenga en cuenta que el archivo de información/exclusión NO se envía desde el repositorio local al repositorio del servidor con git-push arriba...
	## RESULTADO: Las exclusiones se agregan al repositorio del servidor


5.- Obtener cambios del repositorio del servidor remoto y resolver conflictos (FETCH)
-------------------------------------------------- ---------------------------
1) Obtener o extraer los cambios del repositorio del servidor remoto
	# En el directorio del servidor
	# (Asegúrese de que no haya cambios realizados localmente en este directorio de producción que deban confirmarse primero
	# usando 'git add -u :/' y 'git commit'-- o descartado --usando 'git checkout -- <archivos>'
	git fetch # equivalente a: git fetch origin (este paso SOLO recupera el estado actual del servidor remoto,

	# ¡NO descarga ningún código!)
	git merge FETCH_HEAD # Esto significa: "combinar" el HEAD FETCHed del repositorio remoto con la rama local

	# o equivalente (creo)
	git pull # Esto es en realidad buscar + fusionar

	# o podríamos hacer: (2017/10/31)
	git pull --rebase origin master # Ref: https://www.atlassian.com/git/tutorials/comparing-workflows
	lo que evita la generación de una confirmación MERGE intermedia que simplemente establece que se resolvieron los conflictos de fusión.

	NOTA: Si necesitamos descargar una rama REMOTA que NO existe en el repositorio local, podemos usar el siguiente comando de pago:
	git checkout --track origin/<remote-branch>
	(Lo probé hoy 08-mar-2020 y funcionó)
	Ref: https://stackoverflow.com/questions/24301914/how-to-create-a-local-branch-from-an-existing-remote-branch

2) Puede aparecer un conflicto al hacer "git merge FETCH_HEAD". Para resolverlos, podemos usar una herramienta de combinación ejecutando:
	git mergetool --tool=tortoismarge

	que utiliza la herramienta de combinación Tortoise para resolver los conflictos en un archivo a la vez que presenta conflictos. Con esta herramienta podemos decidir fácilmente qué versión del archivo aceptar (CTRL+F10 para aceptar la versión local, CTRL+F9 para aceptar la versión remota).

	Tenga en cuenta que si el archivo con conflictos es nuevo y no existía en una versión "base", la herramienta de combinación Tortoise no puede manejarlo y debemos aceptar/rechazar los cambios manualmente editando <<<< HEAD y >>>> secciones FETCH_HEAD.
	Ref: http://stackoverflow.com/questions/16865937/what-should-i-do-when-i-get-tortoisemerge-cannot-be-used-without-a-base

	Hay muchas herramientas para la fusión. Se enumeran haciendo:
	git mergetool --tool-help

	Otra buena referencia para comprender mejor la obtención y la fusión y sus relaciones con solo extraer es:
	http://longair.net/blog/2009/04/16/git-fetch-and-merge/
	consulte también: https://www.atlassian.com/git/tutorials/comparing-workflows con ejemplos y comandos útiles.

	NOTA: Si queremos abortar la fusión porque, p. los conflictos aparecieron después de que solicitamos una fusión con una confirmación incorrecta, podemos emitir el siguiente comando para mantener la rama base original desde la que se solicita la fusión:
	git reset --hard HEAD
	Ref: http://stackoverflow.com/questions/101752/i-ran-into-a-merge-conflict-how-can-i-abort-the-merge

	NOTA 2: Si no tenemos una herramienta de combinación disponible (porque, por ejemplo, estamos trabajando en una interfaz Git de solo comandos, podemos resolver los conflictos editando manualmente los archivos y conservando la parte que queremos conservar (buscar cosas como "<<<< HEAD", etc. para ver dónde están los conflictos).
	Una vez que se resuelve el conflicto, simplemente agregamos los archivos con el conflicto resuelto nuevamente a git, como si estuviéramos haciendo una nueva confirmación, y luego hacemos:
	git rebase --continuar (que creo que tiene sentido cuando hicimos 'git pull --rebase' al extraer los cambios --ver arriba).

	NOTA 3: Cuando abrimos la herramienta de combinación, se crean al menos tres copias del archivo con conflicto:
	- copia local
	- copia remota
	- copia base (¿qué es esto?)
	Una vez que terminamos de resolver los conflictos y salimos de la herramienta de fusión respondiendo "y" a la pregunta "¿Se resolvió el conflicto?", todos esos archivos desaparecen y el archivo generado por la fusión al intentar la fusión automática se nombra con la extensión .orig ( por ejemplo, functionsdb.php.orig).

3) Ejecute show-ref para asegurarse de que HEAD en el directorio de producción apunte al mismo estado que el repositorio local donde se realizaron los cambios.
	git show-ref --head

4) Cree una sucursal remota para una sucursal local recién creada
	Simplemente presione la rama local recién creada.
	Use la opción -u o --set-upstream de git push para crear una rama remota (con el mismo nombre que la rama local) que rastree la rama local. Vea el ejemplo a continuación.
	Luego podemos usar la opción git branch --set-upstream-to= o -u para cambiar la rama remota rastreada por una rama local si es necesario.

	Ej: si la sucursal local se llama 'test' y la hemos verificado (quizás este paso de verificación no sea necesario), use:
	git push origin test # --> crea la rama remota 'origin/test'
	git push -u origin test # --> crea la rama remota 'origin/test' que rastrea la rama local 'test'
	git branch --set-upstream-to=origin/testdaniel test # --> establece la pista ascendente de branch 'test' en 'origin/testdaniel'

5) Crear una sucursal local de una sucursal remota
	Si el servidor remoto tiene una nueva rama, el comando git-fetch simplemente nos informa al respecto, pero NO SE CREA NINGUNA RAMA LOCALMENTE.

	Si queremos trabajar en una copia local de esa rama, debemos rastrearla con el siguiente comando:
	git checkout --track <remote-branch>
	Ex:
	git fetch origin # --> supongamos que en la respuesta de este comando vemos que hay una nueva rama remota 'prueba'
	git checkout --track origin/test

	El git-checkout --track anterior es equivalente a usar la opción -b, que sin embargo permite establecer un nombre diferente para la sucursal remota.
	Ex:
	git checkout -b mytest origin/test
	# -b significa: "new branch"

	Ahora la rama de prueba remota es rastreada localmente por mytest branch (o por la rama de prueba en el primer uso de git-branch), lo que significa que cada vez que estoy trabajando en la rama de prueba local (porque he realizado una 'prueba de verificación' ) y hago un git-pull (N.B. PULL no FETCH), Git automáticamente sabrá extraer los datos de la rama de prueba/origen remoto.

	Esto se denomina "Tracking (remote) Branches".

	Podemos ver qué sucursales remotas se rastrean localmente (y por qué sucursal local) ejecutando:
	git branch -vv # double verbose (la rama rastreada remota aparecerá entre [] después del código de referencia de la versión)
	git branch -avv # agrega la lista de las sucursales remotas a la salida anterior

	Ref: http://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

6) Actualizar cualquier sucursal con la versión remota
	Si estamos trabajando en una rama (p. ej., test) y queremos actualizar otra rama (p. ej., master), debemos:
	a) verifique la rama 'master' (git checkout master)
	b) extraer del origin/master (git pull) (siempre que el maestro esté rastreando el origin/master)
	NOTA: Si queremos tomar SU versión (es decir, la versión remota, sin lidiar con conflictos) debemos hacer:
		git pull -s recursivo -X suyo [origen/maestro]
	EQUIVALENTE A:
		git pull --strategy-option suyo [origen/maestro]
	O, si ya se hizo un pull y se encontraron conflictos, podemos resolver TODOS los conflictos tomando su versión haciendo:
		git checkout --theirs .
		git add .
	O, si queremos resolver conflictos para archivos particulares:
		git checkout --theirs path/to/file (se aceptan comodines)
	Tenga en cuenta que el opuesto de --theirs es --ours.
	Ref: https://stackoverflow.com/questions/10697463/resolve-git-merge-conflicts-in-favor-of-their-changes-while-a-pull

	Luego podemos volver a la rama original en la que estábamos trabajando (por ejemplo, 'test') con un nuevo comando git checkout.

7) Actualizar una sucursal remota con una versión local
	Use git push de la siguiente manera para permitir diferentes nombres de sucursales en local y remoto (por ejemplo, debido al seguimiento de sucursales con diferentes nombres locales y remotos):
	git push origin <local-branch>:<remote-branch>

	Ex:
	git push origin test:danieltest

	Ref: documentación de git-push


6.- Fusionar(merge) MASTER con un rama(branch) TEST
--------------------------------------------------
	Ref: http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging
	Después de trabajar en una rama de prueba (supuestamente llamada PRUEBA) y de haber probado que todo funciona bien y de haber confirmado los cambios, estamos listos para fusionarnos con la rama MAESTRA. Para hacerlo:
	
	1) Consulte la rama MASTER
	git checkout master
	
	2) Fusionarse con la rama TEST
	git merge test

	3) Eliminar la rama TEST (opcional)
	git branch -d test

	NOTA 1: Es posible que no sea posible hacer la combinación anterior directamente porque puede haber algunos conflictos, que primero deben resolverse. Para ver cómo hacer esto, consulte la página de referencia anterior.

	NOTA 2: Esto no es lo mismo que RESPOSITIONING (que es lo que podemos estar buscando), p. cambie la posición de la rama maestra a la rama de prueba actual después de que hayamos probado que la rama de prueba funciona bien. Para hacerlo, use 'git branch -f master test' (ver más abajo "REPOSICIÓN").

	NOTA 3: Para eliminar una rama remota llamada test, use git push de la siguiente manera:
	git push origin --delete test
	Ref: http://www.gitguys.com/topics/adding-and-removing-remote-branches/


7.- Volver a una versión anterior del PROYECTO (es decir, un compromiso anterior)
-------------------------------------------------- ---------------------
Ref: http://stackoverflow.com/questions/4114095/revert-to-previous-git-commit
1) Si quiero ir al anterior desde una confirmación anterior, use git checkout <commit>.

2) Si solo quiero volver a una confirmación anterior y PERDER cambios locales, use 'git reset --hard'.
	# Esto destruirá cualquier modificación local.
	# No lo hagas si tienes trabajo no comprometido que quieres conservar.
	git reset –hard HEAD

	(tenga cuidado porque parece que esto puede evitar que presione más adelante SI previamente había presionado mis confirmaciones antes del restablecimiento completo ... Para obtener más información, consulte los comentarios a la segunda respuesta en la referencia anterior)

	NOTA: Para ver dónde se coloca HEAD, use 'git show-ref --head'.

	Después de hacer esta operación, los archivos en la copia local del repositorio se habrán actualizado a la versión de los repositorios dada por la posición HEAD, SIEMPRE que se haya realizado un cambio en el archivo w.r.t. la versión HEAD. Sin embargo, tenga en cuenta que la fecha de modificación de cualquier archivo modificado será el momento de ejecución del comando git-reset. (esto es un poco inesperado, pero la razón es que las fechas de los archivos se establecen en las fechas en que se obtiene la información del repositorio)

	Aparentemente, esto también se puede hacer con 'git rebase' con la opción --onto...? -->¡NO! (ver ACTUALIZAR en la siguiente línea)
	ACTUALIZACIÓN: (01/09/2015) Después de leer la documentación de git-rebase, ***la respuesta a la pregunta anterior es NO**. La opción rebase --onto es útil para hacer que una rama *parece* que se bifurcó desde un punto que es diferente del punto de bifurcación actual. ¡El "aspecto como si" significa que toda la información sobre las diferencias entre las confirmaciones se actualiza en función del nuevo punto de bifurcación!
	Ver:
	http://git-scm.com/docs/git-rebase
	http://stackoverflow.com/questions/5471174/git-move-branch-pointer-to- different-commit

	Consulte también el siguiente enlace para obtener una muy buena explicación de lo que significa git-reset y su diferencia con git-revert (que se usa para eliminar una confirmación anterior, a la que también se hace referencia en el elemento 102 a continuación):
	https://www.atlassian.com/git/tutorials/undoing-changes

	*** REPOSICIONAR (o "rebase" en mi idioma) UNA RAMA (tarea muy común cuando queremos hacer master point a la rama actualmente en funcionamiento, ej. daniel) ***
	Si solo necesito reposicionar una rama (p. ej., rama maestra) a otra confirmación, use git branch -f (p. ej., git branch -f master test) (consulte también el elemento (4) a continuación) (tenga en cuenta que esto también funciona para reposicionar a una rama remota, por ejemplo, git branch -f master origin/master).

	ACTUALIZACIÓN-2019/10/30: TENGA EN CUENTA, sin embargo, que git-rebase es un comando MUY PODEROSO en la medida en que se llama el comando Swiss Army Knife (ref: seminario web de Git Tower al que se hace referencia en la parte superior de este archivo entregado el 30 de octubre -2019).

3) Si quiero mantener el historial de cambios, consulte la página de manual de git-revert (http://schacon.github.io/git/git-revert.html) o git-checkout.

4) Si solo necesitamos mover una rama a una confirmación diferente...
	Usar:
	git branch -f <branch> <new-tip-commit>

	donde <new-tip-commit> puede ser un nombre de sucursal o el código hash que hace referencia a la sucursal, y puede ser una sucursal remota.

	Ex:
	git branch -f master daniel
	git branch -f master origin/master
	(El segundo caso es útil cuando, por ejemplo, queremos volver de maestro a una rama de origen/maestro que está detrás de él, es decir, en el pasado)

	Notas:
	- opción -f significa "Forzar". De la documentación:
		"-f: restablece <branchname> a <startpoint> si <branchname> ya existe. Sin -f, git branch se niega a cambiar una rama existente".
	- para que este comando tenga éxito, NO DEBEMOS pararnos en la rama cuya posición queremos mover.
	- si omitimos <new-tip-commit>, la sugerencia de rama se moverá a HEAD

	Ver también:
	git update-ref

	Ref: http://stackoverflow.com/questions/5471174/git-move-branch-pointer-to- different-commit


8.- Volver a una versión anterior de un ARCHIVO
---------------------------------------------------------
Ref: http://stackoverflow.com/questions/215718/reset-or-revert-a-specific-file-to-a-specific-revision-using-git
RESPUESTA 1:
# Usar git checkout
# Suponiendo que el hash de confirmación que queremos es abcde:
git checkout abcdr file/to/restore
## VEA A CONTINUACIÓN CÓMO COMPROBAR UN ARCHIVO CON OTRO NOMBRE (¡para que no anulemos la versión actual! --usa git-show)

# Tenga en cuenta que se usa un comando similar para volver a la versión original de un archivo cuando estamos trabajando en la rama actual
# y me gustaría deshacer todos los cambios que hicimos localmente. El comando es:
git checkout -- file/to/restore # Este comando en realidad se muestra en la información auxiliar disponible con el comando 'git status'.

RESPUESTA 2: ¡Esto también explica para qué sirven las RAMAS!
# Podemos revisar rápidamente los cambios realizados en un archivo usando el comando diff:
git diff <commit hash> <nombre de archivo>

# Luego, para revertir un archivo específico a ese compromiso, use el comando de reinicio:
# Es posible que necesitemos usar la opción --hard si tenemos modificaciones locales.
git reset <commit hash> <nombre de archivo>

# Un buen flujo de trabajo para administrar los puntos de trabajo es usar etiquetas para marcar claramente los puntos en nuestra línea de tiempo.
git tag v0.4.0
# Empuje la etiqueta al repositorio remoto
git push origin v0.4.0

# Para eliminar una etiqueta remota
# Ref: https://nathanhoad.net/how-to-delete-a-remote-git-tag/
git tag -d v0.4.0
git push origin :refs/tags/v0.4.0

# Para eliminar una etiqueta remota
# Ref: https://nathanhoad.net/how-to-delete-a-remote-git-tag/
git tag -d v0.4.0
git push origin: refs/tags/v0.4.0

# Comprobar la confirmación a la que apunta una etiqueta
# Ref: https://stackoverflow.com/questions/1862423/how-to-tell-which-commit-a-tag-points-to-in-git
git show-ref --etiquetas

# Para trabajar en una nueva línea de desarrollo desde un compromiso anterior
# (es decir, supongamos que comenzamos a trabajar en algo nuevo que pensamos que sería fácil
# y luego darse cuenta de que no es fácil... en ese caso queremos mover todo nuestro trabajo que hemos hecho
# hasta ahora en ese nuevo desarrollo a una nueva sucursal, SIN cambiar el estado de la sucursal que tengo
# estado trabajando hasta ahora...), diverge una rama desde ese punto anterior en el tiempo.
# Para hacer esto, use el práctico comando de pago:
git checkout <commit hash>
git checkout -b <nuevo nombre de rama>
Ref: https://stackoverflow.com/questions/2569459/git-create-a-branch-from-unstaged-uncommitted-changes-on-master

# Luego podemos volver a basar eso en nuestra línea principal (rama principal) cuando estemos listos para fusionar los cambios realizados en <mi rama>:
git checkout <mi rama>
git rebase master
git checkout master
git merge <mi rama>
## Este último paso de combinación puede resultar en un avance rápido si <mi rama> está por delante del maestro con una ruta directa.
## Después del último paso de combinación, todavía estamos trabajando en la rama principal.

# Para retirar una versión anterior de un archivo con OTRO NOMBRE
# Usar git-show
git show 21b0fbf66185a49473e4f8195fed3c2542275ef2:ruta/al/archivo/04-DAT-TransformacionVariables.sas > ruta/al/archivo/04-DAT-TransformacionVariables_old.sas
Ref: https://stackoverflow.com/questions/888414/git-checkout-older-revision-of-a-file-under-a-new-name

# Para encontrar un compromiso
# Use git-show y add en --stat asi evitar mostrar toda la información de confirmación de diferencias
# Referencia: https://stackoverflow.com/questions/14167335/find-commit-by-hash-sha-in-git
git show dea48e8961 --stat

9.- Ver los archivos que están RASTREADOS (es decir, están en el árbol de trabajo)
-------------------------------------------------- ---------------
Ref: http://stackoverflow.com/questions/15606955/how-can-i-make-git-show-a-list-of-the-files-that-are- being-tracked
# Opción 1: simple y rápido
git ls-files

# Opción 2: más complicada pero con más flexibilidad e información
git ls-tree -r master --name-only

## -r: recurse en directorios en el árbol
## --name-only: muestra solo el nombre del archivo, sin códigos extraños delante de ellos.

Si necesitamos dejar de rastrear archivos, use rm --cached
Ex:
git rm --cached <files>

# o hacerlo recursivamente sobre los archivos de un directorio
git rm --cached -r <dir>


10.- Ver TODO el árbol de trabajo (incluidas las ramas que están fuera de alcance)
-------------------------------------------------- ----------------------
Ref: https://git-scm.com/book/en/v2/Git-Tools-Rewrite-History (lo encontré aquí, aunque no es el tema principal)
Utilice gitk --all --date-order.
Esto también debería mostrar ramas que normalmente no se ven desde nuestra rama actual (como una rama remota desviada que se rastrea a la rama local, por ejemplo, remotos/origen/daniel que se rastrea a la rama local 'daniel').

El comando git para ver el historial de confirmaciones es git-log.
Ex:
git log --pretty --graph
(esto muestra las líneas a la izquierda con las diferentes rutas de confirmación y se fusiona como lo vemos en gitk)


11.- Ver las diferencias históricas de un solo archivo
-------------------------------------------------- --
Ref: https://stackoverflow.com/questions/278192/view-the-change-history-of-a-file-using-git-versioning
Usar:
git log -p --follow -- file
# --follow sigue el archivo a través de sus cambios de nombre
(Tenga en cuenta que, como se sugiere en la primera respuesta en el enlace anterior, 'gitk --follow file' NO funciona, es decir, NO muestra más el archivo si se cambió el nombre del archivo en su historial)

Comprender la salida de git-log o git-diff: (respuestas muy claras dadas)
https://stackoverflow.com/questions/2529441/how-to-read-the-output-from-git-diff

********************************************* Cosas básicas **********************************************

12.- Mira cómo cambió HEAD con el tiempo
--------------------------------------------------
Usa 'git reflog'.

Esto puede ser útil para, p. deshacer un cambio incorrecto como 'git reset --hard' (es decir, descartar confirmaciones que no queríamos) o eliminar una rama que no queríamos eliminar.

Ref: Seminario web el 30 de octubre de 2019 por Git Tower al que se hace referencia en la parte superior de este archivo.

****************************************** Material adicional ***** ***********************************
100.- Cambiar mensajes de commit en commits pasados
--------------------------------------------
Ref: https://git-scm.com/book/en/v2/Git-Tools-Rewrite-History
Esto es parte de reescribir el historial y se puede lograr usando el comando git-rebase en modo interactivo (-i).
Para obtener más información, consulte la referencia anterior, que está bastante bien explicada.
NOTA: (2015/09/22) Hoy probé las instrucciones en la sección "Cambiar varios mensajes de confirmación" en el proyecto IOLS y ¡funcionó bastante bien! Y en realidad es bastante fácil, aunque puede parecer críptico en algún momento.
Como recuerdo, corrí:
	git rebase -i HEAD~3
(-i entra en el modo interactivo)

y luego edité el archivo que se abre de acuerdo con la confirmación que quiero cambiar.
Luego seguí las siguientes instrucciones (que aparecen más abajo en la sección antes mencionada):
<<
Debe editar el script para que se detenga en la confirmación que desea editar. Para hacerlo, cambie la palabra seleccionar por la palabra editar para cada una de las confirmaciones después de las cuales desea que se detenga el script. Por ejemplo, para modificar solo el tercer mensaje de confirmación, cambie el archivo para que se vea así:
editar f7f3f6d cambió un poco mi nombre
pick 310154e formato README actualizado y culpa añadida
elegir a5f4a0d añadido cat-file
>>

Recuerde que las confirmaciones se enumeran en orden inverso w.r.t. cómo los vemos en gitk, es decir, el compromiso más antiguo aparece primero.
También tenga en cuenta que el comando "pick" significa: no cambie nada sobre la confirmación.
Cambie "pick" a "reword" para cambiar la redacción de una confirmación. Si necesitamos modificarlo, cámbielo a "edit".

ACTUALIZACIÓN-2019/10/30: vea ejemplos en el seminario web de Git Tower mencionado en la parte superior de este archivo entregado el 30 de octubre de 2019.

101.- Guarda el trabajo actual y trabaja en otra cosa
-------------------------------------------------- -
Ref: http://www.gitguys.com/topics/temporarily-stashing-your-work/
Use git-stash (stash significa "almacenar") para guardar el estado actual del proyecto en un lugar seguro para volver más tarde.

Ex:
	git stash
equivalente a:
	git stash push

Esta herramienta puede ser útil si estamos en medio de algo y no queremos cometerlo porque todavía estamos trabajando en eso, pero necesitamos trabajar en otra cosa antes de terminar.

Para restaurar el trabajo escondido (llamado "WIP" por Git --Work In Progress) simplemente podemos ejecutar:
	git stash pop

que es la operación inversa a 'git stash push'. Tenga en cuenta que el estado oculto se elimina de la lista oculta.
que es equivalente a:
	git stash stash@{0}
donde 0 es el número de revisión (el último alijo es 0, el anterior es 1, etc.).

Tenga en cuenta que una vez (abril de 2016) tuve dificultades para volver al trabajo guardado ya que la cabeza no parecía volver al alijo original, sino que apareció una nueva rama con cambios, incluso cuando ejecuté 'git stash apply' ( aunque 'git stash apply' es lo mismo que 'git stash pop' pero sin eliminar el estado oculto de la lista oculta. El problema no se resolvió incluso al crear una rama para el trabajo oculto con 'git stash branch'... I Estoy un poco perdido aquí.

Para ver la lista de uso de trabajo escondido:
	git stash list
Para ver las diferencias entre el último alijo y la copia de trabajo actual, use:
	git stash show

Árbitro:
https://git-scm.com/book/no-nb/v1/Git-Tools-Almacenamiento
https://git-scm.com/docs/git-stash

102.- Eliminar un commit anterior
------------------------------
Ref: https://www.atlassian.com/git/tutorials/undoing-changes
Ref: http://sethrobertson.github.io/GitFixUm/fixup.html (muy buena referencia que es muy intuitiva)
Use git-revert (¡que es diferente de git-reset!) para eliminar una confirmación (generalmente una confirmación defectuosa) del historial.

Esto es lo que dice el primer enlace (deshacer cambios) en la sección "git reset":
<<
Si git revert es una forma "segura" de deshacer los cambios, puede pensar en git reset como el método peligroso. Cuando deshaces con git reset (y las confirmaciones ya no son referenciadas por ningún ref o reflog), no hay forma de recuperar la copia original, es un deshacer permanente
...
Mientras que la reversión está diseñada para deshacer de forma segura una confirmación pública, **git reset** está diseñado para **deshacer cambios locales**.
>>

NOTAS:
- El primer enlace anterior (deshacer cambios) tiene una MUY buena explicación (también gráfica) de cuáles son las implicaciones de esto y cuál es la diferencia con git-reset.
- El segundo enlace anterior (fixup.html) también parece bastante útil para saber cómo proceder en función de nuestra situación.
- En un momento (al probar la opción de fusión sin avance rápido en el proyecto IOLS) quise eliminar todas las confirmaciones que usé para probar esa funcionalidad (ya que se hizo en archivos ficticios). Para lograr esto, verifiqué la rama daniel (una confirmación anterior) y luego eliminé la rama de prueba que había creado para probar la funcionalidad ejecutando 'git branch -D test'. Parece que esto hizo que esos compromisos (que son en el futuro w.r.t. daniel) desaparecieran.

103.- Sobre líneas de código eliminadas por otros desarrolladores
--------------------------------------------------------------------------------
Mientras trataba de entender cómo hacer que git-merge me advierta cuando una combinación hace que desaparezca una línea en mi código (porque el otro desarrollador eliminó esa línea), me encontré con la siguiente discusión en stackoverflow: http://stackoverflow.com/questions /4404444/cómo-culpo-una-línea-eliminada.
De hecho, creo que, conceptualmente, este tipo de fusión NO es un conflicto y, por lo tanto, debe hacerse en silencio sin ninguna queja de conflicto (de hecho, la opción de fusión sin avance rápido que me sugirió Yi Cheng en EARL-2015 no funcionó ). Por lo tanto, lo que estoy buscando quizás sea una herramienta que me diga cuándo se eliminó una línea determinada de mi código, y esto es lo que se analiza en el enlace anterior.

104.- Claves SSH
--------------
Para trabajar con un repositorio web (por ejemplo, GitHub) generalmente necesitamos una clave SSH. Para obtener más información, consulte OneNote -> Git y GitHub -> GitHub HowTo.
Tenga en cuenta que las claves SSH se generan ejecutando:
ssh-keygen -t rsa -C "your@email"
que genera dos archivos id_rsa (clave privada) e id_rsa.pub (clave pública) en ~/.ssh, donde ~ es el directorio de inicio en bash equivalente a Linux (por ejemplo, C:\Users\lundinmatlab).

105.- Almacenar un repositorio local en GitHub
----------------------------------------
Si queremos crear una copia remota de un repositorio local y almacenarlo en GitHub, debemos realizar los siguientes pasos:
1) Crear un nuevo repositorio vacío en GitHub
2) Configure el repositorio remoto de nuestro repositorio local en el GitHub recién creado ejecutando Git Bash desde la ubicación del repositorio local:
git remote add origin
Ex:
git remote add origin git@github.com:your@user/Git.git
3) Empuje la rama maestra (y cualquier otra rama de interés desde el repositorio local al repositorio remoto, y configure el seguimiento ascendente:
git push --set-upstream origin master

¡HECHO!
****************************************** Material adicional ***** ***********************************