EDICIóN GENERAL
252 meneos
5762 clics
Cómo funciona Git (parte 1)

Cómo funciona Git (parte 1)

Git es una herramienta de control de versiones distribuida, pero en última instancia no es más que un gestor de contenido, y en este post entenderéis por qué. El núcleo de Git no es ni más ni menos que un mapa clave-valor de toda la vida, donde las claves son valores hash generados mediante el algoritmo SHA1, y los valores pueden ser varias cosas. En este post nos centraremos en los diferentes tipos de valor que Git puede almacenar.

| etiquetas: cómo funciona , git , parte 1 , internamente , control de versiones
124 128 5 K 331 SysDevs
124 128 5 K 331 SysDevs
Es un post de enero... :palm:
#1 ¿Y qué problema hay? En este caso el envío no es una noticia, es un artículo sobre un tema técnico suficientemente actual. Si bien tiene unos meses, no lo hace estar desfasado y tiene valor divulgativo sobre una tecnología ampliamente usada.

Si fuese un artículo sobre como usar CVS en 1998 sí se podría argumentar que no tiene mucha relevancia en el presente.
#1 Añadiría a #2 que además, independientemente del contenido, no es un envío al sub actualidad.
#1 Pues no lo has publicado en todo este tiempo, #0 ha estado esperando y al final ha tenido que publicarlo :troll:.


Que más da cuando se publique algo, lo importante es que sea útil y no esté desfasado, un saludo.
#1 tiene 4 partes. La enlazada es la primera.
#1 ¿Ha cambiado mucho Git desde enero?
#51 No mucho, pequeños cambios por aquí, mejoras por allá, pero funcionalmente poca cosa. Siempre viene bien leerse las "Backward compatibility notes" de cada Release github.com/git/git/tree/master/Documentation/RelNotes por si acaso.
#55 Gracias Sara.
#57 para que preguntas
#1 Entiendo sí que hay que tener en cuenta la fecha de lo que va en “actualidad”, pero ¿en tecnología? ¿En este sub específico? ¿Acaso pierde interés o se vuelve obsoleto con el tiempo? ¿Tiramos abajo todos los libros de más de un año que hablen de cualquier cosa? Pues yo creo que con esto lo mismo. No es actualidad, es conocimiento. Y eso no caduca.
Cómo funciona Git

La verdad es que funciona muy bien :-D
#3 si yo te contase las pesadillas de mergear 2 branch que tengo........
#3 Funciona muy bien si sólo utilizas las cuatro funciones básicas o si sabes utilizarlo bien.

Si no...  media
#12 gran verdad! xD
#12 Que tire el primer negativo el que haya usado Git y no lo haya hecho alguna vez.
#25 Yo uso git y nunca he hecho eso.
#59 Te puse un positivo para compensar xD
#12 la mitad de mis empleados no lo entienden bien, por más que hasta les demos incluso cursos sobre el tema. Al final te das cuenta de que realmente no es necesario que lo dominen, con las 4 cosas básicas es suficiente.
#39 Mientras haya un par de empleados que lo dominen y se encarguen de mantenerlo y solucionar los problemas, todo normal.
#47 si, es básicamente nuestro caso.
#12 Entiendo el chiste porque sé que la mayoría de la gente no sabe usarlo, pero la mayoría de los problemas que tiene la gente con git son más de una mala arquitectura del código que del propio git.
#63 No te creas, simplemente con ficheros que no contienen codigo se puede liar la cosa si te pones a hacer cherry-picks, rebases, etc. combinado con distintas branches... si no sabes lo que estas haciendo.

Y ya como lo tengas integrado con gerrit ni te cuento.

