Respuestas:
Rara vez hay una buena razón para hacer esto, pero el parámetro es --allow-empty
para confirmaciones vacías (sin archivos modificados), en contraste con --allow-empty-message
los mensajes de confirmación vacíos. También puede leer más escribiendo git help commit
o visitando la documentación en línea .
Si bien el objeto del árbol (que tiene un hash propio) será idéntico, el commit tendrá un hash diferente, porque presumiblemente tendrá una marca de tiempo y un mensaje diferentes, y definitivamente tendrá un commit padre diferente. Los tres factores están integrados en git
el algoritmo hash del objeto.
No son algunas de las razones es posible que desee un Empty cometen (que incorpora algunos de los comentarios):
git
comandos sin generar cambios arbitrarios (a través de Vaelus ).gitolite
(a través de Tatsh ).Otras estrategias para agregar metadatos a un árbol de confirmación incluyen:
git notes
asociar una nota mutable encima de una confirmación inmutable existente.commit --amend
si el control remoto no permite la presión forzada. De esta forma, puede permitir que los desarrolladores vean un mensaje importante que va con la confirmación anterior.
Si está utilizando un sistema como gitversion Tiene mucho sentido hacer este tipo de confirmación. Podría tener un commit que sea específicamente para eliminar la versión principal utilizando un + semver: comentario principal.
Tal vez como una alternativa más sensata, podría crear una etiqueta anotada (una confirmación con nombre con un mensaje). Ver la git tag -a
opción
dev
formulario de bifurcaciónmaster
y luego unafeat
bifurcación inmediatamentedev
, lafeat
bifurcación parece provenir de lamaster
bifurcación, ya que no hay confirmación distintiva en ladev
bifurcación de la quefeat
proviene la bifurcación. Una confirmación vacía cuando realiza ladev
rama por primera vez ayuda a establecer ladev
rama como su propia rama indefinidamente independientemaster
. En general, es útil cuando usa ramas como capas y crea dos capas desde una única confirmación