Introducción a Git

1

¿Por qué usar un sistema de control de versiones como Git?

2

¿Qué es Git?

3

Instalando GitBash en Windows

4

Instalando Git en OSX

5

Instalando Git en Linux

6

Editores de código, archivos binarios y de texto plano

7

Introducción a la terminal y línea de comandos

Comandos básicos en Git

8

Crea un repositorio de Git y haz tu primer commit

9

Analizar cambios en los archivos de tu proyecto con Git

10

¿Qué es el staging?

11

¿Qué es branch (rama) y cómo funciona un Merge en Git?

12

Volver en el tiempo en nuestro repositorio utilizando reset y checkout

13

Git reset vs. Git rm

Flujo de trabajo básico en Git

14

Flujo de trabajo básico con un repositorio remoto

15

Introducción a las ramas o branches de Git

16

Fusión de ramas con Git merge

17

Resolución de conflictos al hacer un merge

Trabajando con repositorios remotos en GitHub

18

Cómo funcionan las llaves públicas y privadas

19

Configura tus llaves SSH en local

20

Uso de GitHub

21

Cambios en GitHub: de master a main

22

Tu primer push

23

Git tag y versiones en Github

24

Manejo de ramas en GitHub

25

Configurar múltiples colaboradores en un repositorio de GitHub

Flujos de trabajo profesionales

26

Flujo de trabajo profesional: Haciendo merge de ramas de desarrollo a master

27

Flujo de trabajo profesional con Pull requests

28

Utilizando Pull Requests en GitHub

29

Creando un Fork, contribuyendo a un repositorio

30

Haciendo deployment a un servidor

31

Hazme un pull request

32

Ignorar archivos en el repositorio con .gitignore

33

Readme.md es una excelente práctica

34

Tu sitio web público con GitHub Pages

Multiples entornos de trabajo en Git

35

Git Rebase: reorganizando el trabajo realizado

36

Cómo usar Git Stash: guarda cambios temporalmente

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits antiguos al head del branch

Comandos de Git para casos de emergencia

39

Git Reset y Reflog: úsese en caso de emergencia

40

Reconstruir commits en Git con amend

41

Buscar en archivos y commits de Git con Grep y log

Bonus sobre Git y Github

42

Comandos y recursos colaborativos en Git y GitHub

43

Tu futuro con Git y GitHub

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Git Reset y Reflog: úsese en caso de emergencia

39/43
Recursos

Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de referencia o reflogs…La gestión de estos cambios es mediante los hash’es de referencia (o ref) que son apuntadores a los commits…Los recoges registran cuándo se actualizaron las referencias de Git en el repositorio local (sólo en el local), por lo que si deseas ver cómo has modificado la historia puedes utilizar el comando:

git reflog

Muchos comandos de Git aceptan un parámetro para especificar una referencia o “ref”, que es un puntero a una confirmación sobre todo los comandos:

  • git checkout Puedes moverte sin realizar ningún cambio al commit exacto de la ref

    git checkout eff544f
    
    
  • git reset: Hará que el último commit sea el pasado por la ref, usar este comando sólo si sabes exactamente qué estás haciendo

    git reset --hard eff544f # Perderá todo lo que se encuentra en staging y en el Working directory y se moverá el head al commit eff544f
    git reset --soft eff544f # Te recuperará todos los cambios que tengas diferentes al commit eff544f, los agregará al staging area y moverá el head al commit eff544f
    
    
  • git merge: Puedes hacer merge de un commit en específico, funciona igual que con una branch, pero te hace el merge del estado específico del commit mandado

    git checkout master
    git merge eff544f # Fusionará en un nuevo commit la historia de master con el momento específico en el que vive
    

¿Qué pasa cuando todo se rompe y no sabemos qué está pasando? Con git reset HashDelHEAD nos devolveremos al estado en que el proyecto funcionaba.

  • git reset --soft HashDelHEAD te mantiene lo que tengas en staging ahí.
  • git reset --hard HashDelHEAD resetea absolutamente todo incluyendo lo que tengas en staging.

