git - sobrescritos - ¿Cómo verificamos los mensajes de confirmación para un impulso?

git ver archivos modificados

Question

Desde CVS, tenemos una política que indica que los mensajes de confirmación se deben etiquetar con un número de error (sufijo simple "... [9999]"). Un script de CVS comprueba esto durante las confirmaciones y rechaza la confirmación si el mensaje no se ajusta.

El git hook commit-msg hace esto en el lado del desarrollador, pero nos resulta útil contar con sistemas de verificación automatizados y recordárnoslo.

Durante un empujón de git, commit-msg no se ejecuta. ¿Hay otro gancho durante el envío que pueda verificar los mensajes de confirmación?

¿Cómo verificamos los mensajes de confirmación durante un git push?

Answer 1

Usando el gancho de actualización

Usted sabe acerca de los ganchos - por favor, lea la documentation sobre ellos! El gancho que probablemente desee es actualizar, que se ejecuta una vez por referencia. (El gancho de recepción previa se ejecuta una vez para todo el empuje) Hay toneladas y toneladas de preguntas y respuestas sobre estos ganchos ya en SO; Dependiendo de lo que quiera hacer, probablemente pueda encontrar orientación sobre cómo escribir el gancho si lo necesita.

Para enfatizar que esto es realmente posible, una cita de los documentos:

Este gancho se puede usar para evitar la actualización forzada en ciertas referencias al asegurarse de que el nombre del objeto sea un objeto de confirmación que sea descendiente del objeto de confirmación nombrado por el nombre de objeto antiguo. Es decir, para hacer cumplir una política de "solo avance rápido".

También podría usarse para registrar el estado antiguo ... nuevo.

Y los detalles:

El gancho se ejecuta una vez para que cada referencia se actualice, y toma tres parámetros:

• El nombre de la referencia que se está actualizando,
• el antiguo nombre del objeto almacenado en la referencia,
• y el nuevo nombre de objeto para ser almacenado en la ref.

Entonces, por ejemplo, si quiere asegurarse de que ninguno de los sujetos de confirmación tenga más de 80 caracteres, una implementación muy rudimentaria sería:

#!/bin/bash
long_subject=$(git log --pretty=%s $2..$3 | egrep -m 1 ''.{81}'')
if [ -n "$long_subject" ]; then
    echo "error: commit subject over 80 characters:"
    echo "    $long_subject"
    exit 1
fi

Por supuesto, eso es un ejemplo de juguete; en el caso general, usaría una salida de registro que contenga el mensaje de confirmación completo, lo dividiría por confirmación y llamaría a su código de verificación en cada mensaje de confirmación individual.

Por qué quieres el gancho de actualización

Esto ha sido discutido / aclarado en los comentarios; Aquí hay un resumen.

El gancho de actualización se ejecuta una vez por ref. Una referencia es un puntero a un objeto; en este caso, estamos hablando de ramas y etiquetas, y generalmente solo de ramas (las personas no presionan las etiquetas con frecuencia, ya que generalmente son solo para marcar versiones).

Ahora, si un usuario está empujando actualizaciones a dos sucursales, maestra y experimental:

o - o - o (origin/master) - o - X - o - o (master)
 /
  o - o (origin/experimental) - o - o (experimental)

Supongamos que X es la confirmación "incorrecta", es decir, la que fallaría en el enlace commit-msg. Claramente no queremos aceptar el impulso de dominar. Por lo tanto, el gancho de actualización rechaza eso. ¡Pero no hay nada malo con los compromisos en el experimental! El gancho de actualización acepta que uno. Por lo tanto, el origen / maestro permanece sin cambios, pero el origen / experimental se actualiza:

o - o - o (origin/master) - o - X - o - o (master)
 /
  o - o - o - o (origin/experimental, experimental)

El enlace de recepción previa se ejecuta solo una vez, justo antes de comenzar a actualizar refs (antes de la primera vez que se ejecuta el enlace de actualización). Si lo usara, tendría que causar que todo el impulso fallara, por lo tanto, diciendo que debido a que había un mensaje de confirmación incorrecto en el maestro, de alguna manera ya no confía en que las confirmaciones en experimental sean buenas, ¡aunque sus mensajes estén bien!

Answer 2

Esta es una versión de Python de pre-receive , que me tomó un tiempo terminar, espero que pueda ayudar a otros. Principalmente lo uso con Trac, pero podría modificarse fácilmente para otros propósitos.

