Introducción a Git

1

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

2

¿Qué es Git?

3

Instalando Git y 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 y los repositorios? Ciclo básico de trabajo en Git

11

¿Qué es un 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

Cambios en GitHub: de master a main

19

Uso de GitHub

20

Cómo funcionan las llaves públicas y privadas

21

Configura tus llaves SSH en local

22

Conexión a GitHub con SSH

23

Tags y versiones en Git y 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

Git Stash: Guardar cambios en memoria y recuperarlos después

37

Git Clean: limpiar tu proyecto de archivos no deseados

38

Git cherry-pick: traer commits viejos al head de un 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

Git reset vs. Git rm

13/43

Lectura

Git reset y git rm son comandos con utilidades muy diferentes, pero se pueden confundir muy fácilmente.

git rm

Este comando nos ayuda a eliminar archivos de Git sin eliminar su historial del sistema de versiones. Esto quiere decir que si necesitamos recuperar el archivo solo debemos “viajar en el tiempo” y recuperar el último commit antes de borrar el archivo en cuestión.

Recuerda que git rm no puede usarse así nomás. Debemos usar uno de los flags para indicarle a Git cómo eliminar los archivos que ya no necesitamos en la última versión del proyecto:

  • git rm --cached: Elimina los archivos de nuestro repositorio local y del área de staging, pero los mantiene en nuestro disco duro. Básicamente le dice a Git que deje de trackear el historial de cambios de estos archivos, por lo que pasaran a un estado untracked.
  • git rm --force: Elimina los archivos de Git y del disco duro. Git siempre guarda todo, por lo que podemos acceder al registro de la existencia de los archivos, de modo que podremos recuperarlos si es necesario (pero debemos usar comandos más avanzados).

git reset

Este comando nos ayuda a volver en el tiempo. Pero no como git checkout que nos deja ir, mirar, pasear y volver. Con git reset volvemos al pasado sin la posibilidad de volver al futuro. Borramos la historia y la debemos sobreescribir. No hay vuelta atrás.

Este comando es muy peligroso y debemos emplearlo solo en caso de emergencia. Recuerda que debemos usar alguna de estas dos opciones:

Hay dos formas de utilizar git reset: con el argumento --hard, borrando toda la información que tengamos en el área de staging (y perdiendo todo para siempre). O, un poco más seguro, con el argumento --soft, que mantiene allí los archivos del área de staging para que podamos aplicar nuestros últimos cambios pero desde un commit anterior.

  • git reset --soft: Borramos todo el historial y los registros de Git pero guardamos los cambios que tengamos en Staging, así podemos aplicar las últimas actualizaciones a un nuevo commit.
  • git reset --hard: Borra todo. Todo todito, absolutamente todo. Toda la información de los commits y del área de staging se borra del historial.

¡Pero todavía falta algo!

  • git reset HEAD: Este es el comando para sacar archivos del área de staging. No para borrarlos ni nada de eso, solo para que los últimos cambios de estos archivos no se envíen al último commit, a menos que cambiemos de opinión y los incluyamos de nuevo en staging con git add, por supuesto.

¿Por qué esto es importante?

Imagina el siguiente caso:

Hacemos cambios en los archivos de un proyecto para una nueva actualización. Todos los archivos con cambios se mueven al área de staging con el comando git add. Pero te das cuenta de que uno de esos archivos no está listo todavía. Actualizaste el archivo, pero ese cambio no debe ir en el próximo commit por ahora.

¿Qué podemos hacer?

Bueno, todos los cambios están en el área de Staging, incluido el archivo con los cambios que no están listos. Esto significa que debemos sacar ese archivo de Staging para poder hacer commit de todos los demás.

¡Al usar git rm lo que haremos será eliminar este archivo completamente de git! Todavía tendremos el historial de cambios de este archivo, con la eliminación del archivo como su última actualización. Recuerda que en este caso no buscábamos eliminar un archivo, solo dejarlo como estaba y actualizarlo después, no en este commit.

En cambio, si usamos git reset HEAD, lo único que haremos será mover estos cambios de Staging a Unstaged. Seguiremos teniendo los últimos cambios del archivo, el repositorio mantendrá el archivo (no con sus últimos cambios, pero sí con los últimos en los que hicimos commit) y no habremos perdido nada.

Conclusión: Lo mejor que puedes hacer para salvar tu puesto y evitar un incendio en tu trabajo es conocer muy bien la diferencia y los riesgos de todos los comandos de Git.

Aporte creado por: Juan David Castro

Aportes 903

Preguntas 54

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Tener cuidado

Espero que les sirva y les parezca interesante.

Creo que faltó la explicación de:

git reset --mixed

Imagen extraída de: git - A Compulsory developer Tool

Mis notas con la información del post

Cuando usas git reset --hard por equivocación:

Hola a todos, me gustaría compartir un resumen de esta clase porque veo confusión:

Sabemos que tenemos tres zonas (Directorio, Staging y Repositorio)

