¿Puedo trabajar en una sucursal con parches fusionados de otras sucursales?

No estoy exactamente seguro de cómo se llama o si es una mala idea, así que por favor, infórmenme si voy a hacer la pregunta incorrecta.

Tengo una base de código que estoy ayudando a mejorar, que he clonado de github. Quería comenzar por limpiar algunas de las advertencias obvias que Eclipse informa y luego revisar y eliminar todas las llamadas de miembros obsoletas.

Para ayudar a simplificar las cosas para el autor, quiero enviar varias requestes de extracción para modificaciones similares en el código en lugar de una "cantidad de cosas limpiadas" para que sea más fácil para ellas inspeccionar y aprobar.

Lo que he estado haciendo es mantener su código original como maestro y crear nuevas twigs para cada grupo de cambios similares. El problema que estoy teniendo es que es muy confuso trabajar en la list de advertencias / errores que informa el IDE, ya que cada vez que me muevo a un grupo diferente, cambio a una twig fuera del maestro y los problemas que yo ' he reparado en otra twig son nuevamente visibles.

¿Es posible trabajar en una gran twig de "todo" para que sea más fácil ignorar las cosas que ya he solucionado? Por ejemplo, cada "commit" se convertiría en una twig separada del master.

O … trabajar en una twig con todas mis otras correcciones de sucursales fusionadas y luego separarlas cuando haya terminado con los cambios que hice en otro lugar.

¿Tiene sentido lo que estoy preguntando? ¿Hay un flujo de trabajo para esto?

Una forma simple de hacerlo (pero con una captura) es crear nuevas twigs basadas en sus propias twigs en lugar de /master . Por ejemplo:

 git checkout -b obvious-warnings origin/master # work work work, create PR git checkout -b deprecated-calls # work work work git checkout -b fix-findbugs # work work work 

Solo hay una captura. Tenga en count que solo pongo "crear PR" después de la primera twig, no los demás. Solo debe crear el siguiente RR después de que el anterior ya sea aceptado. De esta forma, solo los nuevos commits se mostrarán en el diff para el revisor.

Esto es simple, y lo uso en la práctica todos los días en mis proyectos.

No me malinterpreten, normalmente creo nuevas sucursales basadas en el origin/master , pero solo en el caso especial cuando una nueva twig depende de un PR pendiente, creo la nueva twig basada en esa twig de RP.

Simplemente puede crear una twig fuera de la twig principal.

Luego, para cada set de cambios, solo agrega un nuevo compromiso en tu sucursal. Esto facilita la eliminación de confirmaciones o ver los cambios para confirmaciones únicas si es necesario.

Si el maestro se actualiza, puede volver a establecer la base de una de sus twigs en la parte superior del maestro.

Este es un trabajo para rebase interactivo . Realice los cambios en su propia sucursal, sin embargo, tiene sentido para usted en ese momento . Luego, cuando esté listo para sacar algo de su trabajo, haga una rebase interactiva moviendo los cambios listos a una serie de compromisos al frente de su sucursal, etiquete a los últimos con un nombre de sugerencia de twig para que puedan extraer solo aquellos y continuar:

 git checkout -b cleanup # work work commit commit lalala # others do the same on master ...o... .... X---Y master # \ Mon-Tue-Wed-Thu cleanup # this branch not for publication 
 git rebase -i master # (move commits and hunks as you like here, the whole point is you can # work on an overview of a complete set of work and make it ready for # presentation/publishing) 
 ...o... .... X---Y master \ A---B for-upstream # branch made during a rebase -i `edit` or `exec` stage \ j---k---l cleanup