Atención

git reset es una mala práctica, no deberías usarlo en ningún momento. Debe ser nuestro último recurso.

Aporte creado por: David Behar.

Aportes 495

Preguntas 56

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Git nunca olvida, git reflog

Git guarda todos los cambios aunque decidas borrarlos, al borrar un cambio lo que estás haciendo sólo es actualizar la punta del branch, para gestionar éstas puntas existe un mecanismo llamado registros de referencia o reflogs.
.
La gestión de estos cambios es mediante los hash’es de referencia (o ref) que son apuntadores a los commits.
.
Los recoges registran cuándo se actualizaron las referencias de Git en el repositorio local (sólo en el local), por lo que si deseas ver cómo has modificado la historia puedes utilizar el comando:

git reflog

Muchos comandos de Git aceptan un parámetro para especificar una referencia o “ref”, que es un puntero a una confirmación sobre todo los comandos:

  • git checkout Puedes moverte sin realizar ningún cambio al commit exacto de la ref

    git checkout eff544f
    
  • git reset: Hará que el último commit sea el pasado por la ref, usar este comando sólo si sabes exactamente qué estás haciendo

    git reset --hard eff544f # Perderá todo lo que se encuentra en staging y en el Working directory y se moverá el head al commit eff544f
    git reset --soft eff544f # Te recuperará todos los cambios que tengas diferentes al commit eff544f, los agregará al staging area y moverá el head al commit eff544f
    
  • git merge: Puedes hacer merge de un commit en específico, funciona igual que con una branch, pero te hace el merge del estado específico del commit mandado

    git checkout master
    git merge eff544f # Fusionará en un nuevo commit la historia de master con el momento específico en el que vive eff544f
    

Freddy son las 3:43 AM y estoy vienod el video a esta hora porque hace 40 minutos hice un merge que genero conflicto y se sobreescribio mis cambios en un intento de recuperara el trabajo con VS2019 lo que hice fue borrar todo.
No sabe como le agradezco esta clase, de verdad pensé que había perdido el trabajo de mas de 30 horas seguidas todo el fin de semana con su festivo incluido, justo 6 horas antes de tener que entregarlo.
Esta es la clase que por mucho me ha ayudado a que no fuera la peor semana de este año.
Mil Millones de Gracias , de verdad, creo que se nota mi agradecimiento, estaba realmente desesperanzado

==Antepenúltimo aporte de este curso! 😃 ==

Flanders!!, porque borraste todo…

Cuando haces un git commit --amend cuando la cagaste y pensaste que tu jefe no se enteraría:

Cuando te enteras de que existe el git reflog:

Saludos!
Sam Martínez( ̄﹃ ̄)

Cabecera queda eliminada porque se le hace reset a master, para recuperar cabecera podemos conseguir el commit con reflog e usar

git checkout -b cabecera "commit id"

Freddy viendo cómo uso git reset --hard a lo loco porque YOLO.
Jk.

git reset --HARD Antes de conocerla a ella

Reflog

Los registros de referencia también llamados reflogs son una funcionalidad de git que registra todos los eventos del repositorio. Cada vez que el extremo de tu rama se actualiza por cualquier motivo, se añade una nueva entrada a este registro.

→ Mostrar el registro.

$ git reflog

→ Mostrar el registro relativo a la fecha especificada.

$ git reflog --relative-date

Reset

Este comando borra toda la información de nuestra rama hasta el punto que le especifiquemos. La invocación predeterminada tiene argumentos implícitos, como lo detallo a continuación:

→ Invocación predeterminada del comando

$ git reset

→ Invocación con sus argumentos implícitos.

$ git reset --mixed HEAD

En vez de HEAD, se puede usar cualquier HASH de commit de git.

Además del argumento --mixed tenemos otros dos que son --hard y --soft.