Cuando editamos un archivo y salvamos los cambios solamente, Git detecta que hay una modificación y esto lo vemos con el comando git status o git diff.

Cómo ocurre esto?
Esto se logra porque cuando se ejecuta un commit, se genera un Path o ruta del archivo en las tres zonas mencionadas, el archivo queda encadenado entre el directorio y el repositorio, Git hace un tracking o rastreo por la ruta establecida para detectar los cambios. cuando ejecutamos el comando git status o git diff, GIT los refleja en pantalla.

Ahora bien, volvamos al punto donde solamente edité el archivo en la zona del directorio y salvé los cambios,
para introducirlo en la zona de staging debemos hacerlo con…git add cierto?..Bien…!

Supongamos ahora que deseamos sacar de la zona staging el archivo, tenemos dos opciones:

a) git reset head file: mueves el archivo al directorio simplemente, si ejecutas git status o git diff observarás que GIT sigue detectando cambios en el archivo, porque la ruta o path sigue rastreada o tracked, puedes aprovechar esto para devolver los cambios que editaste en el archivo, recuerda que ahora esta en el directorio, ejecutando el comando git restore file, dejarás el archivo como lo encontraste y si deseas comprobar que todo está “original” ; ejecuta el comando git status o git diff, verás que git no detecta cambios.
“git reset head file” mueve el archivo de la zona staging a la zona directorio pero queda tracked por GIT.

Qué pasa que si ejecutas “git rm --cached file”?:
Eliminas el archivo directamente de la zona staging pero a demás su path y el archivo queda “Untracked” inrastreable, No lo mueves a la zona directorio, lo eliminas por completo la memoria sin dejar rastros para GIT, por lo tanto si deseas volver a la originalidad el archivo editado en la zona directorio con el comando git restore file, “GIT no podrá restaurar los cambios”, hiciste un reset memory del archivo en la ram o zona staging dejándolo fuera o chached de la memoria, ahora espero que podramos entender que hace “git rm --cached file”.

git rm --force file: es mas potente todavía porque lo eliminas de la zona staging y de la zona directorio, dicho en otras palabras los borras de GIT y del Disco Duro.

Hay que aclarar algo que puede confundir (Importante):

Cuando ejecutamos “git rm --cached file” y luego haces “git diff” observaras que “NO hay diferencias” en el archivo que se encuentra en la zona directorio con respecto a la zona repositorio (Ultimo commit), recuerda que este contiene la ultima versión del archivo en la rama master.

Qué pasa?
Git no lo detecta porque el archivo quedó eliminado y Untracked, pero en realidad el archivo que está en el directorio está modificado y es diferente con respecto al que se encuentra en la zona repositorio. si ejecutas el comando “git restore file”, GIT no podrá Matchear el archivo con el que se encuentra en el directorio, los cambios que editaste y salvaste no podrán deshacerse para volver al archivo original.

Qué podemos hacer para volver a rastrear el archivo y sea tracked por GIT:
Luego de ejecutar “git rm --cached file” podemos deshacer o restaurar los cambios con el comando “git restore --staged file”, ahora hemos restablecido la comunicación y GIT puede ayudarnos con el archivo porque esta tracked, pero NO esta en la zona staging, no te confundas simplemente esta Tracked…ahora si podemos ejecutar el comando “git restore file” y el archivo editado volverá a ser el original, todo quedará como lo encontraste! Compruébalo con “git status”.

Finalmente quedan los comando que se ejecutan en la zona del repositorio o staging-repositorio:
git reset N#Commit --soft: borra todos los commit superiores y queda como el commit master, el commit seleccionado en el comando, no hay vuelta atrás. a diferencia de “git checkout #commit file”.

git reset N#Commit --hard: borra todos los commit superiores y queda como el commit master, el commit seleccionado en el comando y además limpia la zona staging, no hay vuelta atrás como dice la clase…borra todo todito! así que corran por sus vidas.

Creo que esta muy claro cómo trabajan estos últimos comandos y el “git checkout”, en la clase anterior Freddy lo explica magistralmente.

Saludos!

Git rm: Remover/Eliminar

  • Git rm --cached: Elimina los archivos que están en staging (caché) pero los deja en tu carpeta (disco duro).
  • Git rm --force: Elimina el archivo de git y de tu carpeta (disco duro).
    _Los archivos se pueden recuperar pero con comando avanzados.

Git reset: Ir a archivos pasados.

  • Git resert --hard: Borra todo, del área de staging, commits e historial.
  • Git reset --soft: Borra el historial y los registros pero mantiene los cambios agregado a staging.
  • Git reset HEAD: Imagina que hiciste git add a dos archivos, un HTML y otro CSS. Sin embargo, te diste cuenta que no agregaste los estilos correctamente porque los titulos son rojos. Haces git reset HEAD, tu archivo se quita de staging, vuelve a tu carpeta, modificas el archivo css y vuelves a hacer git add. Si hubieses usado git rm tu archivo se hubiese eliminado.

