Tecnología · GUÍA PRÁCTICA
¿Git rebase omitió un commit? Audite el parche antes de reaplicarlo
Omitir un hash no demuestra pérdida de código. Distinga equivalencia en upstream, un commit vacío, skip manual y restricciones de GitHub antes de reescribir el historial.
Si Git informa de que omitió un commit previamente aplicado, compare su cambio con el upstream usado realmente. El rebase predeterminado puede omitir un cherry-pick limpio ya representado allí aunque los IDs difieran. No lo repita con opciones adicionales solo para recuperar el número anterior de commits.
Esta guía organiza evidencia sobre la punta original, la de destino y el parche omitido. También distingue Git local del botón de una solicitud de incorporación en GitHub: son comprobaciones distintas y un aviso no diagnostica una restricción alojada.
Registre la operación y encuentre la punta original
Conserve aviso completo, IDs omitidos, comando original, versión de Git y rama de destino. Ejecute `git status` para saber si el rebase sigue activo. Una omisión automática, un mensaje de commit vacío al reproducirlo y un conflicto omitido manualmente son hechos distintos. Identifique cuál ocurrió, sin llamarlos todos pérdida de commits.
Después de terminar, consulte `git reflog show --date=iso YOUR_BRANCH`, sustituyendo YOUR_BRANCH por la rama real, e identifique la punta previa por la secuencia. Anote hashes exactos antiguos y de destino; no suponga que un índice fijo de reflog siempre señala lo deseado. Los reflogs son locales y caducan. Si faltan objetos originales, deténgase y busque otra copia conservada.
Compare contra el upstream correcto
Con hashes verificados, ejecute `git cherry -v UPSTREAM_HASH OLD_TIP_HASH`. Menos significa que hay un parche equivalente en upstream; más, que no se encontró. La comparación documentada elimina espacios y números de línea, no coteja mensajes ni IDs antiguos. Lea también el parche exacto: el marcador evidencia equivalencia, no todos los resultados deseados.
El comando examina parches confirmados, no ediciones sin commit, y no prueba que un cambio siga presente tras una reversión posterior. Examine archivos y comportamiento esperado. En un repositorio sintético aislado con Git 2.51.1 comprobamos que una función cherry-picked marcada menos se omitía pero permanecía en el archivo final, y otro commit no equivalente se conservaba. No es una prueba de su repositorio.
Compare las series antes de decidir la reaplicación
Con bases y puntas conocidas, examine `git range-diff OLD_BASE_HASH..OLD_TIP_HASH NEW_BASE_HASH..NEW_TIP_HASH`, reemplazando los cuatro marcadores por rangos reales. Revise entradas sin correspondencia o modificadas junto a la comparación de upstream. Un parche ausente de la nueva serie puede estar en su nueva base: su ausencia no demuestra pérdida. range-diff es una comparación para personas, no un comando de recuperación ni un formato estable de aceptación automática.
Git documenta `--reapply-cherry-picks` como un cambio a la omisión preliminar de equivalentes limpios. El commit reaplicado aún puede quedar vacío, etapa controlada por `--empty`. Ninguna opción garantiza recuperar comportamiento. Si hay una pérdida real, preserve el trabajo y acuerde el historial deseado antes de recuperar. No use otro rebase, hard reset ni force push como diagnóstico.
Separe el botón de GitHub
Si el rebase local termina pero GitHub rechaza Rebase and merge, registre hashes base/head, número de commits y mensaje exacto. La documentación actual limita ese método a 100 commits. Superarlo es una condición concreta aparte; estar por debajo no acredita el resto de requisitos. No atribuya un rechazo alojado al aviso de omisión sin pruebas.
Cada cambio deseado debe quedar explicado: representado upstream, retirado intencionalmente o pendiente de recuperación revisada. Verifique archivos finales y comprobaciones del proyecto, y gestione restricciones con la política de merge permitida. Conserve puntas, comando, IDs omitidos, comparación y cambios inexplicados para el mantenedor. Ocultar el consejo o recuperar el número de commits no es aceptación.
