Así que he saltado muchos aros para hacer que el flujo de trabajo git de fork/rebase/pull sea atractivo para los desarrolladores de mi equipo que temen el control de versiones y la línea de comandos.Forzar git para realizar confirmaciones no operativas durante rebase
En la adición de un artículo de rebase en nuestro wiki de desarrollo, acabo de llegar al punto en que digo "Haz git rebase. Si hay algunos conflictos de fusión, solucionarlos. A continuación, realice una git add. A continuación, realice git rebase --continue."
Pero en el trabajo a través del ejemplo y tomando las capturas de pantalla, me acordé de que si hay un conflicto de combinación, y resolverlo en favor de la rama aguas arriba, haciendo un git rebase --continue, de hecho, se niega a continuar y da un error:
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.
Hay una excelente discusión de los detalles técnicos aquí: Git rebase: conflicts keep blocking progress
Pero lo que me gustaría es hacer que este comportamiento parada.
Supongo que hay una buena razón de diseño para que esto ocurra (probablemente relacionado con rebase simplemente usando la maquinaria de confirmación normal, donde este comportamiento probablemente tenga sentido) pero en esta situación es confuso e intuitivo y hace que la lógica del conflicto conflicto. Si su solución se ve exactamente como la rama ascendente, haga un git rebase --skip. En todos los demás casos, haga un git rebase --continue. "
¿Hay alguna manera de silenciar este comportamiento, ya sea con un indicador para rebasear o en un archivo de configuración controlado por versión (para no tener que configurarlo en la computadora de cada desarrollador o proporcionar instrucciones para hacerlo)?
No creo que este sea un duplicado de esa pregunta. El OP de allí está preguntando cómo omitir la rebase de commits vacíos, mientras que OP aquí está preguntando cómo permitir que 'git rebase' cree commits vacíos. –
¿Pero por qué quieres una confirmación vacía? Una confirmación vacía significa que todo el trabajo realizado en ella se introdujo en una confirmación de la rama que se volvió a establecer en. En ese caso, toda la confirmación debe ser eliminada. Eso podría hacerse después del hecho (por ejemplo, mediante el uso de una rebase interactiva y omitiendo la confirmación no deseada) u otros métodos, pero sin duda es "incorrecto" tener una confirmación vacía. – ErikE