Ahora, detallando un poco cada uno de los argumentos tendríamos lo siguiente:

  1. --hard → Esta es la opción más peligrosa aunque es la que se usa más frecuentemente. Con esta opción todo el trabajo que se encuentra en el staged se pierde y la cabecera de nuestro repositorio apuntará al commit indicado olvidándose de todo lo que sucedió después de ese commit.
  2. --mixed → Este es el modo de funcionamiento predeterminado. Se actualizan los punteros del repositorio y todos los cambios que se hayan deshecho en el índice del entorno de ensayo e mueven al directorio de trabajo.
  3. --soft → En esta opción a diferencia de la primera todo lo que estaba en el staged se conserva, únicamente actualiza la cabecera del repositorio al commit indicado.

Para los que se les perdio la rama cabecera solo ejecuten git checkout cabecera, luego git checkout master de nuevo y git branch ahí ya aparece cabecera de nuevo.

Visual studio code fue hecho con el amor de una madre. ☺️

Git reflog lo sabe todo…

Yo viendo con reflog todos los reset que había hecho antes de llegar a la clase de los reset xd

Cuando el pinche bug no se puede solucionar!!! xD

Es increible como Git guarda absolutamente todo lo que hicimos en nuestro repositorio. Incluso luego de hacer un git reset --hard, podemos volver al momento exacto antes de hacerlo.
Un dato interesante es que tu reflog nunca será igual al de otra persona, aún cuando esa persona esté trabajando en el mismo proyecto que tú. La razón es que Git solamente sube al servidor (GitHub por ejemplo) las referencias que se puedan acceder directamente. Es decir, cuando estamos haciendo un push no estamos mandando el reflog, el reflog solo vive en nuestra máquina, y el servidor tiene su propio reflog. Por lo tanto, Git no es un sistema de opias de seguridad, hacer un push no es hacer una copia de seguridad al repositorio.

Hola a todos, fui anotando todos los comandos del curso y los agrupé en categorías y como no podía ser de otra forma, los subí a GitHub, seria genial, que ustedes añadiesen los comandos que quisieran y/o sus propias descripciones con un pull requests
https://github.com/SuKuShaing/ComandosDeGit.git

Apuntes 😄

Para recuperar una rama que haya sido eliminada necesitamos el hash ultimo commit hecho en dicha rama. Para eso usamos git reflog. Buscamos el hash y lo copiamos.

Ya habiendo obtenido el hash lo que hacemos sera volver a crear la rama pero le agregamos el hash al final.

	git checkout -b cabecera hash_del_utlimo_commit_de_cabecera

Un momento… Minuto 5:25, el branch cabecera no volvió!!

No pude recuperar mi rama cabecera con Git reset --hard 😦

¿Cómo hago eso con mi vida?

¿Qué pasó ayer? Parte 4

Yo cuando freddy borró la rama cabecera

Falto mencionar que si cambias o eliminas un archivo ignorado no lo recuperas con git reset asi no más. Buena clase.

Jajaja me gusta la forma de enseñar de Freddy, con sus actuaciones es original y hace la clase dinámica y entretenida, se aprende mejor la verdad, pase en unos pocos días de saber nada de Git a entenderle y usarlo sin problemas.

Visual Studio Code fue hecho con el amor de una madre 😄

Bueno pero la rama cabecera ya se perdio, no vi que se recuperara. =/

nooo frediee no quiero ver mas…

–cuando fredy te da buenos recursos pero te dice que son malas practicas jjjaa !

Por si alguien olvido arbolito se escribe así:

alias arbolito="git log --all --graph --decorate --oneline"

esto tal vez les sea de utilidad:

pasa que si nosotros metemos un commit al remoto que NO queremos que este allí, podemos sacarlo de esta manera … (desde consola y no por github)
hacer un reset --hard a la versión anterior al envio del archivo.
hacer un commit origin master -f ( f = fuerza el envio )

