¿Por qué dice Git que mi twig principal ya está "actualizada" aunque no lo esté?

Problema básico

Acabo de eliminar TODO el código de un file en mi proyecto y comprometí el cambio a mi git local (a propósito). yo si

git pull upstream master 

para search y fusionar desde la parte superior (por lo que, en teoría, el código eliminado debe estar de vuelta).

Git me dice que todo está actualizado.

Definitivamente, todo NO está actualizado: todo el código eliminado aún se borra.

Otra información relevante

Solo tengo una twig llamada "maestro".

Recientemente configuré "master" para rastrear upstream de esta manera:

El maestro de sucursal se configuró para rastrear el maestro de sucursal remota desde la parte superior.

El command git branch -vv produce:

 * master 7cfcb29 [upstream/master: ahead 9] deletion test 

¿Por qué por qué sucede esto? Estoy a punto de enviar un correo electrónico a mi gerente de proyecto sobre cualquier cambio que realice en nuestro código.

Actualizar

Pensé que era obvio, pero de todos modos este es mi objective:

Obtenga el código más reciente en mi sistema.

Disculpe mi ira aquí, pero ¿por qué una tarea tan simple como esa tiene que ser tan difícil?

Creo que su problema básico aquí es que está malinterpretando y / o malinterpretando lo que hace git y por qué lo hace.

Cuando clonas algún otro repository, git hace una copy de lo que está "allá". También toma "sus" tags de twig, como master , y hace una copy de esa label cuyo "nombre completo" en su tree git es (normalmente) remotes/origin/master (pero en su caso, remotes/upstream/master ) . La mayoría de las veces también omite los remotes/ parte, por lo que puede referirse a esa copy original como upstream/master .

Si ahora realiza y confirma algunos cambios en algunos files, usted es el único con esos cambios. Mientras tanto, otras personas pueden usar el repository original (del que hizo su clon) para crear otros clones y cambiar esos clones. Ellos son los únicos con sus cambios, por supuesto. Eventualmente, alguien puede tener cambios que le envían al dueño original (a través de "push" o parches o lo que sea).

El command git pull es básicamente una abreviatura de git fetch seguido de git merge . Esto es importante porque significa que necesita comprender lo que esas dos operaciones realmente hacen.

El command git fetch dice que regreses a donde sea que hayas clonado (o que hayas configurado de otra manera como un lugar para search) y encuentres "cosas nuevas que alguien más agregó o cambió o eliminó". Esos cambios se copyn y se aplican a su copy de lo que obtuvo de ellos antes . No se aplican a su propio trabajo, solo a los suyos.

El command de git merge es más complicado y es donde te estás yendo mal. Lo que hace, simplificado en exceso, es comparar "lo que ha cambiado en su copy" con "los cambios que ha obtenido de otra persona y, por lo tanto, ha sido agregado al trabajo de su-copy-de-la-otra-persona". Si sus cambios y sus cambios no parecen estar en conflicto, la operación de fusión los une y le da un "compromiso de fusión" que vincula su desarrollo y desarrollo juntos (aunque hay un caso "fácil" muy común en el que tiene no hay cambios y obtienes un "avance rápido").

La situación que está enfrentando ahora es aquella en la que ha realizado cambios y los ha comprometido (nueve veces, de hecho, de ahí el "futuro 9") y no han realizado cambios. Por lo tanto, fetch obedientemente no busca nada, y luego merge toma su falta de cambios y tampoco hace nada.

Lo que quiere es mirar, o quizás incluso "restablecer" a "su" versión del código.

Si simplemente desea verlo, simplemente puede verificar esa versión:

 git checkout upstream/master 

Eso le dice a git que quiere mover el directory actual a la twig cuyo nombre completo es en realidad remotes/upstream/master . Verá su código desde la última vez que ejecutó git fetch y obtuvo su último código.

Si desea abandonar todos sus propios cambios, lo que debe hacer es cambiar la idea de git de qué revisión debe nombrar su label, master . Actualmente nombra tu confirmación más reciente. Si vuelves a esa twig:

 git checkout master 

entonces el command de git reset te permitirá "mover la label", por así decirlo. El único problema restante (suponiendo que estés realmente listo para abandonar todo lo que has hecho) es encontrar dónde debe apuntar la label.

git log te permitirá encontrar los nombres numéricos, como 7cfcb29 que son nombres permanentes (que nunca cambian), y hay un número ridículo de otras forms de nombrarlos, pero en este caso solo quieres el nombre en upstream/master .

Para mover la label, borrando sus propios cambios (cualquiera que haya cometido es realmente recuperable por un time, pero es mucho más difícil después de esto, así que esté muy seguro):

 git reset --hard upstream/master 

El --hard le dice a git que --hard lo que ha estado haciendo, mueva la label de la twig actual y luego revise la confirmación dada.

No es súper común querer realmente git reset --hard y eliminar un montón de trabajo. Un método más seguro (por lo que es mucho más fácil recuperar ese trabajo si usted decide que algo valió la pena después de todo) es cambiar el nombre de su sucursal existente:

 git branch -m master bunchofhacks 

