"Learn Git Branching" es la forma más visual e interactiva de aprender Git en la web; te desafiará con emocionantes niveles, te dará demostraciones paso a paso de potentes funciones, e incluso puede que te diviertas un poco por el camino. Después de este diálogo verás la variedad de niveles que tenemos para ofrecerte. Si eres un principiante, comienza con el primero. Si ya conoces algunos de los conceptos básicos de Git, prueba algunos de nuestros niveles posteriores más desafiantes.
|
etiquetas: git , ramas , branches , juego
Borrar repo
Clonar repo
Y en plan espeso: es maś fácil entender git y los remotos si nos damos cuenta de que cada repositorio es un grafo dirigido acíclico y que hacer un fetch no es más que traernos la parte del grafo que no tenemos del repositorio remoto. La rama local y la rama remota (mi-rama y origin/mi-rama, por ejemplo) no son más que apuntadores a un nodo del grafo (igual que las etiquetas, solo que los apuntadores que son las ramas son modificados por ciertas operaciones como commit, merge, etc). Hacer merges y rebases es jugar con el grafo (crear nuevos nodos y enlaces, mover una secuencia de nodos de un sitio a otro, etc). Pushear es enviar parte de nuestro grafo al remoto y actualizar los apuntadores de las ramas que pusheamos (si es posible sin romper el grafo remoto, por eso a veces rechazan nuestro push).
Ah, y no olvidéis el comando reflog: si habéis roto o perdido algo lo podéis recuperar desde ahí.
Los submódulos añaden un nivel de complejidad, pero puede merecer la pena. Quizá hagan falta comandos más amigables (igual que existe el pull que no es más que un fetch y un merge), pero por lo demás son bien sólidos.
Pero parece que git (y los hashes que mencionas) apuntan a un 'detached head' que es como un ghost branch (estilo la que se genera cuando estas en mitad de un rebase). Y ni puta idea de como funciona el detached head ese de los cojones
El detached head aparece cuando haces un submodule update. Como decía antes, git te pone el subrepo en el hash que le corresponde. Volviendo a lo de los grafos en #6, lo que pasa es que se pone en un nodo concreto del grafo. La mayoría de las veces ese nodo o commit es el mismo que el que indica una rama, no hay mayor problema. Lo que dice git con lo detached es que SI haces un commit en ese momento, como no tienes ninguna rama 'activa' (aunque haya una rama apuntando a ese nodo o commit), ese commit va a quedar en peligro de perderse, porque si cambias de rama ese commit, al no estar apuntado por ninguna rama, es inaccesible (excepto si conoces el hash de ese commit). Es decir, te está diciendo: 'ojito, que nadie está vigilando lo que haces ahora, y si haces un commit es fácil que lo pierdas'.
No sé si te ayuda...
Entonces... si el hash apunta a un commit... realmente da igual el branch del submodulo, no? Si hago (por 'fuera', trabajando en el repo de la libreria) un pull request de 'develop' a 'master'... el hash se mantiene y el mismo commit está en ambas branches, no? Aunque claro, según lo usamos el 'merge' genera otro commit.
Que follón! Pero bueno, algo he aprendido (creo)
No te sigo del todo, pero vamos, mientras no hagas otro commit en el superrepo que incluya un nuevo estado del subrepo el subrepo no cambia. Si cambias de rama en el superrepo pero en ambas rama el hash del suberpo es el mismo, el subrepo se queda igual.
Al final es pensar que un subrepo, que es una carpeta dentro de tu superrepo, es como un fichero más (lo incluyes en tu comit cuando quieres que lo que haya cambiado en el subrepo quede reflejado en el superrepo) solo que se representa por el hash del commit del subrepo.
De todas formas e simpsoible entenderlo sin enredar, te recomiendo que con esta explicación un día juegues un poco con tu superrepo y subrepo y seguramente te quede más claro.
PD: menudos hostiazos
stevebennett.me/2012/02/24/10-things-i-hate-about-git/
Para mi la verdad que desde que he podido evitarlo me ha ido mucho mejor, había mucho jaleo dentro del equipo con el tema de los submodulos. En mi caso los dos gestores de dependencias que utilizo trabajan a su vez con git, por lo que tenerlas privadas o no es trivial, y para un equipo tener una organización en base a un versionado semántico es menos problemático y mucho más solido que los submodulos (versionando caoticamente y con poco control en base a commits), que dicho sea de paso, me parece lo menos sólido de todo git.
En mi experiencia, siempre que se pueda, mucho mejor monorepo
Cc/ #9
Eso me soluciona algunas cosas pero me crea problemas nuevos
Visual SourceSafe's stability is criticised due to the way Visual SourceSafe uses a direct, file-based access mechanism that allows any client to modify a file in the repository after locking it. If a client machine crashes in the middle of updating a file, it can corrupt that file.[14] Many users of Visual SourceSafe mitigate this risk by making use of a utility provided by Visual SourceSafe that checks the database for corruption and, when able, corrects errors that it finds.
Yo en su día lo sufrí: un equipo de unas 15 o 20 personas (una PYME) en una oficina trabajando contra el mismo servidor de SourceSafe. Cada cierto tiempo (cada semana, cada 15 o 20 días, no recuerdo bien) se corrompía y había que esperar un rato a recuperarlo (con pérdida de datos una de cada tres veces, mas o menos). Es posible que con un equipo más pequeño, o una persona sola, no suceda esto.
SourceSafe es realmente un juguete, es como el Notepad de Windows: ¿te hace el servicio? Bueno, para cosas muy simples sí, pero no para mucho más.
Por otro lado, liarla parda con git no es fácil. Está pensado para no perder datos nunca. Otra cosa es que no lo controles bien y haya situaciones de la que no sepas salir, pero es falta de conocimiento, pero al final siempre puedes hacer como dice #5
Git es una herramienta muy potente, pero requiere esfuerzo para aprenderla. Menos del que la gente cree, pero es cierto que al principio resulta intimidante. También es cierto que está muy centrada en la línea de comandos y en Windows debe ser bastante engorroso de usar, aunque tienes varias GUI que te evitan ese problema.
blog.plasticscm.com/2010/11/version-control-timeline.html