Contribuyendo a proyectar en github, cómo "volver a basar mi request de extracción sobre el maestro"

Ok, así que contribuyo a un proyecto en github. El proyecto en github está upstream , mi repository bifurcado en github es de origin y mi repository local en mi computadora.

 git checkout -b feature # Working on feature git commit -a -m 'only commit on feature' 

luego presento una request de extracción

 git push origin master 

La request de extracción se revisa y es necesario realizar un cambio no relacionado. Alguien más hace un commit y se fusiona en upstream/master

Ahora el encargado de mantenimiento me pide que "vuelva a basar mi request de extracción en la parte superior del maestro"

Esta es mi historia (inserte el efecto de sonido de Ley y Orden) …..

No realicé ningún cambio en la request de extracción y sigue siendo la misma confirmación de la function de sucursal.

 git checkout master git fetch upstream git checkout feature git rebase master => "Current branch feature is up to date." git push origin feature => "Everything up-to-date" 

No entiendo. ¿Cómo es esto posible cuando sé que alguien se comprometió y se fusionó con el upstream/master después de que presioné mi request de extracción al origin/feature ?

¿Alguien puede decirme cuál debería ser el procedimiento correcto en esta situación?

Solo muestra una búsqueda en el repository de subida. Eso en realidad no actualiza ninguna de sus sucursales locales. Solo actualiza tus conocimientos de upstream . Tendrás que asegurarte de que el upstream/master esté completamente fusionado con tu master , como con un git pull , antes de volver a basarlo en master , o simplemente simplemente rebase en upstream/master .

Es decir:

 git checkout master git pull upstream master git checkout feature git rebase master 

o

 git checkout feature git rebase upstream/master 

Actualizar:

Luego de corregir su twig de feature local, deberá volver a origin al origin para finalizar la actualización de la request de extracción. Como ya ha presionado la feature una vez, no puede simplemente push nuevamente porque una rebase cambia el historial y no es un avance rápido. Normalmente, cuando un push falla con un "avance no rápido", lo resuelves haciendo un pull, pero un pull simplemente combinará las dos historias divergentes, que definitivamente no es lo que quieres. Eso significaría que su antigua twig de feature (previa a la rebase) se combinaría con la nueva (post rebase). Desea sobrescribir el origin/feature con el estado de la nueva twig de feature , volcando cualquier logging del anterior. Eso significa que querrá forzar el empuje para que suceda, incluso si no es un avance rápido, usando la git push -f origin feature . Nota: el empuje forzado es peligroso y puede perder compromisos con él. Solo úsela si está absolutamente seguro de que sabe lo que está haciendo, como aquí, donde intencionalmente desea descartar las confirmaciones antiguas e inútiles en la twig de feature previa a la rebase.

Ahora el encargado de mantenimiento me pide que "vuelva a basar mi request de extracción en la parte superior del maestro"

Tenga en count que desde septiembre de 2016, el mantenedor puede activar el rebase mismo.

Consulte " Rebase y fusionar requestes de extracción "

Cuando selecciona la nueva opción "Rebase y fusión", las confirmaciones de la twig de la request de extracción se vuelven a establecer en la punta de la twig base, y luego la twig base se reenvía rápidamente a esta cabeza recién reestablecida. Rebases establece automáticamente el committer de las confirmaciones rebasadas para el usuario actual, manteniendo intacta la información de autoría. La ramificación de la request de extracción no será modificada por esta operación.

Si no se puede realizar una rebase debido a conflictos, se lo haremos saber para que pueda resolverlos manualmente según sea necesario.

https://cloud.githubusercontent.com/assets/2195/18671961/a03fa9b6-7f35-11e6-8fa0-e16b2fede8ca.gif