2

Librería de comandos de git vistos en clase (con descripción y ejemplos)

¡Hola! Les comparto aqui la lista de comandos que compilé mientras hacia el curso.
.
Tambien dejé unos extras al final, como la parte de configurar llaves SSH en local y como crear alias en Git.
.
Espero que les sirva 😃
.

Indice

1. Comandos básicos
2. Comandos para trabajar con ramas
3. Comandos para trabajar con repositorios remotos
4. Utilidades y otros comandos
5. Comandos para casos de emergencia
6. Cómo configurar llaves SSH en local
7. Cómo crear alias en Git
8. Cómo invocar manuales completos sobre los comandos

1. Comandos básicos

git init
Crea la carpeta .git/ para iniciar el repositorio.
.
Ojo, solo tomará en cuenta los archivos y directorios que compartan el mismo directorio que la carpeta .git/
.
Escritura:
Git init
.
Ejemplo:
Git init
.
git add
Agrega los archivos que indiques a continuación al area de staging.
.
Puedes indicar archivos puntuales, o incluso carpetas.
.
Escritura:
Git add + archivos
.
Ejemplo:
Git add .
.
Agrega todos los archivos en el directorio actual.
.
Git commit
Crea una nueva versión en el repositorio con todos los cambios guardados en el area de staging.
.
Ojo, si no agregas un mensaje con “-m”, entonces la terminal te enviará a vim o a nano para escribir el mensaje.
.
Escritura
Git commit
.
Extensiones:

  1. “-m” + mensaje: agrega un mensaje al commit sin necesidad de ir a nano ni a vim.
  2. “-a”: envía todos los cambios en el directorio local al area de staging y procede con un commit, todo en el mismo comando.
  3. “–amend”: Anexa todos los cambios en staging al commit anterior. Tambien te permite cambiar el mensaje del commit anterior. (ojo, no se combina con la extensión “-a”. Asegurate de hacer git add antes de este commit. Este se usa para emergencias, cuando enviaste un commit por accidente sin incluir cambios importantes).
    Ojo, solo funciona con los archivos que previamente hayan recibido un git add. Esta extensión no incluye archivos nuevos.

Ejemplo:
Git commit -m "mi primer commit"
.
Crea un commit con el mensaje “mi primer commit”.
.
Git commit -am "mi segundo commit"
.
Hace un git add para todos los archivos que hayan recibido un git add antes, y luego ejecuta el commit. (Ojo, no hace el add de archivos nuevos. Tienes que hacer el git add antes para que lo incluya).
.
Git commit --amend
Envía los cambios que tengas en staging con el commit anterior. (recuerda hacer git add antes).
.
Git config
Te permite hacer configuraciones a git.
.
Puedes hacer cambios solo al repositorio local donde estes parado, o a todos los repositorios actuales y futuros con la extensión “–global”
.
Ojo, si lo usas sin extensión ni parametros, este solo mostrará una lista con las extensiones disponibles para uso.
.
Escritura
Git config + configuración
.
Extensiones

  1. “–list”: muestra la lista de configuraciones ya establecidas.
  2. “–global”: permite hacer cambios de configuración globales que se apliquen a todos los directorios en el futuro.

Ejemplo:
Git config --global user.name "Mi nombre"
.
Git config user.email "mi email"
.
git status
Muestra el estatus actual del repositorio donde estas parado en la terminal.
.
Especificamente muestra:

  1. La rama donde estas parado
  2. Los cambios en archivos que aún no estan en Staging area.
  3. Los archivos nuevos que aún no estan en Staging area.
  4. Los archivos borrados que aún no han sido reportados al Staging area para sacarlos del siguiente commit.

Escritura
Git status
.
Ejemplo
Git status
.
Git log
Muestra el historial de commits en la rama actual, incluidos sus hash (los id de cada commit) y sus tags.
.
Ojo, se pueden aplicar filtros al log. Puedes leer el man git log para verlos.
.
Escritura
Git log + extensiones
.
Extensiones

  1. “–stat”: muestra en detalle los cambios ocurridos en cada archivo tras cada commit.
  2. “–all”: Muestra todos los commits que han ocurrido. Esto ayuda porque en ocasiones git log no muestra todo dependiendo de que branches han ocurrido.
  3. “–graph” muestra de forma grafica con “/” “|” “” el flujo de trabajo con las ramas a lo largo del proyecto
  4. “–oneline” muestra solo una línea por cada commit. Útil para un seguimiento puntual a la historia de un proyecto largo.
  5. “–decorate” muestra los nombres de las ramas en el lugar donde terminan. (git log está configurado por defecto en --decorate=short; pero tambien está =no, =full y =auto)
  6. “-S” + Termino entre comillas: busca los commits donde el termino que indiques fue relevante.