Diferencias:
git rm solo elimina archivos (ya sea de staging o del disco duro).
git reset te envía a versiones antiguas y elimina archivos, historial y registros.

git reset --hard

Por si alguien quedo con duda de que es el Staging area aqui les dejo esta imagen quita dudas:

Para poder entnederle tuve que experimentar dejo mis resultados:

git rm --cached
- Regresa el archivo a un punto anterior especifico: NO

Borrado de
- Work Directory: NO
- Stage Area: SI
- Git: NO
Comentario: vuelve a la normalidad con git add; el archivo ya no esta en Traking

##################################################################

git rm --force
- Regresa el archivo a un punto anterior especifico: NO

Borrado de
- Work Directory: SI
- Stage Area: SI
- Git: NO
Comentario: Se puede regresar a la version anterior con git checkout archivo

##################################################################

git reset --soft
- Regresa el archivo a un punto anterior especifico: NO

Borrado de
- Work Directory: NO
- Stage Area: NO
- Git: SI
Comentario: vuelve a la normalidad con git commit

##################################################################

git reset --hard
- Regresa el archivo a un punto anterior especifico: SI

Borrado de
- Work Directory: NO
- Stage Area: SI
- Git: SI
Comentario: Para regresar a la “normalidad”, agregas los cambios hechos, git add; **git commit **

##################################################################

git reset HEAD
- Regresa el archivo a un punto anterior especifico: NO

Borrado de
- Work Directory: NO
- Stage Area: NO
- Git: NO
Comentario: Simplemente quita el archivo del Stage Area; el archivo sigue en Tracking

Espero haber simplificado un poco este tema
(Hice una tablita en excel, pero no se como compartir imagenes aquí; BIG CHALE u _ u)

La diferencia entre usar$ git rm --cached y $ git reset head para eliminar un archivo de Staging:

Con $ git rm --cached deja los archivos sin ser rastreados (untracked), los elimina completamente de git. Si queremos que sean rastreados de nuevo hay que agregarlos ($ git add). Si despues del $ git rm --cached vemos el status, podemos ver que efectivamente el archivo fue eliminado, y que no esta siendo rastreado.

Con $ git reset head el archivo sigue trackeado, pero los ultimos cambios no han sido añadidos a Staging. Si vemos el status despues de ejecutar el
$ git reset head vemos que el archivo sigue siendo trackeado, no ha sido elimado de Git, pero los ultimos cambios no han sido agregados a Staging.

En conclusion $ git rm --cached es más agresivo que $ git reset head , porque $ git rm --cached elimina el archivo de Git, no solamente lo que habia en Staging, sino todo el archivo. Deja de ser trackeado.

Con$ git reset head el archivo sigue siendo trackeado, solo se eliminan de Staging los ultimos cambios.

les comparto el mapa mental de esta explicacion

Tengamos en cuenta momentos en donde queremos hacer git add en todos los archivos menos en uno, no nos pondríamos a hacer git add y el nombre de cada archivo obviando el que no queremos eso no es nada eficiente, en cambio lo mejor es hacer git add . y después usar un git reset HEAD de ese archivo en particular y así podemos hacer commit en todos menos en ese, y nos ahorramos mucho tiempo

Entonces tenemos hasta el momento antes de llegar a esta clase los siguientes comandos.
git init => para iniciar nuestro proyecto con un repositorio nuevo
git add archivo.txt => para agregar un archivo a nuestro estado staging
git add . => para agregar todos los archivos a nuestros estado staging
git status => para verificar el estado
git commit -m “Mensaje descriptivo” => para guardar nuestros cambios al repositorio
git log => para mostrar el registro de cambios de nuestro repositorio
git log --stat => para mostrar el registro de cambios de nuestro repositorio con el detalle de cambios por cada archivo
git show => para mostrar los cambios a detalle
git diff => para mostrar los cambios realizados entre commits

Pongo mis apuntes de de este bloque del curso por si a alguien le sirven :p

Si después de leer esta explicación aún siguen con dudas, sólo les puedo decir que realicen el ejercicio tantas veces como sea necesario, es la única forma de comprender a aprender.

Pero en pocas palabras: usa el comando rm para cuando requieras eliminar un archivo, pero ten en cuenta que si usas el comando rm --cahed le estamos diciendo a git que si nuestro archivo ya está en el área de staging lo saque de ahí pero lo conserve en nuestro disco duro, pero cuando realicemos el próximo commit en el repositorio dicho archivo ya no va a existir y git ya no lo va a estar rastreando .

Debemos de usar el comando git reset HEAD <nombre_archivo> cuando necesitemos sólo sacar nuestro archivo del área de staging para que no se valla con cambios en el próximo commit.

