Cómo mostrar commites, solo para alguna twig

Necesito get una list de commites, que empujó, por ejemplo, en la twig 'task / 105'.

Quiero decir, necesito get commites, empujado a la twig 'task / 105', en el range desde el primer commit en la twig 'task / 105', hasta el último.

Intenté hacer lo siguiente:

git /dir/project git checkout task/105 git log task/105 

Pero no ayuda. Me muestra commites para otras twigs y para la twig 'test' ambas.

Leí, ¿qué tengo que hacer algo como esto?

 git log TASK_105_FIRST_COMMITE..task/105 

Pero no sé, cómo get el primer compromiso para la tarea / 105 que leí, lo que puede ayudar:

 git merge-base master task/105 git log as65g76s5dgsd5gsd6sd65g4s...task/105 

Pero me confundí con la palabra 'maestro'. ¿Cómo si commit en master se presiona después de presionar commites en la tarea / 105?

Finalmente, realmente no sé qué hacer … Lo siento por el mal inglés

(No estoy seguro de lo que quiere decir con "primer compromiso", y "empujado" me hace pensar que podría estar mirando una situación más restringida).

En general, para marcar commits específicos con un nombre, uno debe usar las "tags" de git, o una reference que "actúa como" una label.

Aquí hay un poco de background básico necesario:

  • Cada confirmación en un repository de git actúa como una "instantánea" de un tree de directorys lleno de files. Esta instantánea tiene una date asociada, autor / confirmador y post. 1
  • Cada confirmación también tiene un set único de "confirmaciones principales" (ninguna para una confirmación raíz, 1 padre para una confirmación ordinaria, 2, o incluso más, para una confirmación de fusión).
  • Cada confirmación (y también los otros tres types de objects almacenados en el repository) tiene un único "nombre verdadero", el ID SHA-1, generalmente expresado como una cadena hexadecimal de 40 caracteres como bd5d3781a8e32d3627bb1de70dc6b105dc9d77a0 (a menudo abreviado a los primeros 7 caracteres) .
  • Estos "verdaderos nombres" son poco sólidos y no son buenos para el uso humano, por lo que git agrega "references" como "twigs" y "tags". Estos son nombres más fáciles de usar como refs/heads/master y refs/tags/v1.3 . Por lo general, también puede omitir las refs/heads/ y refs/tags/ parts.

Un nombre de twig o label es realmente solo una forma de especificar el SHA-1, con otra exception:

  • Una twig "local" -una reference que vive en el espacio de refs/heads/ names- se mueve automáticamente cuando es necesario. (Una twig "remota", en refs/remotes/ , también se mueve cuando se fetch desde el control remoto. De manera más general, la idea es que "las twigs se mueven pero las tags no").

Al agregar una nueva confirmación, git commit -m 'fix some bug' , busca la twig actual, que podría ser master , o podría ser task/105 , o cualquier otra cadena de nombre de twig válida; es una twig si está prefijada por la parte refs/heads/ normalmente es invisible. Al haber encontrado la twig actual (y su correspondiente valor SHA-1), el command de git commit escribe una nueva confirmación en el repository, cuyo padre es el actual SHA-1. La nueva confirmación tiene un nuevo valor SHA-1 único, y la git commit cambia el nombre de la twig para apuntar a la nueva confirmación, que las personas llaman "mover la twig hacia adelante".

Git no 2 registra el "valor anterior" de la twig aquí. Simplemente cambia el nombre de la sucursal -> mapeo SHA-1. Entonces, ¿cómo se puede saber a qué compromiso se ha referido la sucursal? La respuesta es que no se puede , no con un 100% de fiabilidad (ver nota 2).

Si necesita marcar una confirmación con un nombre, esto es para lo que están destinadas las "tags". Hay dos types de tags: las tags "anotadas" (que en realidad residen dentro del repository git y pueden autenticarse si es necesario) y las tags "ligeras".

Una label liviana consiste en un nombre externo que vive en el espacio de nombres refs/tags/ , apuntando a una confirmación, al igual que una twig, excepto que no se mueve automáticamente. (Puede moverlo manualmente, con los indicadores de "fuerza").

Una label anotada consta de una label externa (liviana) que apunta a un object de repository git del tipo "label", que transporta información muy similar a un object de confirmación de git: date, autor, etc. Sin embargo, un object de compromiso "apunta a" un tree, mientras que un object de label "apunta a" un object de compromiso (que luego apunta a un tree). 3