y luego crea una nueva twig local llamada master que "rastrea" (realmente no me gusta este término porque creo que confunde a la gente pero ese es el término git :-)) el master de origen (o upstream):

 git branch -t master upstream/master 

con el que luego puedes conectarte:

 git checkout master 

Lo que hacen los últimos tres commands (hay atajos para hacer solo dos commands) es cambiar el nombre pegado en la label existente, luego crear una nueva label y luego cambiar a ella:

antes de hacer cualquier cosa:

 C0 - "remotes/upstream/master" \ \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "master" 

después de git branch -m :

 C0 - "remotes/upstream/master" \ \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "bunchofhacks" 

después de git branch -t master upstream/master :

 C0 - "remotes/upstream/master", "master" \ \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 --- C8 --- C9 "bunchofhacks" 

Aquí C0 es la confirmación más reciente (un tree fuente completo) que obtuviste la primera vez que hiciste tu git clone . C1 a C9 son sus compromisos.

Tenga en count que si tuviera que hacer git checkout bunchofhacks y luego git reset --hard HEAD^^ , esto cambiaría la última image a:

 C0 - "remotes/upstream/master", "master" \ \- C1 --- C2 --- C3 --- C4 --- C5 --- C6 --- C7 - "bunchofhacks" \ \- C8 --- C9 

La razón es que HEAD^^ nombra la revisión dos desde el encabezado de la twig actual (que justo antes del reinicio sería bunchofhacks ), y reset --hard luego mueve la label. Los commits C8 y C9 ahora son en su mayoría invisibles (puedes usar cosas como el reflog y git fsck para encontrarlos, pero ya no es trivial). Tus tags son tuyas para moverte como quieras. El command fetch se encarga de los que comienzan con remotes/ . Es convencional hacer coincidir "tuyo" con "el suyo" (por lo que si tienen un remotes/origin/mauve también llamarías mauve tuyo), pero puedes escribir "suyo" cada vez que quieras nombrar / ver los commits que obtienes " de ellos". (Recuerde que "one commit" es un tree fuente completo. Puede seleccionar un file específico de una confirmación, con git show por ejemplo, si lo desea).

Como dicen los otros carteles, pull fusiona los cambios desde el upstream en su repository. Si desea replace lo que está en su repository con lo que está en el flujo ascendente, tiene varias opciones. Fuera del manguito, iría con

 git checkout HEAD^1 # Get off your repo's master.. doesn't matter where you go, so just go back one commit git branch -d master # Delete your repo's master branch git checkout -t upstream/master # Check out upstream's master into a local tracking branch of the same name 

Cualquier cambio que realice, como eliminar todos los files de su proyecto, seguirá en su lugar después de una extracción. Todo lo que hace un tirón es unir los últimos cambios desde otro lugar a su propia sucursal, y si su sucursal ha eliminado todo, en el mejor de los casos obtendrá conflictos de combinación cuando los cambios ascendentes afecten a los files que ha eliminado. Entonces, en resumen, sí, todo está actualizado.

Si describes qué resultado te gustaría tener en lugar de "borrar todos los files", tal vez alguien pueda sugerir un curso de acción apropiado.

Actualizar:

OBTENGA EL MÁS RECIENTE DEL CÓDIGO EN MI SISTEMA

Lo que parece que no entiendes es que ya tienes el código más reciente, que es tuyo. Si lo que realmente quieres es ver el trabajo más reciente de otra persona que está en la twig principal, simplemente hazlo:

 git fetch upstream git checkout upstream/master 

Tenga en count que esto no lo dejará en position de (re) iniciar su propio trabajo de inmediato. Si necesita saber cómo deshacer algo que ha hecho o revertir los cambios que usted u otra persona ha realizado, proporcione detalles. Además, considere leer sobre para qué es el control de versión, ya que parece que entiende mal su propósito básico.

Alguien por favor corrígeme si me equivoco, pero creo que esto se debe a que su sucursal está por delante de la sucursal maestra aguas arriba en 9 commits. Cuando haces un pull desde el control remoto, ya tienes esos cambios, es solo que estás por delante de ellos en 9 commits. No tendría sentido para esos cambios antiguos, que ya tiene en su historial y tiene 9 commits por delante, para replace sus nuevos cambios.

Creo que si las confirmaciones en el control remoto fueran más recientes, se fusionarían (de forma pnetworkingeterminada, a less que especifique --rebase ) en su twig actual.

Como dijo Ryan, sugiero que especifique exactamente cuál es su objective para que alguien pueda ayudarlo más directamente.

La respuesta superior es mucho mejor en términos de amplitud y profundidad de la información dada, pero parece que si quisieras que tu problema se solucionara casi de inmediato, y no te molesta pisotear algunos de los principios básicos del control de versiones, podrías …

  1. Cambiar a maestro

     $ git checkout upstream master 
  2. Eliminar su twig no deseada. (Nota: debe tener el -D, en lugar del indicador -d normal porque su twig tiene muchas confirmaciones por delante del maestro).

     $ git branch -d <branch_name> 
  3. Crea una nueva sucursal

     $ git checkout -b <new_branch_name>