Git: Flujo de trabajo para mantener los cambios privados y solo enviar confirmaciones "consolidadas".

Estoy en un entorno en el que se supone que solo debo impulsar compromisos comprometidos y que resuelvan un problema. Por ejemplo: "Este compromiso corrige el error XY" , "Esta confirmación agrega la function YZ" . (para evitar saturar el historial de commit)

¿Qué flujo de trabajo debo adoptar si quiero mantener mis cambios locales (instrucciones de debugging, trabajo en progreso), pero a menudo (varias veces al día) me piden que me traduzca para aplicar cambios del equipo?

Supongo que la idea de git es que te comprometas a menudo, pero una situación ideal para mí sería si pudiera rastrear mi trabajo en progreso de forma privada y solo publicar confirmaciones "consolidadas" en el repository remoto. Y al mismo time, constantemente ser capaz de fusionar en lo que los miembros de mi equipo ya han hecho.

"Manera de Subversión"

Tengo una larga historia de subversión (por lo que el problema principal podría ser que estoy pensando en esto ), donde cualquier cambio remoto se fusionaría automáticamente con mis cambios locales no confirmados. Los conflictos se resolverían en el process de pago.

Hasta ahora, en git lo he estado haciendo:

git stash git pull git stash pop 

"El modo git" (Comprometerse a menudo, fusionar a menudo, supongo?)

¿Cómo se acerca la gente a esto en git en general?

Estaba pensando en mantener twigs privadas de "características" y luego realizar fusiones locales aplastadas de las twigs de características para dominarlas una vez que algo haya terminado y listo para publicarse, de modo que lo que se envía al repository remoto sea un compromiso único que dice "este problema soluciona" XY? "

No he intentado esto hasta ahora, pero parece que tendré que hacer muchas fusiones todo el time para que no se sienta bien.

He estado en una situación similar y he utilizado mucho git merge --squash .

Mantendría una sucursal con los commits que quisiera, ya que me di count del problema y luego lo aplastaré al final como uno lo confirma con reference al error / defecto o similar que resuelve.

Otra opción si termina resolviendo múltiples elementos en una sola twig, por lo tanto, desea tener más de una confirmación, pero solo las confirmaciones "al punto" es hacer una rebase interactiva dentro de la twig, git rebase -i .

Esto le permite agrupar selectivamente las confirmaciones en secuencia en posts de compromiso únicos, pero no es necesario networkingucirlo a solo 1 compromiso final.

Esto puede ser doloroso si estás haciendo muchas fusiones, pero si estás siguiendo algo como el popular model de flujo de git, probablemente estés haciendo una gran cantidad de twigs efímeras para cada elemento en el que trabajes.

La solución que necesita es (acostumbrarse a) contar con sucursales . También deberías usar una twig principal donde obtendrías los cambios de otros desarrolladores sin afectar tu trabajo en progreso (para que no tengas que hacer ese feo git stash / git stash pop ).

Luego, integraría la twig principal en sus twigs de características mediante fusión o rebase .

Un ejemplo. Tiene 2 twigs de características, una simple que está list y otra que necesita más testings y en la que está trabajando actualmente. Debes publicar tu característica simple. Para eso, primero tendrá que search a los demás cambios que se hayan publicado la última semana (la última vez que lo actualizó ).

Para eso, primero verifica la twig principal:

 (feature2) $ git add -A (feature2) $ git commit -m "preemtive commit" # you can also to a stash save (feature2) $ git checkout master (master) $ git fetch --all mirror # get changes from the 'mirror' remote # check the changes (master) $ git merge mirror/master # integrate other people changes into master branch (master) $ git checkout feat1 # the simple feature to be published (feat1) $ git merge master # merge the changes into the feat1 branch # do the necessary tests, check everything is OK (feat1) $ git push mirror feat1 (feat1) $ git update-ref refs/heads/master HEAD # this i will explain later 

Eso es. Ahora puede volver a su twig feature2. No necesita integrar su feat1 y master allí, pero puede hacerlo.

El último paso también podría hacerse así:

 (feat1) $ git checkout master (master) $ git merge --ff-only feat1 

Esto es para indicar que feat1 se ha integrado completamente en la twig principal, la twig pública.