Ejemplo 1
Git log
.
Muestra el log
.
Ejemplo 2
Git log --graph --oneline
.
Muestra un log simplificado con un arbol de branches a la izquierda.
.
Ejemplo 3
Git log -S "cabecera"
.
Muestra los commits donde el termino “cabecera” fue relevante.
.
Git restore
Descarta los cambios recientes en los archivos que no se encuentren en el area de Staging, restaurandolos a como estaban en el último commit.
.
Escritura
Git restore + archivo
.
Ejemplo
Git restore historia.txt
.
Git rm
Al igual que el comando rm, borra el archivo que indiques a continuación tanto del directorio local como de la base de datos de git.
.
Su nombre queda registrado en los commits, pero su información quedará borrada. Ya no podrás acceder a él ni con un checkout.
.
Ojo, no funciona sin una extensión.
.
Escritura
Git rm + extensión + archivos
.
Extensiones

  1. “–cached”: borra el archivo del directorio local y del repositorio, pero conserva la versión que esté actualmente guardada en el staging area (si es que hay una).
  2. “-f” o “–force”: borra todo lo relacionado al archivo (excepto el recuerdo de su existencia en los git log).

Ejemplo
Git rm --force historia.txt
.
Git diff
Compara dos versiones y los cambios que ocurrieron desde la primera hasta la segunda.
.
Ojo, git diff analizará tomando la primera versión que escribas como punto de partida. Asi que atento al orden en el que escribes las versiones (primero la mas vieja, segundo la mas nueva).
.
Ojo, puedes usar HEAD en lugar del tag para referirte al HEAD.
.
Escritura
Git diff + tag version vieja + tag versión nueva
.
Ejemplo
Git diff 31edb48c1566f59e211f74e4d86b35a7fdf12e14 fba45774b74bf651f5f2c33e8bc6d4fd4227460d
.
Git show
Muestra, de forma muy detallada, los cambios ocurridos entre el commit actual y el commit anterior de un archivo, rama, o commit.
.
Ojo, sin no indicas parametros, entonces por defecto muestra el commit de HEAD
.
OJO, Git show se puede combinar con otros argumentos para mostrar otras cosas. Ej: git show-branch, git show-ref.
.
Escritura
Git show + archivo/branch/commit
.
Ejemplo
Git show historia.txt
.
Git show-branch
.
Git show-ref --tags
.

2. Comandos para trabajo con multiples ramas

.
Git checkout
Mueve el HEAD a un commit diferente.
.
HEAD es el nombre de la versión que actualmente puedes ver desde la consola. Por lo tanto, git checkout te permite moverte entre ramas y commits.
.
Tambien puedes revisar archivos puntuales de otras versiones. Pero recuerda que si haces esto (o borras un archivo) y luego haces un commit, entonces estarás “detached from master”.
.
OJO: Si cambias de rama pierdes todos los cambios que no hayas guardado. Esto aplica al staging area y al directorio local.
.
NO CAMBIES DE RAMA SIN ANTES HACER UN COMMIT
.
Ojo, puedes tambien recoger archivos puntuales de otras versiones si escribes el nombre del archivo luego del commitID.
.
Ojo, en ocasiones, esto te sacará del HEAD y te moverá temporalmente a una rama ficticia sin nombre para que no dañes nada importante (error: detached from HEAD)
.
Para seguir trabajando en este caso, debes hacer un git checkout HEAD para volver al HEAD, o crear una nueva rama para hacer experimentos con el archivo viejo.
.
Escritura
Git checkout + archivo/rama/commit
.
Extensiones

  1. “-b” + new-branch: crea una nueva rama y te desplazas hacia ella.

