Acabo de volver a establecer una twig de características en otra twig de características (en preparación para volver a basar todo en la cabeza de mi maestro), e involucró bastantes resoluciones de fusión complicadas.
¿La rebase se guarda automáticamente como un commit en alguna parte?
¿Dónde viven esas modificaciones? No puedo ver nada en gitk o git log --oneline .
(La misma pregunta para cuando fusiono mi twig después de volver a basar).
Rebase está moviendo commits encima de otra twig. Si una confirmación que se mueve causa un conflicto de fusión, esta confirmación se modifica para reflejar la resolución de fusión.
El propósito de rebase es hacer que tus commits se vean como si fueran cambios en la twig a la que rebases. Entonces, la forma más lógica es incorporar conflictos de combinación en estos commits. No se requieren compromisos adicionales por lo tanto.
Merge es diferente, porque es una acción explícita de fusionar twigs divergentes. No se cambian las confirmaciones en cada una de las twigs. La resolución de conflictos se refleja en el compromiso de fusión.
Sí, las rebases y fusiones exitosas hacen commits. Solo no harán una confirmación de que hay conflictos que deben resolverse, pero luego el resultado de la rebase (o combinación) le dirá que esto sucedió y cómo resolverlo.
Para una rebase, solo necesita resolver los conflictos en el índice y luego git rebase --continue .
Para una fusión, necesita realizar la confirmación (commit de git commit ), pero se recordará el hecho de que se trata de una fusión y se le enviará un post de confirmación pnetworkingeterminado adecuado para que usted lo edite.
En los viejos times (2006, antes de 1.5.3 y su manual de usuario ), git rebase se presentaba así :
Un caso especial de recolección de cerezas es si desea mover una twig completa a una nueva confirmación de "base".
Esto es hecho porgit-rebase.
Usted especifica la twig para mover (HEADdefecto) y dónde moverlo (sin valor pnetworkingeterminado), y:
git cherry-pickscada parche de esa twig,- lo aplica sobre el objective,
- y mueve el puntero
refs/heads/<branch>a los commit recientemente creados.
Entonces, por definición, se realizarán confirmaciones (y no es necesario realizar ningún compromiso)
Un caso especial de rebase es cuando quieres dividir tu trabajo, mover (y recrear nuevos) commits.
Desde el mismo tutorial (como una ilustración de no necesitar ningún compromiso adicional después de una rebase):
Supongamos que ha mezclado el desarrollo de dos características en el HEAD actual, una twig llamada "dev".
xxxx (master) \ -f1a-f1b-f1c-f2a-f2b-f2c (dev, HEAD)
Desea dividirlos en "dev1" y "dev2". Suponiendo que
HEADes una twig de master, entonces puede mirar a través de
git log master..HEAD
o simplemente get una list cruda de las confirmaciones con
git rev-list master..HEAD
De cualquier manera, supongamos que calcula una list de confirmaciones que desea en
dev1y crea esa twig:
git checkout -b dev1 master for i in `cat commit_list`; do git-cherry-pick $i done -f1a'-f1b'-f1c' (dev1, HEAD) / xxxx (master) \ -f1a-f1b-f1c-f2a-f2b-f2c (dev)
Puede usar la otra mitad de la list que editó para generar la twig
dev2, pero si no está seguro de haber olvidado algo, o simplemente no tiene ganas de hacer ese trabajo manual, puede usar git-rebase para hacer para ti.
git checkout -b dev2 dev # Create dev2 branch git-rebase --onto master dev1 # Subreact dev1 and rebase
Esto encontrará todos los parches que están en
devy no endev1, los aplica sobre el maestro y llama al resultadodev2.
-f1a'-f1b'-f1c' (dev1, HEAD) / xxxx (master) \ -f2a-f2b-f2c (dev2, HEAD)