Con esta lectura me queda muy claro, lo siguiente:

  • git rm ===> Sirve para eliminar archivos que ya no necesitemos mantener en nuestro repo.
  • git reset ==> Sirve viajar a un commit antiguo y sobreescribir toda la historia.
  • git reset HEAD ==> Sirve para mover los archivos que no quisieramos incluir en el commit que realizaremos. De esta manera mantenemos los cambios, pero no lo registramos en el commit. Hasta que estemos seguros de incluirlo.

Espero les sirva.

Reset: Volver a una version anterior

  • Hard: Todo vuelve al estado anterior (borra todo del stagging)
  • Soft: El stagin sigue ahí, disponible para el proximo commit
  • HEAD: Sacar archivos del area de staging, se puede reversir con un git add .

Rm: Quitar un archivo, pero matenerlo en el control de versiones

  • Cached: Del staggin y del proximo commit, pero los mantiene en el disco duro
  • Force: Del git y del disco duro. Sin embargo, se puede viajar en el tiempo y recuperarlo

💚 Excelente recurso para aclarar las diferencias entre git reset y git rm.

Saludos para aportar algo interesante con lo que me encontré ahora que estoy practicando.

Si es la primera vez que estas usando tu repositorio con git justo después de usar git init, crear tus archivos, editarlos, darle git add y si usas git status verás que los archivos van a estar en staging PERO SI QUIERES USAR EL COMANDO: git reset HEAD para sacarlos de ahí te va a generar un error del tipo: “fatal: argumento ambiguo ‘HEAD’: revisión desconocida…”

Es decir en esta primera vez no va a funcionar este comando!. Para que puedas empezar a usar git reset HEAD debes antes haber realizado algún commit.

Espero les sirva por si a alguien le sucede esto que me tuvo unas horas buscando el porque del error.

Siento que aquí le falto a Freddy explicar más claramente el uso de git reset

reset lo que hace es modificar el indice y el apuntador del HEAD, aunque las entradas con git log no aparecen, realmente siguen ahí, para ver el log del indice podemos usar

$ git reflog
907aa5f (HEAD -> master) [email protected]{0}: reset: moving to 907aa5f927827e26f066a5694907c5e5873dcac9
941661f [email protected]{1}: commit: Se restaura archivo borrado.
5f12e38 [email protected]{2}: commit: Se borra un archivo.
0488b89 [email protected]{3}: commit: se añade calendario
658537b [email protected]{4}: commit: Primer cambio
907aa5f (HEAD -> master) [email protected]{5}: reset: moving to HEAD
907aa5f (HEAD -> master) [email protected]{6}: commit (initial): First commit

por ejemplo en este ejemplo para regresar a la ultima versión antes del reset a la primera versión usamos
git reset 941661f --hard

--hard modifica los archivos en el working tree
--soft no modifica los archivos en el working tree

Diferencia entre git reset head y git rm --cached <file>

Supongamos que historia.txt esta en el stage area.
Si usamos el reset HEAD pasa de stage a unstage. O sea que git le sigue haciendo seguimiento y sabe cuando lo modificas sin embargo tienes que hacer un add historia para luego hacerle un commit.
El git rm --cached lo que hace es pasar de stage a un untracked. O sea que git ya no le esta haciendo seguimiento y tampoco sabe cuando lo modificas git solo sabe que esta ahi.

git reset head: Este comando hace que los archivos dejen de estar en el staged area. Recuerda que el staged area es el estado previo a realizar el commit, después de que agregas los cambios con el comando git add <file>

git rm --cached <file>: Este comando hace que git deje de “trackear” el archivo. Esto quiere decir que ya no va a llevar un registro de los cambios. Este es el estado en el que se encuentran todos los archivos nuevos del proyecto. Git no sabe que cosas han sido modificadas dentro de esos archivos porque aún no están siendo “trackeados”.

Por si persisten dudas acerca de las diferencias:

El comando git rm te permite eliminar un archivo completamente de git, pero te deja staged esta actualización, es decir: el acontecimiento de que borraste el archivo lo deja preparado para que hagas commit de ésta actualización. Independiente de si usas el flag –cached o –force, lo que sucederá después de ejecutar git rm es lo que te digo inicialmente: Podrás dejar un registro de esta eliminación. Lo que cambia con los flags es qué va a pasar con los archivos.

Ahora bien, si usamos –cached el archivo que indiquemos no será eliminado, y pasará a ser un archivo untracked (Como si hubiéramos creado un archivo nuevo). Si usamos –force, git eliminará el archivo que le indiquemos de nuestro working tree o working directory.

Cuando hablamos de reset, tenemos otras opciones interesantes pero ya de cara a eliminar commits y ubicarnos sobre un commit determinado (Cuando no usamos reset HEAD, claro). Si usamos git reset --soft <commit-al-que-vamos-a-ir>, todos los archivos que estaban alojados en los commits posteriores al que vamos a ir, pasarán a formar parte del staging area, para hacer commits nuevos sin perder los cambios. Si usamos git reset --hard <commit-al-que-vamos-a-ir>, los commits posteriores al commit al que vamos a ir serán borrados y también los archivos que estaban alojados allí