Ejemplos
Git checkout 375ac62
.
Git checkout main
.
git checkout 38ef0beb4828ca3dd7cd0c9fa001aea9f5c4ed38 historia.txt
.
Git checkout -b hotfix
.
Git branch
Crea una nueva rama que inicie a partir del commit indicado.
.
Ojo, si no indicas un commit, entonces la nueva rama partirá por defecto de la posición actual del HEAD.
.
Ojo, si no introduces parametros, entonces el comando te mostrará la lista de ramas del repositorio.
.
Escritura
Git branch + nombre de la nueva rama + tag del commit de partida
.
Extensiones

  1. “-d”: borra la rama que indiques a continuación.
  2. “-m” + branch + new-name: cambia el nombre de la rama que indiques a continuación por el que indiques segundo. (esto se usa para cambiar el nombre de master a main).
  3. “-r”: lista las ramas de los repositorios remotos
  4. “-a”: lista todas las ramas, incluyendo las locales y las remotas.

Ejemplo
Git branch
.
Git branch development
.
Git branch development 8fbb4a54e3b6098dda62ddc9e44d8ca4bd33b4e7
.
Ejemplo 2
Git branch -m master main
.
Cambia el nombre de la rama “master” por “main”.
.
Ejemplo 3
Git branch -D development
.
Borra la rama development
.
Ejemplo 4
Git branch -r
.
lista las ramas de los repositorios remotos asociados al local.
.
Ejemplo 5
Git branch -a
.
Lista todas las ramas del repositorio, incluyendo las locales y las remotas.
.
git merge
Crea un nuevo commit en la rama donde estas parado, y absorbe los datos de la rama que indiques en el comando para combinar ambas en algo nuevo.
.
Git mezcla las ramas y toma los cambios más recientes en cada archivo.
.
Ojo, como es un commit, debes dejar un mensaje al hacer el Merge. (puedes hacerlo en nano cuando introduscaz el comando, o con la extensión “-m” más el mensaje entre comillas).
.
Ojo, cuando haces un Merge, combinas el log de ambas ramas. Es decir, cuando hagas un git log podrás ver los commits de las dos ramas que combinaste.
.
Escritura
Git merge + branch secundaria a combinar
.
Extensiones

  1. -m “mensaje”: Una forma rápida de introducir el mensaje sin abrir nano.
  2. –abort: Te permite abortar un merge que causó conflictos.

Ejemplo
git merge cabecera -m "merge de master con cabecera"
.
(hecho desde master)

Comandos para trabajo con repositorios remotos

Git remote
Se utiliza para conectarse con repositorios remotos.
.
Si se usa sin ninguna otra información, entonces muestra una lista de los repositorios remotos a los que está conectado.
.
Ojo, llamar al repositorio remoto “origin” es un estandar de la industria. Pero puede llamarse como sea.
.
Escritura
Git remote
.
Extensiones

  1. “add” + remote-repo-name + URL: agrega la dirección de un repositorio remoto que git identificará con “remote-name”, y que se encuentra en la URL que indicaste.
    Puedes usar esta extensión para conectar tus repositorios locales con repositorios remotos en github a través de HTTPS.
  2. “-v”: muestra los remotos con sus URL (y los comandos “fetch” y “push” si están disponibles).
  3. “set-url + remote-repo-name + new-URL”: Permite cambiar la URL del repositorio remoto al que estes conectado.

Ejemplo
Git remote add origin https://github.com/mistofjoy/practiceblog.git
.
Git remote add origin [email protected]:mistofjoy/practiceblog.git
.
git remote set-url origin url-ssh-del-repositorio-en-github
.
git push
Permite empujar el contenido de una rama del repositorio local a un repositorio remoto.
.
Ojo, para que funcione tienes que iniciar sesión en github desde la consola luego de insertar el comando.
.
OJO: si empujas una rama que ya existe en el repositorio remoto, github te va a pedir que jales la rama antes de hacer un push (con pull o fetch). Esto es para que no dañes la versión que está en el remoto, sino para que construyas sobre ella.
.
Escritura
Git push + remote-name + branch-to-push
.
Extensiones

  1. “–tags” sustituye a la rama en el comando, y permite empujar los tags al servidor remoto.

