Squash confirma arbitrariamente en una twig remota

Soy un poco novato con Git y tuve la tarea de limpiar el historial de una function que desarrollé recientemente. Tengo una configuration similar a este tipo aquí . También quiero lograr lo mismo, pero quiero aplastar a compromisos específicos. Por ejemplo, si mis commits son commit1, commit2, …, commitN , quiero hacerlo de modo que commit1, commit2, … sean aplastados para commitX ; commitX + 1, commitX + 2, … están aplastados para commitY ; etc.

Entiendo que esto es posible con el command

git rebase -i origin/*branch_name* 

pero el problema es que cuando ejecuto ese command, obtengo esto:

 noop # Rebase a112005..a112005 onto a112005 (1 command(s)) ... 

Por lo que yo entiendo, el último y el primer commit deben mostrarse aquí, pero solo ve el último commit. Cuando trato de ejecutar pick o squash con cualquier otro commit dice:

 error: could not apply *commit hash*... *commit message* 

lo que obviamente significa que encuentra la confirmación ya que conoce su post, pero por alguna razón, ni siquiera lo ve como editable. ¿Alguien tiene alguna idea de cómo puedo solucionar esto? Además, si alguien recomienda un mejor sistema de synchronization basado en la terminal para mi configuration o una mejor forma de organizar mis cosas, estaría agradecido.

No puede hacer nada en una sucursal de seguimiento remoto. De hecho, no puede estar "en" una sucursal de seguimiento remoto en primer lugar. (El command git checkout es el que lo coloca "en una twig", como muestra el git status , pero no lo ubicará en una sucursal de seguimiento remoto, solo en una sucursal local).

En general, para hacer que algo suceda en un repository de Git, debe hacerlo en su repository de Git, usando sus nombres de twig.

Cuando desee que suceda algo en el repository de Git de otra persona (como el de origin ), la forma de hacerlo es, primero, configurar todo en su repository, luego use git push para pedirle que tome su trabajo. en su repository y establecer uno de sus nombres de twig para que coincida.

Si les preguntas -el otro Git que controla ese otro repository- para configurar su branch-name para que apunte a un compromiso específico, 1 y ellos están de acuerdo, entonces , en ese punto, tu Git establecerá tu origin/ branch-name de tucursal a punto a ese mismo compromiso, ya que su Git le ha dicho a los suyos que sí, ahora está usando ese compromiso particular para esa twig en particular.


1 Tienen que comprometerse, pero tu git push se lo dará primero, si es que todavía no lo tienen. Así es como funciona git push . En primer lugar, le entrega el set de objects que tiene y que no necesita para aceptar sus requestes; luego, entrega una serie de requestes: "Configure la twig B1 para que asigne 1234567 … , y / o bifurque B2 para confirmar 89abcde … , y / o establezca la label T en …". Su Git no obedece ninguna, algunas o todas estas requestes, enviando respuestas "ok" o "no, y here's why" para cada una.