aqui encontraran mas info

https://www.campusmvp.es/recursos/post/como-eliminar-el-ultimo-commit-de-git-en-el-repositorio-de-origen-p-ej-github.aspx

el git reset si te devuelve al commit si hiciste algo mal en local, pero se debe usar como ultimo recurso, si el repositorio esta en la nube (github, gitlab, bitbucket, etc.) es mejor volver a clonar el repo, o pedirle a algún colaborador si existe en el proyecto que haga un push de sus cambios y hacer nosotros un pull, recordemos que son repositorios distribuidos.

así que git reset con --soft o --hard se puede hacer pero cuando ya no consigamos solución como el ultimo, recurso de después de hacer todo lo posible.

git reflog nos devuelve un histórico de las instrucciones que ejecutamos en un repositorio.

Cabecera sigue donde ha estado toda la vida

Ah! Es que nunca estuvo. Todo fue una mentira x’D

En mac no sirve git reset --HARD [commit] ya que al parecer tiene conflictos con las letras mayusculas, en este caso seria git reset --hard [commit] para restaurar determinado commit

ojala hubiera un git reset para tu corazon despues de que ella te rompiera el corazon XD

git reflog es el ojo de sauron. que atraviesa las sombras y la piel.

Git reflog es como el norte nunca olvida 😃

aca mi pregunta interezante… recuerdo que en un proyecto hace un tiempo lanzamos un reset… solo experimentando… despues seguimos trabajando… revisando dicho proyecto seguimos avanzando hasta que llegue a esta clase y probe el reflog… y en realidad la parte donde aparece ese RESET me la “skipea”, es decir la pasa por alto por que son muchos logs. existe alguna forma de ver realmente el log completo?

dejo captura

Excelente clase, de verdad me sorprendo mucho en como han pensado los comandos los creadores para todas las situaciones que se puedan presentar usando Git. 🙂

Si usan el powershell de windows, cuando hagan git reset HEAD@{0} deben encerrarlo en comillas git reset “HEAD@{0}” ya que puede dar error.

Una anécdota que me voy a llevar de este curso es que por mas que tenga que entregar eso si tengo que dormir lo haré… XD

OMG esto si me va a servir 😅🤘

Como trabaje todo este tiempo sin Git y Github estas herramientas nos dan superpoderes.

Una pregunta, entonces si por error yo envio por ejemplo mi archivo .env con todas las claves de mi base de datos y api keys y estas cosas,
como hago para eliminar estos datos de la historia de mi repositorio? , según lo que dices esto es imposible ?

Cual es la diferencia de usar entre git reset --hard o --soft+ el commit y
git reset --hard o --soft + HEAD{0}

*******************************************************************************
****************Git Reset y Reflog: Úsese en caso de emergencia****************
*******************************************************************************

git reflog (Permite ver el log completo)

git reset HEAD@{2}

git RESET --hard 9ea6558

*******************************************************************************
****************Git Reset y Reflog: Úsese en caso de emergencia****************
*******************************************************************************

Úsese solo cuando nos hagamos bolita y lloremos en un rincón

Podemos hacer una copia del log por si algun dia necesitamos recuperar algo con:

git reflog > nombrearchivo.txt

nunca escriban codigo mientras estan borrachos… los puede obligar al dia siguiente a utilizar el git reset --hard

jajajajjajaja como me reí, Freddy debería tener más cursos

Freddie para los premios Oscar xD

haha me encanta la alegria de como enseñas

Jajajaja visual studio code fue hecho con el amor de una madre XD

Clase 39 – Git Reset y Reflog: úsese en caso de emergencia

¿Para qué sirve el comando git reflog?

  • Para ver toda la historia del repositorio, aunque hayamos borrado cosas y alterado su historia.