Con todo eso en mente, lo que las personas llaman "una twig" suele ser una pieza de un gráfico de compromiso. Un gráfico de compromiso se forma tomando todas las confirmaciones referencedas externamente (aquellas con nombres de twig y label, más algunos otros casos especiales) y "trabajando hacia atrás" a lo largo de las references principales para encontrar más confirmaciones. Esto se puede escribir o dibujar algo como esto:

  o--o--o / \ ...--o--o--o--o---o--o <-- refs/heads/master \ o <-- refs/tags/v0.9 \ o--o <-- refs/heads/devel 

Aquí, los pequeños representan los nodos de confirmación y las flechas <-- muestran los compromisos referencedos externamente.

Por lo tanto, si tiene un único repository (en su máquina de desarrollo, por ejemplo) y desea saber qué cometidos sucedieron "después del punto X " y "a través de la punta de la twig señalada con el nombre Y ", debe save (en algún lugar) el "verdadero nombre" (SHA-1) para "punto X ". Digamos que el "punto X " fue capturado anteriormente cuando hicimos la label v0.9 , y ese "punto Y " es en realidad " devel twig". Entonces:

 v0.9..devel 

es una taquigrafía estándar de revisión de git que significa "todas las confirmaciones accesibles desde el nombre de devel , excluyendo todas las confirmaciones accesibles desde el nombre v0.9 ". Dado que v0.9 es una label válida, esto le proporcionará solo los últimos dos o--o commits.

Pedir master..devel te proporcionará "commits alcanzable desde el devel , excluyendo compromisos accesibles desde el master ". No es importante que haya cometidos accesibles desde el master que no sean alcanzables desde el devel : se puede pensar que se toma un marcador de color y se dibuja "hacia atrás" desde refs/heads/master , coloreando todos los commits que se pueden alcanzar moviéndose hacia la izquierda en el dibujo (pero nunca moviéndose hacia la derecha). Luego tomas un segundo color y color diferente en todas las confirmaciones de refs/heads/devel pero no vuelves a colorear ningún commit ya coloreado. Entonces en este caso, master..devel obtiene tres commits: el nombrado por refs/tags/v0.9 , más los dos últimos commits.

Ahora, sigues mencionando "empujado", que trae una nueva y diferente arruga. Cuando ejecuta la git push origin branch , hay dos repositorys involucrados: el suyo, con su nombre de refs/heads/branch , y "origen" (en alguna otra URL), con su nombre de refs/heads/branch .

Si el empujón tiene éxito en actualizar (y no "crear") sus refs/heads/branch , eso significa que tenía algún SHA-1 anterior identificado por refs/heads/branch , y una vez que termina el push, tiene algunos nuevos y diferentes SHA-1 identificó, específicamente, el que acaba de empujar con éxito.

Si quieres saber "a qué compromiso se refs/heads/branch sus refs/heads/branch antes de que lo cambiara", bueno, él es el único que sabe eso. La mejor manera de averiguarlo es preguntárselo. Puedes usar git ls-remote para hacer esto, o git fetch . En general, debe search antes de presionar de todos modos, por lo que esa es probablemente la opción adecuada. Sin embargo, aquí hay un problema, ya que hay una carrera entre lo que él te dice cuando preguntas ( ls-remote o fetch ) y lo que tiene cuando finalmente te git push por ahí. Incluso si trabaja muy rápido, en los pocos milisegundos entre su consulta y su push , alguien más podría queuerse y hacer un push diferente y cambiar las cosas. Entonces, la mejor manera de averiguar qué se actualizó "de su lado" es que él te lo diga, generalmente a través de un "gancho después de la recepción". (Este gancho se entrega "triples-SHA-1, nuevo-SHA-1, renombre" triples).


1 De hecho, hay dos dates y nombres de usuario separados, uno para "autor" y otro para "committer". Prueba git cat-file -p HEAD para ver los datos sin formatting (mayormente) dentro de un commit.

2 En realidad, git registra el valor anterior, en el "reflog" … pero los reflogs no son permanentes. Si necesita recuperar un SHA-1 olvidado, dentro del time de vencimiento, está allí; pero si lo quiere como un elemento más permanente, no es para lo que está diseñado el reflog, y será incómodo usarlo de esa manera.

3 De hecho, las tags pueden apuntar a más tags (anotadas), y eso se considera uso normal. También es físicamente posible señalar cualquier reference a un "tree" o "blob" dentro del repository, pero esos no son usos normales para refs/heads/ y refs/tags/ references.