Entiendo que,
git rm elimina archivos de git y de disco duro.

  • git rm --cached elimina los archivos de git
  • git rm --force elimina los archivos de git y del disco duro con posibilidades de recuperarlos utilizando comando avanzados

git reset volvemos al pasado y cambiamos la historia

  • git reset --soft borra el historial de commits de un archivo a excepción de aquellos cambios que se encuentren en staging
  • git reset --hard borra todo el historial de commit incluyendo los cambios que hasta ese momento existían en el staging area.

git reset HEAD toma los archivos que estén en el staging area y los coloca unstaged.

En conclusion el git reset HEAD hace lo contrario a git add:

git add: coloca archivos en el Staging area
git reset HEAD: saca los archivos colocados por git add

Esto se puede comprobar haciendo un ‘git status’ antes y después de cada comando.

puff bastantes conceptos D:

Notas del contenido espero sean de ayuda.

Comando rm
rm: Este comando nos permite eliminar archivos del repositorio, sin eliminar su historial por lo cual podremos RECUPERAR.

rm <nombre archivo> --cached: Sacaremos (Eliminación) del archivo del staging (index) pero continuará en el disco duro.

rm --forced: Elimina el archivo del repositorio y del disco duro (Se puede RECUPERAR con comandos avanzados ya que dejamos un rastro.)

Como recuperarlos : (Comandos sugeridos por el Git Bash)

git restore --staged <nombre archivo> se restaura en el staging.

git restore <nombre archivo> se restaura en el working directory o disco duro.

Comando reset (Se aplican cuando ya el commit ha sido creado)
reset: Este comando nos permite regresar a una versión o commit anterior sin la posibilidad de RECUPERAR.

reset --soft <id commit>: Regresa el repositorio al commit indicado, conservando los cambios en staging y disco duro permitiendo aplicarlos luego por medio de un commit.

reset --hard <id commit>: Regresa el repositorio al commit indicado, eliminando los cambios realizados posterior a este, tanto en staging como en disco duro. SIGNIFICA PELIGRO.

reset HEAD: El archivo continuara en el staging (index) pero los cambios realizados NO, mientras que el rm cached eliminará el archivo y sus cambios del staging. Este comando impide que los cambios de cierto archivo sean agregados al repositorio sin estar listos.

reset HEAD <nombre achivo>

Muy clara la explicación. Es importante la mención que git siempre guarda todo, incluso haciendo un git reset --hard, se puede recuperar los archivos.
Tenemos la siguiente lista de commits

8ccb7ca (HEAD -> master) Add style.css
d1ff77et Update index.html
98f16ab Add README.md
95c4bdb Update index.html
8ce9a45 Initial commit

Hago un git reset 8ce9a45 --hard y solo tengo

8ce9a45 (HEAD -> master)Initial commit

Si queremos recuperar los commits anteriores hay dos opciones, creamos una rama con el último commit antes del reset hard con git checkout -b 8ccb7ca, nos dirigimos a master y hacemos un merge con la rama creada.

git checkout -b 8ccb7ca # Creamos un rama con todos los commits  anteriores
git checkout master # Cambios a la rama master
git merge 8ccb7ca # Recuperamos todos los commits

La otra opción es realizar el comando git reset --hard con el último commit antes del primer reset hard 8ccb7ca

git reset 8ccb7ca --hard # Recuperamos los commits anteriores

De esta forma, podemos ver como git al final no borra nada totalmente.

La segunda forma fue enseñada en el curso de git y github de 2017 por Leonidas Esteban

Git reset HEAD y git rm –cached tienen el mismo efecto? Ambos regresan un archivo del Staging a Unstaged?
Aun no me queda claro si git rm --cached solo regresa archivos de Staged a Unstaged/Untracked o si tambien borra los registros de ese archivo de Git

Es bueno saber que aunque se aplique el git reset --hard, hacia el commit 1 (ejm: teniendo 10 commit de historia ),
pueden ser recuperados.
Esto se logra haciendo un git reset --hard y el hash (deben tenerlo copiado en algún lugar) del ultimo commit (hagan la prueba)

git reset HEAD y git restore --staged . son equivalentes ya que en ambos casos los archivos salen de staging con la única diferencia de que al usar git reset HEAD se muestran los archivos que salieron de staging.

git reset HEAD

git restore --staged .

Debemos tomar en cuenta también que con git restore --staged podemos indicar el o los archivos que queremos sacar de staging sin necesidad de sacar todos.

En cuanto a git rm --cached, este comando no es para sacar el archivo de staging sino para eliminar el archivo de la rama en la que estemos trabajando pero estaremos conservando una copia del archivo en nuestro disco local. Claro que este cambio (la eliminación) no se verá afectado hasta que demos commit.