Ejemplo
Git push origin master
.
Git push origin --tags
.
git pull
Permite jalar a tu repositorio local el contenido de una rama de un repositorio remoto que ya hayas configurado con git remote.
.
Ojo, git pull es una combinación de git fetch y git merge. No hay problema si jalas una rama que no existe en tu repositorio local. Pero si jalas una rama que coincide con tu repositorio local, entonces el comando intentará hacer un merge entre ellas.
.
Ojo, si la rama que intentas jalar coinciden en nombre, pero no en historia (log de commmits), entonces habrá un error que impedirá ejecutar el comando.
.
Para ignorarlo, tienes que usar la extensión “–allow-unrelated-histories”
.
Ojo, tienes que hacer esto para actualizar el repositorio cada vez que ocurran cambios en el repositorio remoto que no tengas en el local.
.
Ojo, es una buena práctica hacer esto con regularidad para que tu repositorio esté al día, en especial antes de hacer un commit y un push.
.
Escritura
git pull + remote-name + branch to pull
.
Extensiones

  1. “–allow-unrelated-histories”: Permite jalar una rama remota que coincide en nombre con una rama local, aunque estas no coincidan en historia.

Ejemplo
git pull origin main
.
Git pull origin main --allow-unrelated-histories
.
Git tag
Maneja etiquetas que podemos asignar a nuestros commits.
.
Ojo, si solo ingresas el comando git tag, podrás ver la lista de tags en tu repositorio local, y se mostrarán en todos los git log en el futuro.
.
Tambien, si ingresas git show-ref --tags, podrás ver una lista con los tags en tu repositorio local junto a la referencia al momento de crear el tag.
.
OJO, si borras un tag, la única forma de sacarlo de github es con un push especial del tipo git push origin :refs/tags/tag-name
.
Escritura
Git tag + extensión + nombre del tag + ID del commit
.
Extensiones

  1. “-a” + tag-name + commitID: crea un nuevo tag con el nombre que indiques y lo asigna al commit que indiques.
  2. “-d” + tag-name: Borra un tag en el repositorio local
  3. “-m” + message: agregas un mensaje al tag (si, colocar etiquetas es igual que hacer un commit. Si no pones uno te manda a nano T-T).

Ejemplo crear un tag
Git tag -a v0.1 -m "resultado de las primeras clases del curso" 375ac62
.
Ejemplo borrar un tag y sacarlo de github
Git tag -d inicio
->
Git push origin :refs/tags/inicio
.
gitk
Abre una interfaz de un software de git que te muestra con más detalle el arbol de commits del directorio de trabajo.
.
Ojo, para ejecutarlo desde wsl2, tienes que ejecutarlo con wslview. (es posible que debas tenerlo instalado en windows para que funcione).
.
Ejemplo
wslview gitk
.
Git clone
Permite clonar un repositorio remoto en un directorio local.
.
Ojo, esto solo trae la rama main al directorio local. Para traer las demás tienes que hacer un git pull de las que desees.
.
Por eso si, trae toda la historia de commits de la rama main. Y tambien trae la dirección de los remote-repos, junto a cualquier otra
.
Ojo, si el repositorio es público, puedes clonarlo sin que te pida usuario ni contraseña.
.
Ojo, Este comando crea una copia de la carpeta que contiene al repositorio remoto dentro del directorio donde se ejecutó el comando.
.
(es decir, si estoy en proyecto1/ y ejecuto el git clone para clonar un repositorio llamado hyperblog, entonces aparecerá proyecto1/hyperblog/).
.
Escritura
Git clone + URL-remote-repo
.
Ejemplos
Git clone [email protected]:mistofjoy/practiceblog.git

4. Utilidades y otros comandos

Git rebase
Pega los commits de una rama en la punta de otra rama.
.
Esto permite hacer cambios silenciosos en una rama sin que quede registro de que usaste otra rama para arreglarlos.
.
OJO, Esto reescribe la historia de commits para que parezca que una rama como bugfix partió del último commit de master, aunque no haya sido asi. Por eso es una mala práctica.
.
OJO, esto solo se usa en local.
.
Ojo, primero se debe aplicar el rebase en la rama con los cambios que deseas pegar, y luego en la rama objetivo.
.
Ojo, esto genera los siguientes problemas:
1. La historia de commits y responsables queda alterada
2. Si la rama objetivo avanza mucho antes del rebase, pueden ocurrir muchos conflictos

