Cómo push/pull git rebase

Question

Me gustaría utilizar git rebase con el fin de fusionar limpiamente una característica de la rama principal (en menos cometa o al menos en la parte superior del registro de cambios). Tenga en cuenta que soy el único que trabaja en el repositorio.

Después de leer Git workflow and rebase vs merge questions, encontré git rebase sería bastante agradable y al igual que Miqueas me gustaría git push cambios porcentualizada simplemente porque que estoy trabajando desde diferentes lugares (por ejemplo: mi portátil, mi casa, otro PC en alguna parte ...)

Así que aquí son dos soluciones (a la fusión fea bidireccional):

1. Uso git push -f para empujar, y luego tirando de otra máquina, pero cómo conseguir limpiamente la versión más reciente en otras máquinas?
2. Uso de combinación para combinar los cambios principal a la rama de la característica, git push/pull, y una vez maduro, hacer un solo rebase (en una o más comete limpiamente)

(2) sería como a continuación:

git co -b feature-a 
... change files 
git push origin feature-a 
... moving to another PC 
git pull origin feature-a 
... change files 
git merge master 
... change files (not the "special rebase") 
git rebase master 
git co master 
git merge feature-a 
git branch -d feature-a 
git push origin :feature-a 

¿Qué solución crees que funcionaría? No he probado ninguno de ellos hasta ahora (principalmente por temor a que mi registro sea más complicado).

Answer 1

recordar que git rebase repeticiones cambios y crea nuevas confirmaciones. Al reajustar y forzar los empujes por todos lados, vas contra el grano de la herramienta. Note cómo empieza la sección "Recovering from an upstream rebase" de la documentación git rebase (con énfasis añadido):

Rebase (o cualquier otra forma de volver a escribir) una rama que otros han basado en el trabajo en una mala idea: nadie aguas abajo de ella se ve obligada para arreglar manualmente su historial Esta sección explica cómo hacer la solución desde el punto de vista de la corriente descendente. La solución real, sin embargo, sería evitar volver a basar el flujo ascendente en primer lugar.

Aunque usted es el único desarrollador, seguirá siendo otros (desde la perspectiva de un repositorio) cuando trabaje en otros clones. Como has visto, este flujo de trabajo es una molestia.

Deje que sus cambios se cocinen en las ramas. Cuando una rama está lista para el horario estelar, luego rebase, fusiónela en maestra y elimine su rama de tema. Su vida será más fácil si mantiene cortas las vidas de las sucursales y sus alcances estrechos.

Answer 2

que siempre asegurarse de que cometió y empuje (f) todo, desde cualquier máquina dejo.

Cuando llego a alguna otra máquina:

git fetch -v 
git checkout mybranch # Already checked out with old HEAD 
git reset --hard origin/mybranch 

Esto funciona bien porque sé que el otro "yo" en diferentes ordenadores constantemente compromete y empuja antes de salir (y por tanto no hay cambios unpushed en el máquina a la que llego)