Hola, en git recomienda usar git restore --staged “file” para quitar a un archivo del Staging Area
Y me llegó una duda, cual es la diferencia entre $git restore --staged “file” y $git reset HEAD
A lo que veo hacen lo mismo, pero por la sintaxis pienso que el git reset HEAD resetea el HEAD (version actual) con lo que también se eliminan los archivos de Staging Area Y $git restore --staged “file” nomás quita a dicho archivo de Staging Area…
¿Si es así?

¿Pero qué no si usamos git rm --cached file.txt lo sacamos del stage sin eliminarlo? ¿Cuál sería la diferencia entre rm --cached y reset HEAD?

Yo usaria el alias para cambiar de git reset a git usameconcuidado. :v

git reset --hard a todo cuando me despidan injustificadamente jojojo

#PlatziDay

Hay una posible solución si nos equivocamos haciendo git reset --hard.

  1. Uso reflog, muestra cronológicamente, una lista donde se fue ubicando HEAD y que se fue actualizando, incluso si hemos borrado algo, al menos por un cierto tiempo.
    git reflog
  2. Allí busco el commit al que quisiera volver y copio su sha1(el código de letras y números)
    a2e5728 [email protected]{10}: checkout: moving from master to origin/master
  3. Hago un reset hard al commit ese que acabo de buscar y que quisiera volver
    git reset --hard a2e5728
    Y voilà recuperamos algo que creíamos perdido.
    Por supuesto NO LLEGUES A ESTE PUNTO, trata de revisar muy bien antes de usar reset, pero tal vez esto podría salvarte.


Estoy aplicando lo que he aprendido en este curso mientras desarrollo el curso de programación básica, es increible porque ya tuve la necesidad de regresar a una versión anterior porque los cambios que hice no me resultaron y tuve la oportunidad de iniciar a partir de la última versión correcta que tenía.

Entonces git rm --cached y git reset HEAD hacen lo mismo? O existe alguna diferencia entre ellos? A lo que leo ambos sirven para sacar nuestros archivos del Staging Area en caso de que asi lo decidamos, pero sin borrarlo del disco.

Tengo una duda. Cuando ejecuto el comando git rm --cached <nombre_archivo> estoy eliminando el archivo de staged area y además lo estoy elimiandno de la carpeta .git?. Me queda la duda de la diferencia entre el git rm --cached y git reset HEAD, siento que son muy similares.

Un poco enredado sin embargo hay que practicar para coger el tiro

Tengo una duda, supongamos que quiero sacar los cambios que realice para que no se incluyan en el commit, eso implica que ya ejecute el comando git add . ¿Qué diferencia existe entre hacer git rm --cached y git reset HEAD?

Estuve practicando estos comandos, y surgió esta duda… cual es la diferencia entre git reset HEAD y git rm --cached ?

**Pienso que es mejor usar git reset HEAD
**
De hecho al hacer “git add .” te sugiere por default lo sig:

Changes to be committed:
(use “git reset HEAD <file>…” to unstage)

git rm: Borrar cosas del pasado.
git checkout: Saltar de una versión a otra sin borrar nada.
git reset: Volver al pasado cargándose todo lo que se atraviese.

Diferencias entre Git reset y Git rm:

  • Git reset, con sus distintos flags ya sea “–soft, --hard, reset HEAD”, Son unos comandos que se utilizan de una forma mas general o agresiva de modo que, mayormente funciona para eliminar archivos y volver pasos atras del proyecto o los cambios que se han hecho sin dejar rastro en el sistema.
  • Git rm, con sus distintos flags " --cached, --force" Es una forma menos agresiva de eliminar archivos de git sin eliminar todo el historial de versiones, lo que quiere decir que es menos agresivo y sera mas flexible al momento de buscar versiones anteriores antes de eliminar el archivo como tal, en caso que queramos hacerlo.

Quiero compartirles la información de este libro, me parece muy interesante para complementar 😃
https://git-scm.com/book/es/v2/Fundamentos-de-Git-Guardando-cambios-en-el-Repositorio

Hay compañeros que creo que ya hicieron buenísimos aportes complementando el tema, pero me gusta entenderlo como:
git checkout como dice la clase es ver la versión y regresar, no la afectas en nada
git rm elimina archivos pero aún seguirán registros de éstos dentro de Git
git reset vuelves a una versión anterior, conllevando a que puedas borrar absolutamente todo de alguna actualización que hayas realizado

Cual sería la diferencia entre: git rm --cached y git reset HEAD por lo que entiendo ambos quitan el archivo de staging.

Hola a todos !!
una pregunta esta parte del curo que es la clase número 13, no hay video?
me sale solamente explicación por texto.

Buenas, tengo una pregunta ¿Alguien sabe la diferencia entre $git rm --cached y $git restore --stage?
Veo que el primero me pasa de Stage a Untracked y el segundo me pasa de Stage a Unstaged pero no le veo ninguna utilidad, Gracias.

-Alguien que pueda aclararme las diferencias entre estos comandos porfavor?
$git reset HEAD Y $git restore --cached

jajaja Salvar tu puesto xD. Gracias por la información.

