Portada
mis comunidades
otras secciones
![Aprende jugando a utilizar git [ENG]](https://cdn.mnmstatic.net/cache/31/30/media_thumb_2x-link-3223637.jpeg?1575998766)
#6:
Un clásico. Está muy bien para aprender git, que no es intuitivo.
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í.
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í.
Comentarios
Un clásico. Está muy bien para aprender git, que no es intuitivo.
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í.
#6 Mucho más claro, dónde va a parar.
#8 De ahí lo de "en plan espeso"
#8 Pensaba que alguien respondería algo del estilo: "¿Qué parte de grafo, acícliclo, conexo o de clausura transitiva no entiendes...?"
#6 Yo me llamo Ralph
#17 Esa confusión que tienes es normal cuando empiezas con submódulos. Como decía antes, en el superrepo se guarda el hash del commit en el que quieres tener el subrepo (el hash es simplemente un identificador de cada commit). Lo que NO puedes hacer es decirle a git que quieres tener el subrepo en una rama concreta, por que las ramas se mueven (si haces un commit en esa rama, la rama apunta a otro commit). Git quiere que le digas que el subrepo está en un commit dado, algo sólido, no una rama que se mueve. Salvando mucho las distancias, es como si le dices a git que quieres que mantenga en el repo un fichero y que cuando cambie ese fichero git lo comitee él solito: no se puede hacer.
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...
#18 Pues... si ayuda, si. Aunque he tenido que leer 3 veces el comentario
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)
#21 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?
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.
#21 Vuestra conversación muestra lo mierdoso que es git en algunas ocasiones. Y la curva de aprendizaje es horrorosa.
#29 Es un software complicado, desde luego. ¿Alguna alternativa seria mejor? Si git se ha convertido en un estándar de facto en la gestión de código, por algo será.
#18 Ah, y muchas gracias!!
#6 No es intuitivo? En serio?
#13 Los submódulos funcionan perfectamente y en muchos casos no puedes usar gestores de dependencias o es muy costoso (porque es ćodigo que no es integrable en un packagist, npm, gems o el que sea). Por ejemplo, código custom que no puede ser público (y no quieres montarte un servidor privado de dependencias), código custom que no pertenece a ningún tipo de software que sea gestionado por un gestor de dependencias.
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.
#15 Ya, yo no quiero generalizar, por eso decia “si es el caso”.
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
concho… yo creía que esto lo conocía todo mundo.
#4 posno. Y me lo planifico para Navidad, frikk Navidad
#4 Pues si tienes a mano una buena guía para submodulos pon el link por aquí, que llevo meses con esa mierda y aun no entiendo como funcionan
#9 En repo principal (superrepo) se guarda el hash del repositorio del submódulo. Es decir, igual que en un determinado commit git guarda el estado de cada fichero, para los submódulos lo que guarda es el hash en el que está el subrepo (el repo del submódulo). Así, cuando cambias de rama (haces un checkout) en el superrepo, git simplemente cambia el hash en el que debe estar cada uno de los submódulos. Para que los submódulos cambien efectivamente su contenido (lo que ves cuando listas el directorio donde está el submódulo) ejecutas git submodule update (que es como decirle a git que haga un checkout en cada submódulo al hash en el que debe estar cada uno de ellos según el commit actual del superrepo).
#12 Gracias. Hasta ahí vamos bien. No conocía algunos detalles pero en general bien. Mi problema es cuando también tienes branches en el submodulo. Mi feature branch del super debería apuntar al branch 'develop' del submodulo. Y el master al master.
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
#9 Los submodulos es mejor evitarlos, dan mucho problema y tampoco son necesarios (mucho mejor usar gestores de dependencias y versionar en condiciones si es el caso)
#13 En mi caso necesito que una carpeta dentro de un repo sea otro repo. Es como una librería compartida pero no es ningún lenguaje de programación estándar que puedas generar un jar o similar y usar maven.
#14 pon esa carpeta en el .gitignore y gestiónala aparte, puede apuntar a otro repo distinto. Para mí es lo más fácil.
Cc/ #9
#36 No es mala idea, la verdad. Pero tendría que clonar ese repo... unas 20 veces
Eso me soluciona algunas cosas pero me crea problemas nuevos
#4 viejuno pero útil, ya no sé cuántas veces lo he enviado a distintos compañeros para que practiquen
En el titulo pone [eng] pero esta traducido en perfecto argentino, por lo menos al principio.
Dame una... ?
Un resumen interesante de la historia de los gestores de código:
http://blog.plasticscm.com/2010/11/version-control-timeline.html
Donde esté ClearCase, que se quite lo demás...
#25 Source Safe mola(ba) +1000
PD: menudos hostiazos
Es importante aprender a usar bien Git, porque simplemente programar bien es tan fácil que resulta aburrido.
https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
#31 Sí, el viejo artículo sobre lo que no le gusta de git. Con cierta base de verdad, pero mucha exageración. Las comparaciones con SVN son una mala elección, la verdad, SVN es precisamente bastante duro de usar, y aprenderlo es complicado. Si ya lo usas y esas cómodo, ok, pero si vas a aprender algo nuevo aprende git de largo. Ahora mismo si tengo que interactuar con un proyecto en SVN es como volver a la edad media.
#3 git reset —hard
A buen entendedor, pocos comandos...
Error
Borrar repo
Clonar repo
#1 copy *.* Y a rular
#1 https://xkcd.com/1597/
#30 #33 Visual SourceSafe tiene varios problemas. Primero, es solo para Windows, así que si trabajas en otro entorno no lo puedes usar. Por otro lado, la última versión es de 2005, es un producto descontinuado. Por último, su estabilidad es muy pobre. Ya lo dicen en la misma Wikipedia:
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.
#39 Pues no esa la experiencia que he tenido yo, 15-20 proyectos, con unas 50 -60 personas trabajando.
Es como las dietas, todos los años nos proponemos usar git.
#19 Con la diferencia de que si no usas un gestor de código o usas un gestor de la generación anterior (CVS y Subversion principalmente) usar git te hace la vida mucho más fácil (ramas nuevas instantáneas, merges fáciles). Si, tienes que aprenderlo, pero solo lo aprendes una vez. Es como si tuvieses que hacer dieta una sola vez en la vida, y una vez en tu peso ya puedes comer todo lo que quieras que te mantienes.
#24 Bueno, Visual SourceSafe tiene una curva de aprendizaje mucho más rápida, y para una pyme da más que de sobra. Nosotros lo usamos durante dos décadas, y seguimos haciéndolo con los proyectos viejos. Con git, sin embargo, más de una vez la ha liado parda alguien.
#30 Para pymes y no tan pymes..., yo lo he usado 12 años, y se pueden hacer muchas cosas con él, soluciona la papeleta más que de sobra. Para mi git es un pequeño infierno, y que tarde o temprano alguien la liara, no Sabra seguir..., y acabará empezando desde cero con la última copia.