Copiar origen / master a un nuevo trunk para usar git-flow

Me gustaría hacer una copy del origen / maestro de un repository de modo que haya dos troncos uno al lado del otro, y el segundo, origen / desarrollo. Quiero que ambos troncos tengan todos los mismos compromisos hasta cierto punto (que se crearía el origen / desarrollo del time) pero si mirasen el primer compromiso, cada troncal tendría una raíz diferente. es posible?

Básicamente, mi equipo ha tenido una twig de origen / principal para trabajar, pero nos gustaría pasar a algo más parecido a git-flow, por lo que hay múltiples troncos uno al lado del otro. Dado que hemos tenido toda esta historia que no queremos perder, ¿cómo te mueves al model de gitflow?

Aquí está el flujo de trabajo:

origin/master -> Initial Commit on origin/master -> SHA1 -> SHA2 -> SHA3 -> SHA4 ===> create a duplicate of origin/master as origin/develop origin/develop ->same initial commit that was on master ->SHA1 ->SHA2 ->SHA3 ->SHA4 ->SHA5: committed to origin/develop only ->SHA6: committed to origin/develop only <=== merge develop (SHA5 & SHA6) into master at this point 

Si entiendo tu pregunta correctamente, no, esto no es posible. Cada commit apunta a su compromiso principal. La modificación de un padre hará que todas las confirmaciones posteriores (aunque el parche sea el mismo) sean diferentes. git rebase maneja eso bastante bien, pero el siguiente esquema de bifurcaciones NO será posible sin fusionar el commit de desarrollo inicial con el maestro (que no es lo que creo que quieres):

 o---o--o--o--o (branch master) /|| || || ||\ o--o--o--o--oo--o--o (branch develop) 

Cuando cambias tu compromiso inicial, git volverá a comprometer todos los siguientes commits (crea un nuevo hash para cada commit), que se verá así:

 o--o--o--o--o (branch master) o--o--o--o--o--o--o (branch develop) 

No entiendo por qué lo necesitas, pero en realidad, git te ayuda a save tu historial mediante fusiones. Cuando se fusiona, el historial de la twig fusionada se fusiona con la twig de fusión, por lo que después de la fusión se puede ver claramente lo que está sucediendo con el git log --graph .

Por otro lado, si tienes diferentes historiales en 2 twigs pero los parches reales son los mismos (como en mi segunda ilustración), puedes usar git rebase para hacer que tu historial sea más limpio y lineal, para que se vea así:

 o--o--o--o--o (branch master) \ o--o--o (branch develop) 

No necesitas raíces diferentes? Solo la twig se desarrolla a partir del maestro actual y no se preocupe por ello. Si miras el historial (logging de git) desde el final de la nueva twig de desarrollo, lo verás por toda la twig de desarrollo hasta el punto de ramificación y luego dominarás el historial hasta el primer compromiso en el repository. No perderás ningún historial.