Entiendo que git rm --cached es muy similar a git reset HEAD.
Con los demas comandos de borrar hay que tener cuidado.

tomando nota para evitar incendios
Saludos desde Nicaragua

necesito una buena practica para sintetizar esto

Un monton de gente esta viendo este curso en el #PlatziDay, sencillamente genial!

Reset HEAD es un" control z" al commit
Rm cached lo desvincula de git pero archivo sigue existiendo

¿Y si en lugar de de usar el “git reset HEAD”, vuelvo a hacer un “git add .”? ,¿no da lo mismo?

Lo mas importante de toda esta teoria es hacer practicas rompiendo cosas, asi aprenderemos totalmente el flujo de git.

Yo estoy confuso, consigo hacer las prácticas con Freddy pero es demasiada información de golpe

Especificando un solo archivo:
Sacarlo del Stagin y mantener los cambios en el archivo:

#git rm --cached arhivo.txt

Borrarlo de git y del disco

#git rm --force arhivo.txt

Para varios (n) archivos:
Sacar archivos modificados del staging y mantener los cambios en los archivos

#git reset --soft

Borrar todos los cambios

#git reset --hard

Creo que #git rm --cached archivo.txt y #git reset HEAD hacen la misma función, sin embargo, rm es en particular para un solo archivo y reset HEAD para todos los archivos modificados dentro del directorio en donde te encuentres.

MUY BUENO EL CURSO, YO QUE VENGO DE UNA ESCUELA DE NEGOCIOS CREO QUE SERÁ NECESARIO DARLE UNA VUELTA A TODOS LOS CONCEPTOS PARA NO TENER PROBLEMAS CON COMANDOS REGRESOS COMO ESTOS.

Muy bueno, solo aún no me queda claro la diferencia de git rm --cached y git reset HEAD

git reset --hard. Borra…

Por si alguien tiene dudas todavía con el comando “rm”, a mi me ayudo este tutorial:
https://youtu.be/sSdYOJPvbzM

¿cual es la diferencia entre git rm --cached y git reset HEAD?

Rn lo personal git reset HEAD hace parte de mi diario vivir, en ocasiones realizo cambios que no deben ir a la rama y los saco con este comando

git reset HEAD nombre_archivo

Esto es muy útil para sacar cambios de tu próximo commit

Con esto queda en claro que voy a usar personalmente git , para arreglar y romper varias carpetas realizadas por mi antes de decir que puedo trabajar completamente con git.
Entonces tendré experiencia en lo que debo y no debo hacer, inclusive como salvar loas archivos de mis mocos realizados.

¿ $ git reset HEAD funciona igual que $ git restore --staged ?

Bueno, yo ya estuve practicando y me enamoré del git checkout. Del git reset no mucho, sobre todo --hard jajajaja

Cuál es la diferencia entre git rm --cached y git reset HEAD ?? Acaso es que el git rm --cached es solo para remover un archivo en especifico del area de staging? y “regresarlo al disco duro” y git reset HEAD para remover todo del area de staging (opuesto a un git add . ) ?

tomando notas para no incendiar la oficina en un futuro. excelente.

Buen curso. Debo terminarlo para mañana ya que el lunes comienzo a trabajar por primera vez xd.

Excelente lectura, pero aquí nace una duda. En este caso el comando utilizado en el ejemplo hipotético $ git reset HEAD básicamente funcionaría como un $ git restore --staged [archivo a sacar del staging], o cuál sería a su diferencia técnica, además de la cantidad de archivos a eliminar del staging en una sola acción?
.

Si todavía tienen alguna duda con respecto a git rm quiero mostrarles un ejemplo que yo mismo utilice para entenderle.

> git rm --cached file_name.txt : Es una opción para sacar literalmente el archivo de un commit, es como expulsarlo, ya no tendrá seguimiento alguno. Sin embargo, te permite agregarlo nuevamente al staging, el mismo git da el ejemplo de como hacerlo que basicamente es git add… o borrar el seguimiento git restore --staged <file>

> git rm --cached file_name.txt
> git status

On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
        deleted:    13. Git reset vs. Git rm
Untracked files:
(use "git add <file>..." to include in what will be committed)
        13. Git reset vs. Git rm        	

> git rm --force file_name.txt : Al contrario del comando anterior, este ya no te permitirá agregarlo nuevamente al stage, por lo que tendrias que crear literalmente el archivo o entrar al archivo y agregar algun cambio para que git reconozca que hay un archivo que no esta trackeado.

> git rm --force file_name.txt
> git status

On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
        deleted:    13. Git reset vs. Git rm

Cabe aclarar, que al hacer git rm, no se borra el archivo, unicamente desaparece el seguimiento.