Aun asi, me parece el mejor sistema de control de configuracion que existe. En una empresa tuve que utilizar ClearCase/ClearQuest y aquello era un infierno.
Resumiendo, Git funciona así:  media
#0 Muy interesante el blog, gracias por el descubrimiento.
G.I.T -> Search Engine Powered Repository System.
Te lo dice el propio nombre.
Siempre me ha parecido curiosa la dificultad que encuentra la gente, incluso buenos programadores, en usar git, cuándo es relativamente sencillo comparado con otros problemas. Algo tan típico como un rebase para mantener limpio el histórico hace que la gente te ponga los ojos en blanco cuando les hablas de ello. Creo que es sencillamente dejadez, se ve el control de versiones como un mal necesario, en vez de apreciar el cúmulo de ventajas que proporciona.
#9 La verdad es que lo estoy empezando a usar, con cosas muy básicas, y solo con 2 ramas (ya que para mi es más que suficiente) y la verdad que no lo veo complicado. No sé si lo uso bien o no, ya que estoy aprendiendo a usarlo por mi mismo, pero aún así como lo uso me sirve y me es más que suficiente.

Y sí, a primera vista y en mi uso básico no me parece tan complicado, la verdad.

#10 Incluso para sistemas sirve. Más si tienes que mantener scripts del sistema y controlar las revisiones que puedas hacer.
#11 cuando trabajes en un proyecto con otros diez desarrolladores, y tengas que hacer un merge de la rama principal a la tuya el último día de la release, cuando todo dios acaba de subir sus cambios, vienes y nos cuentas.
#17 Qué ocurre en ese caso?

Como he dicho, soy novato y básicamente lo uso para mi y mantener mis mini desarrollos (sripts principalmente) y alguna aplicación.

Pero, con el uso básico que hago me sirve muy bien y va perfecto.

Obviamente se puede complicar un poco cuando hay mucha gente usándo el mismo repositorio. Pero eso ocurre con cualquier cosa. No es lo mismo desarrollar una aplicación que lo van a usar 5 personas que 1000 personas.
#22 Como he dicho, soy novato y básicamente lo uso para mi y mantener mis mini desarrollos (sripts principalmente) y alguna aplicación.

Ahí está el quid de la cuestión, y no es con ganas de ofender. Precisamente la ventaja de git es la capacidad de trabajo colaborativo que tiene, y es precisamente cuando trabajas colaborativamente que empiezan los problemas, donde los conflictos se dan por doquier y hay que gastar un poco de tiempo resolviendo alguno a mano, por lo general. De…   » ver todo el comentario
#24 pero tus quejas son metodológicas, no es culpa de la herramienta. Si las features están mal planificadas, y varias personas trabajan sobre el mismo código, los conflictos se van a dar sí o sí, y hay que resolverlos. Esto se puede mitigar haciendo rebase periódicos sobre el trabajo de los demás, ramas cortas para features cortas y claramente separadas, evitando que el último que va a mergear se tenga que comer la mierda.

#15 no he llegado a verlo bien porque estoy con el móvil. Lo que está…   » ver todo el comentario
#27 Justo justo, por eso te digo, que cuando yo me quejo es más del estilo "así es la vida, que se le va a hacer". Es un peñazo, pero es un sacrificio necesario.
#27 Git flow, no? para mi es básico... un git "pelao" puede ser la muerte si hay muchos desarrolladores que no lo dominen, con el git flow se encauza todo mucho mejor.
#17 En mi caso somos solo dos, pero utilizamos phpstorm y la herramienta para resolver conflictos es la hostia. Aunque con 10 desarrolladores y en último día... No quiero verme en una de esas jajaja
#23 Ya te digo, por necesidades del proyecto donde estoy tengo que usar Eclipse, aunque solo toque front, y echo de menos muchísimo Webstorm por su herramienta de git, sobre todo a la hora de resolver conflictos, eso de que te aparezcan 3 pantallas con los cambios del repositorio, los tuyos y el archivo tuyo original es genial.
#30 Yoy frontanero también y aunque de PHPStorm me sobra el 90% de las funcionalidades que ofrece si ahora mismo me lo quitasen sería una gran putada por ese 10% que si utilizo. Aunque ya se sabe aquí hay que acostumbrarse a tocar de todo jejeje. Precisamente con Eclipse tengo 0 experiencia.
#17 Te resumo tu comentario con un gif.

media.giphy.com/media/cFkiFMDg3iFoI/giphy.gif
#26 jajajaja xD Me siento identificado ahí.
#17 en esa situación, el problema no es git. El problema son 10 tios que han trabajado descoordinados durante 2 semanas. El mismo problema existiría con cualquier otro cvs.
#37 ¿Y qué haces en un proyecto donde es habitual que se tarden dos semanas en realizar las contribuciones?