Escritura
Git rebase + Rama-a-borrar
.
Ejemplo
Git rebase main
(ejecutado desde la rama experimento)
.
(luego)
.
Git rebase experimento
(ejecutado desde la rama main)
.
Esto reescribe la historia de commits para que parezca que la rama “experimento” partió desde el ultimo commit que recibió “main”. Aún si esto no fue asi.
.
De hecho, si haces un git log --graph, verás que experimento nunca fue una rama diferente, sino que “main” y “experimento” siempre fueron la misma rama.
.
Si luego borras la rama “experimento” con git branch -D experimento, la rama desaparecerá de todo el registro.
.
Git stash
Guarda en una memoria de git los cambios no agregados al momento de usar el comando.
.
Esto te permite conservar los cambios, con el fin de no perderlos si necesitas consultar otra rama antes de hacer el commit.
.
Mas tarde puedes recuperar lo que guardaste en el stash para completar los cambios y luego hacer el commit.
.
Este es un comando muy usado en proyectos complejos.
.
Ojo, cuando usas git stash, todos los cambios se guardan en el stash y tu rama regresa a la última versión del HEAD.
.
Ojo, cuando reclamas los cambios con git stash pop, estos desaparecen de la memoria del stash
.
Escritura
Git stash + extensión
.
Extensiones

  1. list: muestra una lista con todo lo que tenemos guardado en el stash.
  2. pop: recupera los cambios que tenías guardados en el stash
  3. Branch + branch-name: Te mueve a la rama que indiques y libera los cambios en el stash (si escribes el nombre de una rama que no existe, entonces crea la rama).
  4. Drop: borra los cambios guardados en el stash.

Ejemplos
Git stash
.
guarda los cambios actuales en el stash
.
Git stash list
.
te muestra una lista de los cambios guardados en el stash
.
Git stash pop
.
libera los cambios que estaban guardados en el stash dentro de la rama donde ejecutes el comando.
.
Git stash branch english-version
.
te desplaza a la rama “english-version” (creandola si no existia), y liberando los cambios guardados en el stash.
.
Git stash drop
.
Borra los cambios que tenías guardados en el stash
.
Git clean
Borra archivos nuevos que aún no estan staged o tracked.
.
Ojo, este comando no funciona si se ejecuta por si solo. Tienes que ejecutarlo con sus extensiones.
.
Ojo, este comando no toca a las carpetas ni a las cosas que hayan sido indicadas en el .gitignore.
.
Extensiones

  1. –dry-run: te muestra una lista de las cosas que serían borradas si ejecutas el comando git clean (pero no las borra aún. Esto solo es para que tengas una idea de que sería borrado con el comando).
  2. -f: borra todo lo que aparece en la lista que muestra --dry-run

Ejemplos
Git clean --dry-run
.
Muestra la lista de los que se borraría si usas el comando
.
Git clean -f
.
Borra todo lo que se puede borrar con git clean.
.
Git cherry-pick
Hace un git merge con un commit antiguo de una rama diferente.
.
OJO, ESTO ES UNA MALA PRÁCTICA. Esto reconstruye la historia del repositorio y eso rompe la trazabilidad de los cambios.
.
Ojo, El merge no se guarda como un merge en el log, sino que se guarda como un commit nuevo en la rama actual. No hay forma de saber de donde vino la información que se agregó.
.
Escritura
Git cherry-pick + CommitID
.
Ejemplo
Git cherry-pick 7d8eaef
(ejecutado desde la rama main)
.
Ejecuta un merge de “main” con el commit 7d8eaef (que pertenece a otra rama, y está tres commits detrás del HEAD de esa rama).
.
Git grep
Busca palabras o expresiones en los archivos del repositorio y los muestra en pantalla.
.
Tambien puedes usar extensiones para ver cuántas veces usaste una palabra.
.
Ojo, para terminos complejos, lo correcto es encerrar el termino entre comillas
.
Escritura
Git grep + extensión + termino a buscar
.
Extensiones
• “-n” indica las líneas donde se encuentra el término que buscar
• “-c” cuenta la cantidad de veces que la palabra se repite por documento

Ejemplo 1
Git grep color
.
Muestra en pantalla los archivos que contienen “color”, junto con las líneas en su interior que contienen la palabra.
.
Ejemplo 2
Git grep -n color
.
Muestra además la línea del archivo donde aparece la palabra.
.
Ejemplo 3
Git grep -n color
.
Cuenta cuantas veces se repite la palabra “color” en cada archivo.
.
Ejemplo 4
Git grep "Etiqueta-html"
.
Cuenta cuantas veces se usa una etiqueta en cada archivo.
.
Git shortlog
Muestra un log por cada colaborador del proyecto
.
Escritura
Git shortlog + extensión
.
Extensiones
• -sn: cuenta el número de commits que ha hecho cada colaborador
• --all: incluye todos los commits que ha realizado cada colaborador, incluyendo los que fueron borrados.
• --no-merges: ignora los merge