¿Qué es “HEAD (#)” que vemos al usar git reflog?

  • Son los head que se han ido muriendo en el tiempo.

¿Qué es lo más importante cuando hacemos un git reset?

  • Saber identificar el commit en el que queremos volver, porque una vez hayamos vuelto en el tiempo todo lo que había desde ese momento en adelante se perderá.

git reflog, trae todos los cambios y nunca olvida.

git reset, debería ser utilizado en casos muy estrictos.

Si por casualidad se te ocurre hacer PUSH de los cambios erroneos, antes de hacer RESET. Cuando arregles todo y vuelvas a hacer push vas a recibir un error, como este:

error: denying non-fast forward refs/heads/main (you should pull first)

No queremos hacer PULL, por que eso traería los cambios erroneos.
Lo que se puede hacer es forzar un PUSH:

git push --force origin main

Ahora sí, el server debería aceptar el push.

Gracias git reset --hard

Git Reset y Reflog: úsese en caso de emergencia
git reflog, Aquí se ve todo sin importar que hayas eliminado cosas o hayas hecho daños y hecho commits, una vez aquí podemos coger el ultimo HEAD donde todo estaba bien y podemos hacer un git reset.

git reset --soft, este mantiene lo que sea que tengamos en staging, a lo que le hayamos dado add, lo que todavia este pendiente de un commit.
git reset --hard, y este nos resetea todo.

git reset lo que hace es volvernos a traer esa posición donde estuvimos antes.

El comando reset es peligroso porque cuando hacemos un reset HARD es como si estuviéramos reseteando toda la historia, esta es una mala practica y no debería usarse sino hasta cuando algo realmente se rompe

git reset NO recupera ramas.

En conclusión NADA, pero NADA se pierde con GIT!

En git reflog está la verdad...

git reflog es el que da las pistas para resolver el crimen que cometiste jaja

Estos códigos me hubieran sido utiles a mitad del curso jejej

Comparto mis apuntes de la clase

Creo que cuando hacemos git reset HEAD@{4} no es un reset --soft, es un mixed. Por que el soft te mantiene los cambios agregados, luego de darle al add, listos para el comit. En cambio el mixed te los deja a los cambios listos para el comit -a, o add primero y luego commit

Git Reflog muestra el registro de referencias de Git, esto significa que proporciona un historial detallado de todas las acciones realizadas en el repositorio local, incluso si se han eliminado o perdido ramas o confirmaciones. Es especialmente útil cuando necesitas recuperar cambios perdidos o deshacer acciones no deseadas.
.
Ejecutar git reflog en nuestro repositorio, nos mostrará el registro de referencias. Verás una lista cronológica de todas las acciones realizadas, como confirmaciones, fusiones, cambios de rama, rabase, entre otros. Cada entrada en la lista está identificada con un hash que se puede usar para referenciar acciones específicas en el historial. Estos identificadores permiten recuperar confirmaciones eliminadas o deshacer cambios no deseados con git reset --HARD <hash_commit>.
.
Con git reflog también tenemos varias opciones adicionales, como filtrar el registro por una rama específica utilizando git reflog show <branch_name>, o mostrar solo las entradas relacionadas con ciertos archivos utilizando git reflog -- <file_name>.
.
El reflog solo se mantiene durante un tiempo limitado y puede ser eliminado en ciertas situaciones, como cuando ejecutas comandos como git gc para limpiar tu repositorio. Por lo tanto, es importante actuar rápidamente si necesitas recuperar cambios perdidos.

Creo que la rama borrada no logró recuperarse. En ese caso hay una forma de hacerlo (no sé si también se considera mala práctica) y es la siguiente:

Primero, hay que identificar el id del commit en el que la rama todavía existía. Luego ponemos el siguiente comando:

git branch <branch-name> <commit-id>

Reemplaza branch-name por el nombre de la rama borrada y commit-id por el identificador o hash del commit. Esto hará que la rama se creé con todos los commits hasta ese punto. Recuerda usar git reflog para ver el id del commit

ajjajajajajajajjajajajajajaj me hizo reir la parte donde dijo que siempre se usa HARD es porque en verdad todo se fue al carajo. Tambien esta la opcion de git revert <hash commit>
lo ismo que el reset pero guarda el historial

La cara de un hombre que ha salvado incontables proyectos con este curso
🤙

  • git reflog Encontramos la historia de los cambios realizados con los archivos en git, como las ramas o archivos eliminados

Soy yo o la rama cabecera no aparece como Freddy dice?. Eso querria decir que el git reset --HARD no recupero la rama borrada?

Git reflog no olvida
Git reflog no perdona!

Hace dos calses se me fue al carajo todo, yo viendo este video 😃

Amo reír con el estilo de Freddy.

Tssss git NUNCA OLVIDA!!!

Normalmente, en entornos de desarrollo, no se utiliza el git reset --soft si no que se hace un --hard y es razón de ello, la corrección de errores, reseteando todo radicalmente.

git reflog seria como un detective, descubre a los rebase a los amed por ahi que parecian que nunca estuvieron cuando se hacia git log jaja

La clase más divertida de todo Platzi me parece.

Eso no sería estar dormido, eso sería tener 15 cervezas encima jajajajaja

GIT REFLOG es como tu conciencia 💀👽👹

De mis videos favoritos 😄😄

ya casi terminamos el cursoooo

Tengo una duda, que tal si ese commit ya se le hizo un push y esta en el remoto?
¿puedo darle RESET en local y despues hacer push?

moraleja no hagan commits de noche

Sin lugar a duda solo viendo videos no es aprender y eso es lo que hace maravilloso a Platzi, darnos esos consejos valiosos.
Pase casi una hora simulando que estoy trabajando en mi proyecto y después llegaba alguien nuevo al equipo y daño todo, hice varios commit tratando de “arreglar esos problemas” pero a la final no se pudo y nuestro jefe quería que el proyecto esté como antes cuando todo funcionaba. Pero llega alguien salvador al equipo y conoce esta maravilla de git reflog y git reset y nos salva el día. (me metí mucho en la historia xD)

Super claro como funciona estos comandos.

Cuando todo se va al Cara

PowerShell

Si alguien más está usando la consola de PowerShell 😂 y le sale este error:

Le agregan comillas simples nomas 'HEAD@{4}', porque @ y {} son caracteres especiales para esta consola.

stackoverflow - git reset HEAD@{n} results in error “unknown switch ‘e’”

Si quieren tener una vista parecida a la de Freddy donde veamos en que branch estamos sin tener que poner git branch, hagan lo siguiente:

  1. Primero vamos a abrir la configuracion de bash con code o vim, en este caso lo hare con code, ponemos los siguiente:
code ~/.bashrc
  1. Luego ya que se nos abra el archivo, vamos a ir hasta abajo, pueden agregar la nota usando
    #Mostrar git branch

y luego ponemos

PS1='\u@\h\[\033[01;34m\] \w\[\033[0;32m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] '

le damos guardar ctrl + S.

  1. Ahora nos vamos de vuelta a la terminal y para no tener que salirnos le damos lo siguiente:
<code> source ~/.bashrc

y listo, navegamos a una carpeta que tengamos un .git y ya podremos ver en que branch estamos:

Por lo que veo, Git es la vieja chismosa de la calle que pase lo que pase el chisme se lo llevará hasta que los gusanos la desintegren.

Aconsejo ver 2 veces (mínimo) esta clase y después ponerla en práctica, antes de mandarse una kgada 😄

Profesor Freddy permítame decirle que usted posee el don de la enseñanza.
Sus clases son maravillosas!!!🤩

Termine el curso hace unos mese y de pronto trabajando en un proyecto -> todo se fue al carajo <- y estoy otra vez aquí con un cafecito xd

Este video pude ser perfectamente sacado de contexto 🤣🤣
que grande Freddy