Eso existe. No siempre se puede dividir el trabajo en porciones de un día.
#38 Me cuesta creer que todas las tareas de un equipo de 10 personas suelan tener una duración de 2 semanas.

Yo he pasado por ahí, y el tema es convencer al equipo de subir lo antes posible el trabajo y, sobretodo, que hagan un pull cada día sobre sus repos locales, de manera que los conflictos se van resolviendo poco a poco.

Y la otra, cuidado con los rebases. Son muy chulos, pero te lian parda cuando 2 personas comparten rama.
#41 a veces la gente se pone a trabajar con caracteristicas muy gordas que no pueden ser mergeadas hasta que son completas, un ejemplo:
github.com/TrinityCore/TrinityCore/pulls?page=3&q=is:pr+is:open 24 PRs son del año y aun no estan completas.
#53 Si.. Por lo que veo es un proyecto bastante monolítico. Así de un vistazo he visto clases con 600 líneas. Eso lo complica todo un poco. Aunque sospecho que también hay discusiones técnicas ahí, aparte de los problemas de mergear. Algunas PR sólo tenían cambios en un archivo. Poco probable que haya un conflicto ahí.
#17 Si crees que es difícil, prueba con Subversion :troll:

/cc #11
#62 Eso dicen que es un infierno, pero cuando empecé unos estudios que dejé (ingeniería informática) hará ya muchos años atrás, subversion reemplazaba a cvs y decían por aquel entonces que era una maravilla (comparado con cvs, claro) :-)

Así, que supongo que cvs aún debe ser más divertido :troll:
#64 Eso es. Subversion fue un sustituto excelente para CVS; funcionó muy bien durante muchos años y nos ayudó a controlar nuestro código fuente. Pero hoy Subversion está obsoleto.

¿Sabes qué es lo peor? Que en mi empresa lo seguimos usando para gestionar un proyecto con más de 50 GB de código y más de 1000 ramas. Imagina por qué creo que Git es dios.
#65 En la empresa que trabajo usan aún subversion para algunos proyectos y no sé si para el principal (no estoy en desarrollo ni nada), pero sí que algo scripts de automatización y alguna cosa que se acerca más a una aplicación un poco de estrangis.

Pero sé que también usan git y algunos proyectos estan en Mercurial(hg).

¿Has probado Mercurial? Más o menos tienen un rendimiento similar, Mercurial y git, ¿no?
#62 di no a las drogas.
#9 te invito a intentar mergear los commits que faltan de github.com/TrinityCore/TrinityCore en gitlab.com/trinitycore/TrinityCore_434/tree/4.3.4 a ver si sigues opinando lo mismo xD (o incluso encontrar los commits que realmente faltan en el 2º) xD
#15 Esta tarde lo intento.
#40 para lo 2º
git cherry -v origin/4.3.4 3.3.5
no va bien xD saca muchos falsos positivos.
#9 A mi me sacas de los 4 botones del sourcetree y me matas xD
#9 Creo que el problema de muchos no es tanto el uso de GIT como la dificultad para trabajar en equipo. Hay muchos programadores que se enfrascan en lo que están haciendo y no les da la olla para pensar un momento en cómo coordinar sus cambios con los de otras personas de una manera eficiente. Y cuando digo "otras personas" incluyo a ese mismo programador al cabo de unos días. Lo que hoy tienes claro y fresco en la mente, dentro de un tiempo no lo estará. Es importante almacenar versiones, comentarlas y gestionarlas dedicando unos minutos de cariño, porque a la larga compensa muchísimo. Y esto vale para GTI, SVN, TFS... y para ordenar la ropa en un armario.
Yo es que soy de Sistemas... :shit:
Raúl Ávila, el autor, ha sido mi gran descubrimiento de este 2017. Su blog es oro puro para programadores.
Ayer mismo pude recuperar un stash que había eliminado por error, me salvó de una buena...
Git es una maravilla y saber usarlo agiliza mucho los cambios de contexto y la gestión de tags y versiones del producto anteriores.
Hay mil tutoriales para lo básico y para todo lo demás, stackoverflow
Bromas aparte, a quienes tengais ya unos conceptos de GIT os recomiendo GItKraken. Te agiliza mucho al hacer comandos poco intuitivos.