Ejemplo 1
Git shortlog
.
Muestra el log de commits por colaborador
.
Ejemplo 2
Git shortlog -sn --all --nor-merges
.
Muestra cuantos commits ha hecho cada colaborador (incluyendo los commits borrados, pero excluyendo los commits que son un merge).
.
Git blame
Muestra el contenido de un archivo junto con el contribuidor que modificó cada línea por última vez, y el Hash del commit donde esa línea fue modificada por última vez.
.
Escritura
Git blame + extensión + nombre del archivo
.
Extensiones
• -c: identa un poco más la información para hacerla más facil de leer.
• -L + línea de inicio +"," + Línea final: Hace un git blame de un documento, pero solo del contenido entre las líneas indicadas en la extensión.

Ejemplo1
Git blame blogpost.html
.
Git blame -c blogpost.html
.
Ejemplo 2
Git blame css/estilos.css -L35,53
.
Hace un git blame del archivo estilos.css en la carpeta css/; pero solo evaluando el contenido entre la línea 35 y 53 del archivo.

5. Comandos para casos de emergencia

git reflog
Muestra la historia de commits de todas las ramas en orden temporal, y con el número de HEAD de cada uno.
.
Esta se usa para identificar el estado del proyecto al que querrías regresar con un git reset
.
Ojo, esto guarda toda la historia del repositorio, incluyendo cuando haces un git reset
.
Escritura
Git reflog
.
Ejemplo
Git reflog
.
Git reset
Desplaza el HEAD a la versión que indiques a continuación, reseteando el repositorio entero a esa versión, y eliminando todas las versiones posteriores
.
Esto resetea las branches y los commits al punto donde estaban cuando hiciste el commit que indicaste en el reset.
.
Usualmente se usa en conjunto con git reflog para identificar el HEAD al que quieres regresar.
.
OJO, ESTO ES UNA MALA PRACTICA. SOLO SE USA EN EMERGENCIAS.
.
Ojo, escribir solo git reset HEAD te permite sacar los archivos que esten actualmente en el staging area sin alterarlos en el directorio local. (es decir, te permite deshacer los git add).
.
Ojo, git reset trabaja solo en el repositorio, asi que no afecta los archivos en el directorio local. Es decir, aunque regreses a la versión 2 (desde la versión 3), tus archivos actuales seguiran siendo los de versión 3. Y aún puedes hacerles add y commit 😮 (ojo, esto no aplica si haces git reset --hard, que es lo común).
.
Esto puede ayudarte a deshacer un commit equivocado (cuando hubo un error en un archivo, o simplemente cuando te equivocaste en el mensaje que ibas a dejar).
.
Ojo, aunque el git log queda reescrito, el git reflog no se reescribe. Alli si queda guardado cuando ocurre un reset, e incluso puedes regresar a como estaba todo antes del reset si usas un hash del reflog.
.
Escritura
Git reset + extensión (si aplica) + commit/“HEAD”
.
Extensiones

  1. “–soft”: Conserva lo que esté en el Staging area (index)
  2. “–hard”: No conserva nada.

Ejemplo 1
git reset --soft 8fbb4a54e3b6098dda62ddc9e44d8ca4bd33b4e7
.
Resetea todo el repositorio a cuando estaba cuando ocurrió ese commit (restaurando branches y archivos disponibles aquel entonces)
.
Ojo, el directorio quedará como estaba antes de hacer el reset, asi que tienes que hacer un Checkout para regresar los archivos a la version que deseabas.
.
Ejemplo 2
Git reset --hard [email protected]{4}
.
Resetea todo el repositorio y el directorio de trabajo a como estaba cuando se hizo el commit identificado como el [email protected]{4} (esta etiqueta se puede ver cuando usas el git reflog)
.
Ejemplo 3
Git reset HEAD
.
Saca todos los cambios del staging area (deshace todos los git add que hayas hecho despues del último commit)
.

6. Cómo configurar llaves SSH en local

