Hice una confirmación que incluye los siguientes cambios:
main a un nuevo file aux aux Desafortunadamente, esto hace que la confirmación sea difícil de revisar en GitHub, porque GitHub muestra la diferencia como si se hubiera eliminado y reinsertado todo el fragment. Idealmente, el revisor solo vería las ediciones menores realizadas en aux después del movimiento del contenido.
Me gustaría agregar un compromiso intermedio para simplificar la revisión de este cambio. El compromiso intermedio simplemente duplicaría main a aux (es decir, aux sería una copy de main ). Luego, la siguiente confirmación eliminaría el contenido movido de main y mostraría los cambios menores a aux . ¿Es esta una buena manera de hacerlo, y si es así, cómo debo crear este compromiso intermedio? Tenga en count que, lamentablemente, ya completé el cambio y preferiría no volver a hacer todo el process.
Esto se puede hacer, pero tenga en count que si ha publicado la confirmación (como parece), no se recomienda editar ningún historial. Entonces hay algunos procedimientos posibles. A los efectos de estas explicaciones, asumiré que los cambios se encuentran en una twig my_branch . (Funciona bien si la twig en cuestión es master , solo necesitaba asumir algo para escribir commands).
Simple pero tosco
Podrías volver a la confirmación anterior, crear una twig temporal y crear tu confirmación intermedia en esa twig. Luego dígales a los revisores que primero revisen el cambio en la sucursal temporal, luego my_branch su my_branch la sucursal temporal. Si sus revisores van a ir por eso, entonces les da los diffs más simples sin desorder. Pero tal vez no preserve la historia de la mejor manera.
Con la reescritura de la historia
Si puedes hacerlo, obtendrás un historial más limpio. Pero implica la reescritura de la historia, y como se señaló anteriormente, esto podría causar problemas a otros usuarios de los repositorys a los que se les haya aplicado el cambio. Consulte la documentation de git rebase re: Recuperación desde una rebase ascendente
Si esto no es un problema, o si encuentra que el procedimiento de recuperación es aceptable, puede hacer esto:
Primero, revise la confirmación antes del cambio. Asumo que es
git checkout my_branch^
Ahora estás en estado de cabeza separada. Probablemente sea bueno crear una sucursal temporal:
git checkout -b temp_branch
Copie main a aux y commit.
Luego, quiere una confirmación que se parezca a la HEAD my_branch , pero desea que su padre sea la HEAD de temp_branch . Si aux es lo único que cambió en esa confirmación:
git checkout my_branch -- aux git commit git branch -f my_branch
Si hay otros cambios en la confirmación, puede ser más fácil volver a criarlos. Hay un ejemplo en stock de cómo hacer esto en la documentation de git filter-branch ( https://git-scm.com/docs/git-filter-branch )
Por supuesto, en este momento puedes limpiar temp_branch . Es posible que tengas que "presionar forzar" my_branch (si ya se ha publicado).
git checkout my_branch git push -f
Y esa es la señal que todos los demás desarrolladores pueden necesitar para recuperar si también tienen references a my_branch .
Sin reescritura de la historia
Si ninguno de los anteriores puede funcionar, entonces puede intentar esto: Primero, use git revert para volver a antes del cambio. Luego, vuelva a aplicar el compromiso en dos fases.
De nuevo, la confirmación intermedia es fácil de realizar (lo mismo que en el caso de reescritura). Si los cambios en main y aux son el único cambio en la confirmación, entonces puede volver a extraer aux del commit original para simplificar la creación del commit final. Pero esta vez el command será
git checkout HEAD^ -- aux
porque HEAD es el compromiso de revertir, por lo que HEAD^ es el que tiene el cambio en él.
Si el compromiso tiene cambios adicionales, entonces un braoder
git checkout HEAD^ -- .
podría hacer, pero me inclinaría a rm -r el tree de trabajo primero simplemente por paranoia. Independientemente de los pasos que intente, puede validar que ha recreado el tree final correctamente con
git diff HEAD^
Así que ahora tienes esta historia extraña de ida y vuelta, pero no hay reescritura y no hay una "segunda twig" involucrada en hacer una validation simplificada. Por supuesto, puede que aún tenga que validar en dos pasos: primero muestre que HEAD^ es igual al estado validado anterior, luego valide el parche de HEAD^ to HEAD .