¿Cómo contribuir a un proyecto que ha bifurcado?

Digamos que he bifurcado https://github.com/user/proj.git y he hecho un desarrollo significativo en (la twig principal de) mi fork.

Quiero trabajar en un problema que está teniendo upstream (que no he reparado en mi fork). Si lo he entendido correctamente, debería crear una twig de características fuera de la última comprobación de upstream en su master:

git fetch upstream git checkout upstream/master git checkout -b my_new_feature 

el segundo de esos commands me permite saber que estoy en el estado 'HEAD separado' … ¿hay algo de lo que deba preocuparme (entender para hacer esta tarea)?

Ahora hago mis cambios, luego git add y git commit los files modificados, luego git push a github, pero cuando creo una request de extracción me dicen que mi request de extracción no se puede fusionar automáticamente porque hay un conflicto entre una cambio que he hecho y un cambio que fue verificado en upstream/master después de que hice mi git fetch .

Los cambios en conflicto son semánticamente equivalentes, por lo que quiero diferir a la versión de upstream/master . ¿Cómo rebase (eso es lo que quiero hacer, ¿no?) Mi request de extracción fuera de upstream/master mientras resolvía el conflicto? (Estoy bien versado en Subversion y un novato en git si eso ayuda a responder …)

esta request de extracción es problemática, ya que incluye un conflicto con los cambios realizados en el upstream / master después de que me bifurqué

los pasos necesarios para "proporcionarle una nueva twig adecuada"?

Una "twig reajustada propiamente dicha" significa una twig reestadificada en la parte superior del upstream/master (siendo el upstream el nombre del repository original que ha bifurcado)

 git fetch upstream git checkout myBranch git rebase upstream/master 

(También describo ese paso en " Extraiga nuevas actualizaciones del repository original de Github en el depósito de Github bifurcado ")

También puede hacer una rebase interactiva, si desea limpiar un poco el historial de su twig ( git rebase -i )

De esta manera, usted resuelve cualquier conflicto en su clon local, y git push --force su twig al tenedor.
Si ya tenía un PR (request de extracción) en progreso, se actualizará a sí mismo para tener en count el historial revisado de su twig networkingefinida.

El objective para el mantenedor del proyecto original es fusionar su sucursal en su sucursal principal, y hacerlo con una combinación trivial (0 conflicto).

Para completar la respuesta y el comentario de Thorbjørn Ravn Andersen:

Antes de todo, debe proporcionarle al responsable una fusión indolora, lo que significa estar al día con respecto a la twig principal.

Cuando un mantenedor combina una request de extracción, puede elegir la forma de hacerlo:

  • Aplástalo en un compromiso.
  • Combina el tree de request de extracción como un todo.

En la primera opción, el tamaño / comentarios / separación de las confirmaciones no es importante, ya que todo será una confirmación comentada por el responsable.

En la segunda opción, cada compromiso de su sucursal es importante. Por lo tanto, cada compromiso debe representar una unidad lógica de trabajo (por ejemplo, no debe haber confirmado la corrección de errores que introdujo con su sucursal, o si comete un resultado no funcional). Siempre puede presionar forzar su twig de request de extracción para que sea bonita.

En cuanto a estar actualizado en la twig principal, debe aplicar la misma lógica. Comprometerse: "Combinar maestro en Pipo" no es útil en absoluto, debe volver a establecer la base de su bifurcación para que la "fusión" sea invisible.

Y por último, pero no por ello less importante, cada mantenedor tiene sus propios hábitos, de modo que si el código, la testing y la documentation siempre se envían por separado o se agrupan, debería hacer lo mismo. De todos modos, cuando publique una request de extracción si el mantenedor encuentra algo que contar al respecto, puede discutirlo con él y cambiarlo de la manera que considere que se fusionará.

Cuando bifurca un proyecto en github, crea su propio repository paralelo.

Github utiliza "requestes de extracción" en el proyecto original para permitirle solicitar a aquellos con derechos de confirmación que retiren los cambios de su tenedor.