Cambiar de qué twig es una twig de una twig de git

Estoy trabajando en un entorno de múltiples desarrolladores en un repository que tiene una twig llamada "desarrollo", que se actualiza con frecuencia. Sin embargo, hay algunos problemas con el desarrollo, y me gustaría crear una twig en mi máquina local, digamos "custom_develop", donde puedo hacer un par de commits que no tengo la intención de volver al repository principal.

Cuando trabajo en una twig de características, me gustaría comenzar creando una twig de custom_develop llamada "feature / ticket-123" y crear un par de commits. Luego, cuando creo que he terminado mi trabajo en el ticket 123, quiero hacer que "feature / ticket-123" se convierta en una twig de "desarrollo" en lugar de una twig de "custom_develop", para que pueda crear una request de extracción que se combinará para desarrollar en el server remoto.

¿Cómo puedo hacer esto en git?

Si trato de hacer

git checkout develop git checkout -b custom_develop git commit -m "Commit I don't want to share" git checkout -b feature/ticket-123 git commit -m "Ticket-123: Refactor" git rebase develop 

yo obtengo

 Current branch feature/ticket-123 is up to date. 

y el logging de git aún incluye el compromiso "Confirmar que no quiero compartir".

Usaré un diagtwig para describir su pregunta visualmente.

Esto es lo que tienes actualmente:

 A <- develop \-- B (don't share) <- custom_develop \--C <- feature/ticket-123 

Esto es lo que quieres:

 A <- develop \-- C' <- feature/ticket-123 \-- B (don't share) <- custom_develop \--C <- no branch 

El problema es que, de forma pnetworkingeterminada, rebase intentará reproducir todas las confirmaciones que se hayan producido desde la base de combinación de su confirmación actual y la confirmación a la que está volviendo a basar. En su caso, la base de fusión (último padre común) es A. Por lo tanto, no hay nada que reproducir, no hay compromisos que hayan divergido de A en la twig de desarrollo. Es por eso que recibe el post "actualizado". Sin embargo, incluso si el desarrollo hubiera progresado, todavía tendrías un problema porque Git volvería a reproducir todas tus confirmaciones en donde se desarrolle actualmente, incluida la confirmación B, que deseas ignorar.

Por lo tanto, deberá usar la opción –onto de rebase:

 git rebase --onto develop B 

Esto reproducirá todos los commits en la twig actual que NO son padres de B (o B sí mismo) "on" develop.

La syntax puede ser confusa. En el caso pnetworkingeterminado, solo especifica la confirmación "en", pero sin la palabra key --onto . En el caso no pnetworkingeterminado en el que se especifica una confirmación de "ignorar", debe especificar la palabra key --onto aunque realmente esté agregando una confirmación "ignorada". Sería mejor si Git te permitiera especificar esto con git rebase develop --ignore B

Otra opción, que se requiere si los commits que desea ignorar no están todos en la parte inferior de su twig, es decir, los commits que siguen a merge-base, es usar una rebase interactiva.

 git rebase -i develop. 

Luego, cuando la window interactiva aparezca, comente los commits que desea ignorar.

Por último, probablemente no sea una buena idea tener una sucursal personalizada permanente. Sería mejor poner properties específicas del entorno en un file que se ignora utilizando .gitignore .