Incluye commits originales con commit aplastado al presionar a control remoto?

Pregunta

¿Cuál es una buena manera de asegurar que el control remoto tenga las confirmaciones que están dentro de un compromiso aplastado para un RP?

Fondo

Estoy usando Github, y aplastando mis commits en una única function de confirmación antes de empujar hacia el origen.

Si presiono solo el commit aplastado, Github (también conocido como el blob git en el control remoto) no parece saber acerca de las confirmaciones individuales antes de la squash (Github-markdown generalmente convertirá [<commitSHA>] a un enlace a la confirmación, pero esto no está sucediendo)

Supongo que podría empujar mi twig no aplastada, luego eliminarla del origen. Luego aplaste mis compromisos y vuelva a presionar. Pero eso parece un poco propenso a errores.

Idealmente, sería bueno tener un argumento de git push que examinaría el reflog para entender qué cometidos entraron en un commit aplastado e includelos.

Nota También abierto a comentarios sobre la sensatez de este flujo de trabajo

No tienes mucha experiencia con github, pero el siguiente flujo de trabajo parece relevante para tu pregunta.

  • crea una nueva sucursal para tu trabajo
  • empujar esta twig al control remoto sin aplastar
  • cuando la function esté list, realice la merge feature_branch --squash twig principal, realice la merge feature_branch --squash y empújela.

Como resultado, la sucursal principal tiene compromiso único con el trabajo general, pero uno de sus padres es una sucursal con todo el historial de desarrollo. Todos los commits se representan en remoto, por lo que la vinculación debería funcionar bien.

Un par de notas:

1) En flujos de trabajo normales, el acto de "aplastamiento" confirma que "estas confirmaciones individuales no son importantes; las creé como parte de mi flujo de trabajo de desarrollo, pero en el historial grabado quiero que se entiendan como una sola confirmación". Al hacer reference a los compromisos individuales, estás trabajando en contra de ti mismo.

2) A pesar de (1), puede conservar las confirmaciones originales. Sin embargo, no serán entendidos por git en relación con la confirmación aplastada, ni a su sucursal, ni a ningún trabajo posterior. Las características de host (como los enlaces de commit de Github) pueden funcionar, pero si un estado del código es lo suficientemente importante como para merecer tal enlace, entonces cuestiono la sabiduría de eliminarlo del historial de la sucursal.

3) Con (1) y (2) en mente, una alternativa es simplemente usar fusiones verdaderas en lugar de fusiones de squash. Esto permitirá que los comportamientos pnetworkingeterminados de las herramientas funcionen según lo previsto y no tendrá que tomar medidas especiales para que sus commits individuales sean reconocidos en origin . Por supuesto, cree que no quiere hacer eso, porque mantiene las confirmaciones individuales en la salida de log pnetworkingeterminada. Sin embargo, esa es la razón por la cual el command log tiene el argumento --first-parent .

4) Si a pesar de esto decides que solo tienes que usar fusiones de squash y presionar las confirmaciones originales bajo references separadas, funcionará. Pero, contrariamente a la especulación en su pregunta, no es seguro eliminar la reference que utilizó para presionarlos. Si lo hace, las confirmaciones individuales pueden eventualmente eliminarse mediante la recolección de elementos no utilizados.

5) Por otro lado, al contrario de lo que la nnovich-Ok parece implicar, no tienes que empujar antes de aplastar, porque aplastar no es una acción destructiva.

Entonces, si realmente lo deseas, puedes mantenerte al tanto de las twigs de características para confirmaciones individuales, mientras usas squashes para mantener un historial master simplificado, entendiendo que git no reconocerá la relación entre todas estas twigs; que no puede eliminar las twigs de características porque son lo único que mantiene vivo al individuo; y que está haciendo un esfuerzo para resolver un problema de la manera difícil, abarrotando su list de references con las twigs no utilizadas, todo para hacer algo que está integrado en el command git establecido de todos modos.