En lugar de un largo historial de confirmaciones planas, ¿por qué no hay una jerarquía? Por lo tanto, en el nivel superior puede tener solicitudes de extracción, entonces puede bajar un nivel y ver las confirmaciones en ese RP. Me doy cuenta de que las relaciones públicas son específicas de Github, pero entiendes la idea. Solo me refiero a agrupar una serie de confirmaciones como una característica o corrección de errores, por ejemplo.
Seguramente haría que el historial de confirmación sea mucho más fácil de navegar.
Estoy seguro de que hay una respuesta obvia a esta pregunta, pero parece que no puedo encontrarla.
version-control
git
Eggbert
fuente
fuente
Respuestas:
Hay un largo historial de confirmación plana porque los cambios son secuenciales. Cada uno se basa en el estado 'antes' y deja un estado 'después'. Sería difícil que los cambios no reflejen esto.
Una opción para agrupar cambios relacionados es usar etiquetas: http://git-scm.com/book/en/Git-Basics-Tagging, aunque se usan más para etiquetar un punto en el historial en lugar de agrupar confirmaciones dispares.
Para agrupar las confirmaciones en otras más grandes, también puede hacer rebases interactivos.
Las ramas son una opción, puede crear una rama y hacer un montón de confirmaciones que están relacionadas lógicamente. Puede fusionar esos commits nuevamente en master como lo desee, probablemente utilizando la
--no-ffopción.La relación entre ramas también se puede ver en herramientas visuales como gitg / gitx
fuente
Tuve el mismo problema al pensar en esto hasta que descubrí que Git numera sus ramas principales. Dado esto, las confirmaciones de fusión generalmente molestas que se generan pueden considerarse nodos de resumen. Y todos los detalles adicionales se pueden eliminar de la vista, dejando un solo historial lineal resumido.
Consulte esta publicación de blog para obtener detalles y ejemplos.
fuente
Agrupa las confirmaciones en ramas: cada rama es un conjunto de confirmaciones. Cuando fusiona commits, está poniendo un conjunto de commits dentro de otra rama, construyendo efectivamente una jerarquía de commits: rama principal, características, errores, experimentos, lo que sea.
Idealmente, su rama principal es una sucesión de commits de fusión. Si solo mira a los primeros padres (los comandos de git aceptan tal opción), tendrá una vista de alto nivel de su historial (con suerte, escribirá una confirmación de fusión significativa, no la generada automáticamente). Pero cuando observa a los padres 2º, 3º, etc. de una fusión en su historial, está abriendo la caja para ver qué hay dentro de una fusión. Aquí tienes detalles de lo que pasó.
fuente