EDICIóN GENERAL
218 meneos
5962 clics
Aprende jugando a utilizar git [ENG]

Aprende jugando a utilizar git [ENG]

"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
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…   » ver todo el comentario
#6 Mucho más claro, dónde va a parar.
#8 De ahí lo de "en plan espeso" :-D
#8 :-D :-D :-D 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 :shit:
#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…   » ver todo el comentario
#18 Pues... si ayuda, si. Aunque he tenido que leer 3 veces el comentario xD

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) xD
#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…   » ver todo el comentario
#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 xD
#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 xD
#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 xD

Eso me soluciona algunas cosas pero me crea problemas nuevos :-P
#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:

blog.plasticscm.com/2010/11/version-control-timeline.html
Donde esté ClearCase, que se quite lo demás... :troll:
#25 Source Safe mola(ba) +1000 :troll:

PD: menudos hostiazos :palm:
Es importante aprender a usar bien Git, porque simplemente programar bien es tan fácil que resulta aburrido.

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
#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

…   » ver todo el comentario
#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.
comentarios cerrados

menéame