Les cuento que practicando y practicando los comandos de rm y reset me pasó justo lo que freddy advirtió y es que se me borraron varios commits y no he podido recuperarlos. Mi history ya tenia como 7 commits y solo me quedaron 2, el primero y el último. Lo que me extraña es que yo estaba haciendo las pruebas solo con el primero y nose que pasó. En fin me queda de aprendizaje y saber que esto es realmente de mucho cuidado. Espero freddy explique mas adelante algún comando especial para recuperar los archivos borrados de forma agresiva por error.

#PlatziDay

#PlatziDay

#PlatziDay

#PlatziDay

Info que te saca de apuros… Excelente explicación

#PlatziDay

Creo que no se debe usar git reset después de las 12:00 de la media noche, el sueño te puede traicionar!!

Que buena explicación y me doy cuenta de que he estado usando **reset **en algunos casos cuando simplemente debí de usar checkout.

Hola estoy en este curso para reforzar mis conocimientos de Git. En lo largo del uso de Git, la mejor practica que puedes tener es trabajar por etapas, y a esas etapas manejarlas con branches (ramas). Cuando cada etapa concluye hacer un merge a master. Cada branch puede llegar a tener N sub branches con versiones o con el nombre de la funcionalidad. Ahi es cuando más sentido tiene usar branch para cuidar el curso del repositorio master que tiene practicamente la version de final de tu proyecto.

Mejor explicado Imposible.

Excelente el día de hoy voy en mi segundo día en Platzi repasando Git , ya que nunca lo había usado en mis proyecto pensé que era super difícil, pero ya lo veo mas claro y quiero nunca parar de aprender . Ya me monte en la nave espacial y voy por más … Gracias y Saludos.

Sería que para sacar a UN ARCHIVO de la staging area se usaría “git rm --cached <nombre del archivo>” y para sacar TODOS LOS ARCHIVOS de la staging area, se usaría “git reset HEAD” (siendo lo opuesto a “git add .”)

Permite sacar de apuros en el momento que se requiera, probe: “git reset HEAD nombre_archivo” y tambien funciona solo para el archivo que se desea ponerlo nuevamente fuera del staging es decir en estado unstaged.

Suena muy delicado, creo que tendré que hacer este curso al menos dos veces para interiorizar mejor

Adoro el Git Reset, me recuerda al drop database :3

Recién estoy aprendiendo a programar, y en mi caso, se me hace más difícil practicar (ya que no creo mucho código), así que estoy haciéndome un manual corto personalizado. Quizás a ustedes les sirva también esa técnica 😃

Excelente explicación
Dejo mi aporte
Para entender git reset en practica vean mis últimos 3 commits

<[email protected]Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master  git superlog            
* fc70cb3 - (7 seconds ago) border - tony (HEAD -> master)
* 20c71e4 - (3 minutes ago) margin - tony
* 52bc060 - (3 minutes ago) padding - tony
* 10c74ca - (31 minutes ago) proyectoReal con html y css - tony
* 774ac22 - (7 days ago) Commit2 - tony
* bb00cf1 - (7 days ago) Commit 1 - tony>

Noten que cuando utilizo git reset --soft únicamente se borrará el commit “border” que hice, sin embargo mis cambios en mi archivo no se han eliminado y de hecho me ha dejado esos cambios en el area de Staging listos para hacer commit

<tony@MacBook-Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master  git reset 20c71e4 --soft>
<[email protected]Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master  git superlog
* 20c71e4 - (9 minutes ago) margin - tony (HEAD -> master)
* 52bc060 - (9 minutes ago) padding - tony
* 10c74ca - (37 minutes ago) proyectoReal con html y css - tony
* 774ac22 - (7 days ago) Commit2 - tony
* bb00cf1 - (7 days ago) Commit 1 - tony%>
<[email protected]Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master ✚  git status    
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   css/estilis.css>

Cuando utilizo git reset --hard verán como ya no tengo cambios para hacer commit cundo uso git status, verán que mi commit “border” desapareció y que mis cambios también los he perdido.

<[email protected]  ~/Platzi/GitFreddy/proyecto   master  git reset 20c71e4 --hard
HEAD is now at 20c71e4 margin>
<[email protected]Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master  git superlog
* 20c71e4 - (9 minutes ago) margin - tony (HEAD -> master)
* 52bc060 - (9 minutes ago) padding - tony
* 10c74ca - (37 minutes ago) proyectoReal con html y css - tony
* 774ac22 - (7 days ago) Commit2 - tony
* bb00cf1 - (7 days ago) Commit 1 - tony% >
<[email protected]Pro-de-Effren  ~/Platzi/GitFreddy/proyecto   master  git status
On branch master
nothing to commit, working tree clean>

Es importante saber cuándo utilizar git reset y cómo utilizarlo ya que como hemos visto podemos perder nuestros cambios realizados.

Cual sería la diferencia entre git rm --cached y el git reset HEAD?.
el primero mueve los archivos que indique al estado untracked, pero el estar untracked no es lo mismo que estar unstaged?y el segundo sacarlo del área staging a unstaged, por lo que no entiendo muy bien la diferencia entre ambos o ambos pueden ser utilizados para el mismo fin?