También he dejado las instrucciones para modificar de nuevo el mensaje de confirmación histórico, que es un poco más complicado de lo que pensaba.

#!/usr/bin/env python
import subprocess

import sys 
import re

def main():
    input  = sys.stdin.read()
    oldrev, newrev, refname = input.split(" ")
    separator = "----****----"


    proc = subprocess.Popen(["git", "log", "--format=%H%n%ci%n%s%b%n" + separator, oldrev + ".." +  newrev], stdout=subprocess.PIPE)
    message = proc.stdout.read()
    commit_list = message.strip().split(separator)[:-1] #discard the last line

    is_valid = True

    print "Parsing message:"
    print message

    for commit in commit_list:
        line_list = commit.strip().split("/n")
        hash = line_list[0]
        date = line_list[1]
        content = " ".join(line_list[2:])
        if not re.findall("refs *#[0-9]+", content): #check for keyword
            is_valid = False

    if not is_valid:
        print "Please hook a trac ticket when commiting the source code!!!" 
        print "Use this command to change commit message (one commit at a time): "
        print "1. run: git rebase --interactive " + oldrev + "^" 
        print "2. In the default editor, modify ''pick'' to ''edit'' in the line whose commit you want to modify"
        print "3. run: git commit --amend"
        print "4. modify the commit message"
        print "5. run: git rebase --continue"
        print "6. remember to add the ticket number next time!"
        print "reference: http://.com/questions/1186535/how-to-modify-a-specified-commit"

        sys.exit(1)

main()

Answer 3

No mencionó cuál es su rastreador de errores, pero si es JIRA , entonces el complemento llamado Política de Compromiso puede hacer esto sin ninguna programación.

Puede configurar una condición de confirmación que requiere que el mensaje de confirmación coincida con una expresión regular. Si no lo hace, se rechaza el empuje, y el desarrollador debe enmendar (arreglar) el mensaje de confirmación, luego presionar nuevamente.

Answer 4

Podrías hacerlo con el siguiente gancho de pre-receive . Como han señalado las otras respuestas, este es un enfoque conservador, de todo o nada. Tenga en cuenta que protege solo la rama maestra y no impone restricciones a los mensajes de confirmación en las ramas temáticas.

#! /usr/bin/perl

my $errors = 0;
while (<>) {
  chomp;
  next unless my($old,$new) =
    m[ ^ ([0-9a-f]+) /s+   # old SHA-1
         ([0-9a-f]+) /s+   # new SHA-1
         refs/heads/master # ref
       /s* $ ]x;

  chomp(my @commits = `git rev-list $old..$new`);
  if ($?) {
    warn "git rev-list $old..$new failed/n";
    ++$errors, next;
  }

  foreach my $sha1 (@commits) {
    my $msg = `git cat-file commit $sha1`;
    if ($?) {
      warn "git cat-file commit $sha1 failed";
      ++$errors, next;
    }

    $msg =~ s//A.+? ^$ /s+//smx;
    unless ($msg =~ //[/d+/]/) {
      warn "No bug number in $sha1:/n/n" . $msg . "/n";
      ++$errors, next;
    }
  }
}

exit $errors == 0 ? 0 : 1;

Se requieren todas las confirmaciones en un impulso para tener un número de error en algún lugar de sus respectivos mensajes de confirmación, no solo la sugerencia. Por ejemplo:

$ git log --pretty=oneline origin/master..HEAD 354d783efd7b99ad8666db45d33e30930e4c8bb7 second [123] aeb73d00456fc73f5e33129fb0dcb16718536489 no bug number $ git push origin master Counting objects: 6, done. Delta compression using up to 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (5/5), 489 bytes, done. Total 5 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. No bug number in aeb73d00456fc73f5e33129fb0dcb16718536489: no bug number To file:///tmp/bare.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to ''file:///tmp/bare.git''

Digamos que solucionamos el problema aplastando los dos compromisos y presionando el resultado:

$ git rebase -i origin/master [...] $ git log --pretty=oneline origin/master..HEAD 74980036dbac95c97f5c6bfd64a1faa4c01dd754 second [123] $ git push origin master Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 279 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To file:///tmp/bare.git 8388e88..7498003 master -> master

Answer 5

Usted necesita hacer un script en su pre-recepción.

En este script recibe la revisión antigua y nueva. Puedes verificar todo el commit y devolver false si uno de estos es malo.