Introducción a Git, GitHub/BitBucket...

themaz

#120 Vale eso es lo que esperaba, que al hacer el checkout los archivos pasen a ser los de la revisión pero esto no aparece. En la consola aparece, pero en la carpeta local donde tengo los archivos, no se actualiza :S

28 días después
Amazon

Alguno sabe si se puede "cancelar" un cambio de una línea en un commit pasado? Desde command line o desde gitlab (que es lo que usamos en el curro).

La cosa es que un compañero editó un mensaje para poner una chorrada hace un par de semanas y lo vi ahora en el merge request...

1 respuesta
3 meses después
soek

#122 si haces checkout de ese commit y haces un force push podrás cambiar el historico.

1 respuesta
Amazon

#123 sí, pero si me pongo en ese commit, ya tiene esos cambios hechos, cómo desharía los cambios de ese comit en concreto, una línea sólo?

1 respuesta
soek

git commit --amend #124

1 respuesta
Amazon

#125 eso no es sólo para editar el mensaje? xD

soek

Es para añadir los cambios actuales añadidos al commit anterior

HiGher

Cambiar el histórico del remoto en el que sincronizan todos, es una buena forma de tocarle los cojones a los compañeros. En vuestro repo, todo lo que queráis, pero una vez están sincronizados los commits con un origen, no se tocan.
Para cambiar lo que sea se hace otro commit NUEVO y punto.

1 respuesta
Merkury

Venia a decir lo de #128 que --amend es para usarlo antes de haber hecho push.

Y cambiar un commit una vez pusheado, no es una buena idea.

1 1 respuesta
soek

#129 o haciendo un rebase.

Yo no me he puesto a criticar lo que es buena o mala idea, simplemente he ido a solucionar ese problema.

Obviamente que la forma sencilla y correcta es haciendo un commit nuevo, para eso el control de versiones.

2 respuestas
Merkury

#130 Rebase tampoco es que sea la panacea... aunque esto es opinion personal mia eh!

1 1 respuesta
soek

#131 Personalmente soy bastante fan del rebase

1 respuesta
Amazon
#130soek:

para eso el control de versiones.

Precisamente quiero aprovechar el control de versiones para no tener que reescribir el código que se borró, o borrar el código que se añadió xd

Y por lo del pusheo, ahora mismo sólo somos 2 tocando el código, así que en principio cuando haga falta hacer esto que comento no habrá problema, porque encima soy yo el que controla de git (mi compañero sabe hacer commit, push, pull y poco más.

1 respuesta
soek

#133 Hay algo que no acabo de entender.

Si quieres modificar algo que tu compañero cambió, haz otro commit re-haciendolo.
Cual es el problema?

Idealmente, aunque seais 2 tocando código en un solo repo, cuando se habla de hacer commit yo me refiero a hacer una PR y mergear.

Merkury

#132 Pero trabajando tu solo o con mas gente, porque rebase te la puede liar muy gorda...

Yo he visto logs, que ni regreso al futuro xD

1
21 días después
Amazon

¿Qué significa este [1]?

1 respuesta
Merkury

#136 Comentario?

1 respuesta
Amazon

#137 sep, tiene sentido, gracias xD (comprobando puntos anteriores con bastantes comentarios)