Primer paso: Generar tus llaves SSH. Recuerda que es muy buena idea proteger tu llave privada con una contraseña.
.
ssh-keygen -t rsa -b 4096 -C "[email protected]"
.
Segundo paso: Terminar de configurar nuestro sistema.
.
En windows y Linux:
#Encender el “servidor” de llaves SSH de tu computadora:
eval $(ssh-agent -s)
.
#Añadir tu llave SSH a este “servidor”
ssh-add ruta-donde-guardaste-tu-llave-privada
.
En mac:
#Encender el “servidor” de llaves SSH de tu computadora:
Eval "$(ssh-agent -s)
.
#Si usas una versión de OSX superior a Mac Sierra (v10.12), debes crear o modificar un archivo “config” en la carpeta de tu usuario con el siguiente contenido (ten cuidado con las mayusculas)

Host *
AddKeysToAgent yes
UseKeyChain yes
IdentityFile ruta-donde-guardaste-tu-llave-privada

#Añadir tu llave SSH al “servidor” de llaves SSH de tu computadora (en caso de error puedes ejecutar este mismo comando pero sin el argumento -k
Ssh-add -K ruta-donde-guardaste-tu-llave-privada
.
Notas
El protocolo de envío de datos por llaves públicas y privadas se llama ssh (secure shell).
.
Este es el protocolo que se debe usar para conectarte a servidores remotos.
.
A partir de que ambos lados tienen la llave pública del otro, ambos ordenadores pueden transferir información de forma segura a través del protocolo ssh
.
Las llaves públicas y privadas no se generan por repositorio. Se generan por persona.
.
Lo correcto es crear las llaves pública y privada en el Home de tu usuario.
.
El comando es:
.
ssh-keygen -t rsa -b 4096 -C “tu correo electronico en Github”
.

  1. “ssh-keygen” es el comando para generar las llaves
  2. “-t” especifica a continuación el tipo de llave a crear.
  3. “rsa” es el tipo de llave (algoritmo) mas popular actualmente (04/2021)
  4. “-b” especifica a continuación el número de bits en la llave a crear (la complejidad de la llave)
  5. “4096” es el número de bits que elegimos en este ejercicio.
  6. “-C” agrega un comentario. En este caso se agrega el correo electronico al que estará vinculado esta llave.
    .
    Cuando la crees te preguntará donde la quieres guardar. (por defecto elige una carpeta .ssh/ en el home, la cual es buena opción)
    .
    Luego pide un passphrase (contraseña con espacios). Puedes ponerle una a tu llave privada, y lo correcto es hacerlo.
    .
    A partir de ahora, tu llave publica está en la carpeta .ssh/ en el home, y tiene la extensión “.pub”
    .
    (id_rsa es tu llave privada; y id_rsa.pub es la pública).
    .
    La key fingerprint y el randomart son formas de saber que la llave de verdad fue creada. Y el randomart es otra forma de compartir esa llave.
    .
    Para activar la llave, tienes que asegurarte de que el servidor de llaves ssh esté encendido.
    .
    En windows y Linux funciona igual. Solo ingresa el siguiente comando:
    .
    eval $(ssh-agent -s)
    .
    Si luego de que lo corres te suelta algo como esto:
    .
    Agent pid 129
    .
    Entonces el proceso está corriendo bien. (pid es el process ID)
    .
    Ahora hay que agregarla al servidor ssh local.
    .
    Para hacerlo corres el comando
    .
    ssh-add + ruta-llave-privada
    .
    En mi caso es
    .
    Ssh-add ~/.ssh/id_rsa
    .
    Ojo, puedes borrar una llave con ssh-add -D
    .
    Ojo, puedes cambiar la passphrase de tu ssh con:
    .
    ssh-keygen -p
    .
    Te pedirá que ingreses la vieja contraseña y que ingreses y confirmes la nueva.
    .

7. Cómo crear un Alias en Git

Git config --global alias.stats “shortlog -sn --all --nor-merges”
.
Esto crea un alias en git que hace que la palabra “stats” sea igual a “shortlog -sn --all --nor-merges”
.
Por lo tanto,
.
Git stats = Git shortlog -sn --all --nor-merges
.

8. Cómo invocar manuales completos sobre los comandos

Insertar el comando seguido de la extensión “–help” abre un documento html con información detallada sobre ese comando
.
Ejemplo:
.
Git blame --help

Afterword

Escrito y recopilado por Jhonkar Sufia @mistofjoy 29/04/2021

Escribe tu comentario
+ 2
Ordenar por:
1
6921Puntos

Guardado para toda la eternidad. Gracias

0
6296Puntos

Vale oro.

0
6384Puntos

Me acabas de salvar con este resumen. Mil gracias.