www.gitkraken.com/

Funciona en MacOs, Windows y Linux.
#19 Software cerrado para una herramienta abierta. Meh. Gitg y para merges, Meld.
#19 yo lo uso a diario y estoy contentísimo, especialmente con meld como herramienta de merge
Pues para mi la mejor herramienta en mi trabajo diario.

La verdad es que me he viciado a utilizarlo con source tree porque es muy cómodo e intuitivo y el repo del curro lo tenemos en bitbucket, aunque con phpstorm no se lleva muy bien.

Por consola pues lo básico, commitear, pushear, hacer pulls, stashing y hacer reset de las ramas. También hay algunos trucos que he aprendido de los amigos de stackoverflow para solucionar algunas situaciones bastante incómodas. Lo único que no alcanzo a…   » ver todo el comentario
Pfff a estas alturas
He estado curioseando por las entradas del blog y es crema de la buena, no andamos sobrados de sitios así en nuestro idioma.

#0 ¡Gracias! :hug:
Git es una de las mejores herramientas que he visto para control y gestión de código. Llevo años usándolo a diario y no podría vivir sin ello. Veo a mucha gente con problemas y generalmente son problemas sencillos. Es normal; al principio puede ser complicado de entender, luego todo es placer. Los problemas suelen venir por no tener un workflow adecuado. Recomiendo leer acerca de git workflow. Mergead a menudo vuestra rama principal a vuestra rama de desarrollo para evitar conflictos al…   » ver todo el comentario
Mientras sigamos diciendo que git es una maravilla, nadie se planteará crear una herramienta de gestión de versiones decente.
Git es un motor de control de cambios, pero para su uso productivo necesita una buena interfaz gráfica, basada preferiblemente en web y algo mejor que bases de datos de registro de errores como Mantis o Redmine que no permiten adjuntar imágenes o texto enriquecido de forma fácil.
Hoy día para describir un bug es necesario introducir hasta elementos multimedia: videos,…   » ver todo el comentario
#43 ¿? ¿Qué tiene que ver un bugtracker como Mantis en el que por cierto se pueden adjuntar imágenes con un sistema de control de versiones como git o SVN?
Aparte de que hay interfaces GUI para ellos que se integran en el gestor de archivos de escritorio, que es donde lógicamente tiene que estar.
No entiendo tu comentario mezclando conceptos.
#48 Pues que GIT es un motor de control de cambios, pero no una herramienta productiva para usuario final (desarrollador/analista/jefe de proyecto).
Se necesita una capa superior de software para aprovecharlo.
Yo quiero estar concentrado en mi programa, mi algoritmo, mi lenguaje, no en registrar los cambios de aquella o tal manera. Quiero que el editor me pregunte la mejora realizada y pulsar enter. Simplemente.
El día que se puedan copiar y pegar imagenes en Mantis me avisas. Por supuesto se pueden adjuntar ficheros lo cual es mucho más engorroso que copiar y pegar una imagen.
Hace años que se inventaron los objetos BLOB, existe el formato CDATA en base64 para HTML y aún no podemos pegar imágenes en los editores de los navegadores.
#49 nosotros usamos Mantis y adjuntamos imágenes con frecuencia, no sé si hablamos de lo mismo.
Pero sigo sin ver la relación entre Mantis y el CVS, dos software distintos para propósitos distintos, además en nuestro caso el servidor SVN está físicamente en la empresa y el de Mantis fuera porque acceden los clientes. No damos acceso al servidor interno por Internet.

En el bug de Mantis ,apuntamos la revisión de SVN que corresponde pero no siempre, a veces es la versión liberada. Depende de la…   » ver todo el comentario
Nosotros seguimos trabajando a diario con SVN, da pereza pasarse a GIT, aunque no acabo de ver un motivo suficientemente fuerte para cambiarse. Parece mejor en control de ramas pero no solemos hacer forks, y al trabajar con servidor local tampoco nos va lento SVN.
comentarios cerrados

menéame