estoy usando Husky
en mi proyecto ReactJs. La idea es que cuando el usuario confirme los cambios, se deben ejecutar algunos comandos de pelusa. Para esto, agregué en mi package.json
:
"lint": "next lint --fix",
"lint:fix": "lint && git add -A .",
Antes de enviar el mensaje ejecuto lint:fix
. Todo está funcionando.
También sé que este comando git add -A .
agregará los cambios si se producirán después lint
comando, por lo que si el desarrollador se comprometerá => lint
solucionará los problemas => y si hay algunos cambios, git automáticamente agregará estos cambios al compromiso sin volver a hacerlo git add .
y git commit -m ...
.
Pregunta: Tener este comando git add -A .
alguna desventaja y está bien agregar allí?
Tenga este comando git add -A . cualquier desventaja
Primero git add .
es suficiente (la -A
es el predeterminado desde Git 2.x)
En segundo lugar, el principal inconveniente (en general) es que agrega todo, incluso si puede tener otras modificaciones no relacionadas. También agrega nuevos archivos.
En su caso (utilizado en un gancho de confirmación previa), ha preparado su índice (git add
solo los archivos que desea confirmar): el git add .
podría arriesgarse a agregar otro archivos que inicialmente no deseaba incluir en su próxima confirmación.
otra pregunta, es lint-staged
(https://npmjs.com/package/lint-staged) lo mismo que git add -u
en mi situación”lint:fix
“: “lint && git add -u
“?
los Léame menciones:
Desde v10.0.0 en adelante, cualquier modificación nueva a los archivos preparados originalmente se agregará automáticamente a la confirmación.
Si su tarea anteriormente contenía un git add
paso, elimine esto.
El comportamiento automático asegura que haya menos condiciones de carrera, ya que tratar de ejecutar múltiples git
operaciones al mismo tiempo generalmente resulta en un error.
En general, usted no debe correr
git add
en cualquier enlace previo a la confirmación. Tú deberían probar lo que el usuario ha proporcionado como “Tengo la intención de confirmar estas versiones”, y si la prueba falla, prohíba la confirmación mientras dice por qué está prohibiendo la confirmación. Deje que el usuario ejecute cualquier tipo de operación de “arreglar automáticamente mis archivos”: el enlace previo a la confirmación es solo un verificadorNo un reparador.– torek
29 de marzo a las 18:00