Git rebase/merge para publicaciones públicas

Question

He estado investigando a través de git merge y rebase docs, y algo no se está hundiendo. Estoy trabajando activamente en un proyecto en Git, y necesito compartir hitos específicos con otros desarrolladores. Quiero compartir el código exactamente como está en cada hito/lanzamiento, pero no todos mis compromisos pequeños previos a cada lanzamiento.

¿Cómo creo una rama de versión que refleje una rama de desarrollo, donde cada una de las confirmaciones en la rama de versión contiene varias confirmaciones de la rama de desarrollo? En otras palabras, la rama de publicación debe tener un historial comprimido, pero debe coincidir con la rama de desarrollo.

Originalmente, había pensado que usar una rama separada y usar git merge --squash sería efectivo, creando una nueva rama con una serie de confirmaciones que reflejaran el conjunto completo de cambios entre cada versión. Ahora entiendo que git merge --squash no funciona para usos repetidos.

Git rebase funciona para colapsar varias confirmaciones en una confirmación grande, pero como cambia el historial de confirmaciones, ¿no cambiaría mi historial privado así como las publicaciones públicas?

No quiero perder mi historial de pequeños cambios, pero quiero enviar confirmaciones combinadas a un servidor compartido.

Answer 1

Seguramente, si sus compromisos son dignos de mantener y constituyen su trabajo para un lanzamiento al público, entonces ¿deberían formar parte de su historial publicado? Si no desea publicar su historial completo de repositorios, es mejor que use git archive para crear archivos de lanzamiento.

Dicho esto, si realmente desea crear una rama de publicación con un historial separado, entonces es posible. Sin embargo, se está preparando para una mayor sobrecarga de mantenimiento, ya que nunca podrá fusionar su historial privado con su sucursal de publicación pública, ya que eso traería todo el historial privado a su sucursal de publicación. Esto es lo que hace Git; rastrea de dónde vienen los cambios.

Puede fusionarse desde la rama de publicación a la rama privada, pero como su trabajo (presumiblemente) proviene de la rama privada, esto no le hará ganar mucho. La opción más fácil es tener una rama de publicación separada que contenga solo las confirmaciones de instantáneas del estado de la sucursal privada en los puntos de publicación.

Suponiendo que ha llegado al punto en el que desea crear una confirmación en la rama de publicación (release) basado en la confirmación actual en la rama privada (private) y suponiendo que tiene el árbol liberado no hay cambios en el índice, esto es lo que puede hacer.

# Low-level plumbing command to switch branches without checking anything out 
# (Note: it doesn't matter if this branch hasn't yet been created.) 
git symbolic-ref HEAD refs/heads/release 

# Create a new commit based on the current index in the release branch 
git commit -m "Public release commit" 

# Switch back to the private branch 
git checkout private 

Usted puede hacer esto para cada versión (o sub-release) y el nuevo compromiso será construido directamente sobre la parte superior de la versión anterior sin incorporar ninguna de su historia privada.

Answer 2

Solo crea una nueva rama y haz todo el aplastamiento allí. Luego publica eso. Tus commits más pequeños seguirán allí en las otras ramas.

Mi flujo de trabajo para esto sería algo como esto:

git co -b release_branch_squash release_branch_with_all_commits 

git rebase last_release_tag 

Ahora es el momento para hacer frente a todos los conflictos que puedan surgir. Realmente no sé cómo evitar esto. Por lo general, no es un gran problema. Mi repositorio git ya ha registrado la mayoría de las resoluciones de conflictos de todos modos.

git rebase --interactive last_release_tag 

Esto abrirá vim. Para todo el lanzamiento que deseo aplastar, reemplace pick con squash. Entonces solo guarde y salga. Hecho.