Reasignación a nuevas versiones en git upstream (GitHub) con la pérdida de todos los cambios locales

Quiero tener la siguiente estructura de versión:

(my private changes to 0.1.0) - A - B - C - ... / (upstream repo) - 0.1.0 - 0.2.0 - ... \ (my private changes to 0.2.0) - D - E - F - ... 

No quiero fusionar mis cambios con los cambios en el flujo ascendente, porque el upstream se desarrolla rápidamente y, por lo general, hay millones de conflictos difíciles de resolver, porque el código upstream fue networkingiseñado significativamente. Cuando sale 0.3.0, solo voy a crear una copy exacta de la misma olvidando mis cambios privados y luego volver a aplicar mis correcciones privadas una a una. Pero no quiero que mis antiguos cambios desaparezcan por completo. Quiero que sigan sentados en algún lugar (¿en una sucursal separada?).

git rebase no es lo que quiero. De acuerdo con el libro de Pro Git , rebasing intentará volver a aplicar parches de ABC a 0.2.0. Aquí hay una situación de ejemplo entre las dates de lanzamiento de las versiones 0.1.0 y 0.2.0:

 (upstream) - 0.1.0 - (my master) - A - B - C 

Ahora 0.2.0 está fuera:

  (my master) - A - B - C / (upstream) - 0.1.0 - 0.2.0 

No quiero volver a ajustar mis cambios A – B – C debido a demasiados conflictos. Quiero labelr mi twig A – B – C como 'my-0.1.0' y comenzar una 'nueva' twig maestra desde 0.2.0:

  (my-0.1.0) - A - B - C / (upstream) - 0.1.0 - 0.2.0 - (my new master) 

Quiero que mi nueva twig maestra sea una copy limpia de la cadena ascendente 0.2.0, sin ningún bash de volver a aplicar mis viejos sets de cambios ABC. Así que más tarde puedo seleccionar cuidadosamente los cambios de ABC uno por uno si los necesito en el mundo posterior a 0.2.0.

¿Cómo pongo la label my-0.1.0? ¿Es una label, una label, una twig? ¿Cómo comienzo una twig maestra vacía fuera de 0.2.0? Tenga en count que hay dos repositorys diferentes: mi repository repo y upstream. ¿Debo copyr la twig ascendente del repository ascendente a mi repository? ¿Cómo me aseguro de que 0.2.0 se tira después de 0.1.0, y no después de C? Si acabo de hacer una request de extracción después

(stream arriba) – 0.1.0 – (mi maestro) – A – B – C

yo obtengo

(en sentido ascendente) – 0.1.0 – (mi maestro) – A – B – C – "0.2.0 combinado con ABC"

que no es lo que quiero

También a veces quiero impulsar ciertos cambios (por ejemplo, E) de nuevo a la stream ascendente. ¿Es posible crear una request de extracción solo para cambio E? En darcs esto es posible. Si no es posible con Git / GitHub, entonces necesitaré crear una twig separada, volver a aplicar los cambios en E manualmente. ¿Cómo debo proceder?

git rebase es tu amigo.

Etiquete la versión anterior si lo desea y vuelva a establecer la base de sus twigs privadas en la última versión original.

Para crear una request de extracción solo para E, puede:

  1. Cree una nueva bifurcación y git cherry-pick E (la vieja bifurcación tendrá la versión anterior de E).
  2. git rebase -i la twig y reorderar los commits para poner E primero. Entonces puedes labelr E y crear una request de extracción desde esa label. Cuando el upstream lo aplica, el rebasing debe aplicar correctamente los commit restantes

En cualquier caso, si la rebase no se da count de que E se ha fusionado cuando upstream finalmente lo hace (lo que sucede si lo modificaron), simplemente use el rebase interactivo para descartar su versión obsoleta.

Darcs realmente hace lo mismo, pero Darcs se rebases automáticamente si puede hacerlo sin conflictos (y se rehúsa a hacerlo por completo si no puede), mientras que en git rebasas explícitamente y si hay conflictos (E resulta depender de D), escupe el conflicto y te permite lidiar con él de la forma que quieras.

Editar : Ah, solo quieres poner A, B y C a un lado y comenzar con limpieza 0.2.0. Puedes usar cualquiera de las twigs (en master, do):

 git branch -m my-0.1 git checkout -b master 0.2.0 

o label (en master, do):

 git tag my-0.1 git reset --keep 0.2.0 

La sucursal mantendrá su reflog, podrá verificarlo y modificarlo. La label no tendrá un reflog y no podrás verificarla (el pago te colocará en el estado "HEAD separado" a less que le des una twig para crear).

Es posible que desee ver git rebase --onto que le permitirá aplicar un set de cambios en una base diferente a la que están actualmente en

Tenga en count que desde git1.7.2rc2 , el git reset --keep 0.2.0 opción mencionada por Jan Hudec en su respuesta también se puede escribir:

 git checkout -B master 0.2.0 

El anuncio menciona:

 git checkout -B <current branch> <elsewhere>" 

es una forma más intuitiva de deletrear " git reset --keep <elsewhere> ".