Estoy tratando de descubrir el mejor flujo de trabajo para trabajar con un fork de un proyecto de código abierto existente en Github. Quiero tomar un proyecto existente y realizar cambios significativos en él, en este caso para transferirlo a Android y agregar funcionalidad específica de Android únicamente. Me gustaría satisfacer lo siguiente:
Mi idea inicial es que doblaría el proyecto original, luego bifurcaría y cambiaría el nombre de mi tenedor para darme los siguientes resúmenes:
original-author/projectA nicstrong/projectA nicstrong/projectA-android Esto me permitiría trabajar en mis cambios locales de repo local / projectA-android push a nicstrong / projectA-android. Luego, para actualizar desde el proyecto original, pude rebase nicstrong / projectA a la más reciente desde original-author / projectA luego get / fusionar de nicstrong / projectA a local / projectA-android.
Mis preguntas son:
1 / Sí, parece ser el enfoque más seguro, ya que cualquier modificación que finalice en back-porting en nicstrong/projectA estará en un proyecto con la misma estructura que original-author/projectA .
Eso significa que las requestes de extracción serán más fáciles de organizar, ya que estará en un proyecto que refleja el proyecto original del autor.
2 / Si tiene una refactorización masiva en nicstrong/projectA-android , crearía una twig backport , fusionar cuidadosamente o seleccionar cuidadosamente lo que necesita de los numerosos cambios en la twig backport , y luego nicstrong/projectA esa twig a nicstrong/projectA .
(lo que significa que ha agregado nicstrong/projectA como un control remoto de nicstrong/projectA-android )
El nombre de un repository git depende en gran medida del nombre del control remoto. Continúa y clona, luego simplemente agrega un nuevo control remoto (con un nombre diferente) y comienza a presionar allí. En ese punto, por supuesto, puede continuar y cambiar el nombre del directory del proyecto sin problema.