Usar
git checkout para regresar al commit anterior y seguir realizando commits desde ese punto no es la mejor de las ideas.
Para eso existe
git reset.
1. Commit en Master (A).
2. Nueva rama dev.
3. Commit en dev (B) (archivo.js).
4. Commit en dev (C) (borras archivo.js).
5.
git reset HEAD^ --hard o
git reset B --hard6. Ahora estás en B.
Y ahora puedes seguir haciendo commits.
Como tu lo estás haciendo, los cambios entre
dev2 y
dev borran el archivo.
En tu ejemplo, tienes otro commit (D) que hace otros cambios. De:
B--C (borraste archivo)
\
D (otros cambios)
Si haces una unión de C y D, vas a crear un merge commit (E).
Donde se agregan los cambios de de C y D (es un merge de 3 puntos), respectivamente. Git ve que eliminaste un archivo en C y no se que hayas hecho en D pero también lo ve.
Entonces los cambios los agrega y el resultado es o un merge conflict (porque editaste el archivo en D y git no sabe que cambios usar, si los de D o los de C) o tu archivo acaba borrado (porque esos son los cambios introducidos por C).
No tienes porque hacer
git merge en este caso. Simplemente, olvidate del commit que existe. Si has hecho lo del
git checkout forza la cabeza de la rama
dev a que apunte al commit D. Lo puedes hacer haciendo:
git branch -f dev
estando sobre el commit D o
git branch -f dev D
para ser más especifico.
Autor
En línea
