• 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.

    Leer en meneame.net | Noticia original

15 Comentarios

  1. pip /  hace 1 año

    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.

  2. demostenes /  hace 1 año

    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, imágenes, enlaces... El texto plano sólo sirve para describir errores en bash.
    De nada me sirve registrar cada modificación si para anotar comentarios, realizar cambios de version o juntar ramas tengo que usar un interfaz CLI incómodo y poco usable.
    Lo importante no es tanto registrar la información como poder acceder a ella, manejarla fácilmente y verla de forma gráfica.

    Para mi -hoy día- es más util un comparador de ficheros que te muestra las diferencias en colorines que git.

    • pip /  hace 1 año

      ¿? ¿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.

      • demostenes /  hace 1 año

        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.

        • pip /  hace 1 año

          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 política de proyecto.

          Para control de versiones usamos SVN, no git, por inercia más que nada, y lo usamos tanto desde el terminal Linux como desde tortoiseSVN (cliente gráfico para Windows) como RabbitCVS (ídem para Linux). También tenemos algún script que accede a SVN al compilar para incrustar la info revisión en el binario final, así que como ves es importante tener acceso CLI.

          Yo sigo viendo conceptos separados y la verdad lo veo bien como está, siempre mejorable cada uno en su cosa pero deben mantenerse independientes y con acceso GUI+CLI.

  3. AzzaPfeiffer /  hace 1 año

    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 converger con master, o al menos reducir el tamaño de los conflictos. Usad TDD. Cread commits frecuentemente. Git es amor.

    Paracetamol: si revertiste un commit, hay que revertir ese commit revertido o al mergear no se aplicarán los cambios y parecerá que desaparecen commits

  4. perrinchi /  hace 1 año

    Pfff a estas alturas

  5. plastname /  hace 1 año

    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 entender es la función de rebase, por las que lo leo no lo entiendo.

    La verdad es que el artículo está muy bien para entender como funciona "por detrás" aunque se me escapan algunas cosillas, pero siempre viene bien una lectura así para aclarar algo las ideas porque su función la tenía clara, pero no su funcionamiento, más que nada por la pereza de ponerme. Mientras funcione... Hasta que te toca comerte algún marrón jejeje.

  6. Zeioth /  hace 1 año

    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.

    • Anthk_ /  hace 1 año

      Software cerrado para una herramienta abierta. Meh. Gitg y para merges, Meld.

    • sin_animo_de_lucro /  hace 1 año

      yo lo uso a diario y estoy contentísimo, especialmente con meld como herramienta de merge

  7. choskar7 /  hace 1 año

    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

  8. kimbbo /  hace 1 año

    Raúl Ávila, el autor, ha sido mi gran descubrimiento de este 2017. Su blog es oro puro para programadores.

  9. XtrMnIO /  hace 1 año

    Yo es que soy de Sistemas... :shit:

  10. Bilki /  hace 1 año

    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.

    • llorencs /  hace 1 año

      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.

      • xenko /  hace 1 año

        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.

        • llorencs /  hace 1 año

          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.

          • sagnus /  hace 1 año

            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 hecho, si entramos ya en el tema de que quizá tienes una versión en local, otra subida online pero luego tienes otra en la caché (tenía un nombre, no recuerdo ya que hace tiempo que no toco el git) al final te piensas 1 minuto si dar al enter al escribir un comando que supuestamente borra la caché, no vaya a ser que borre también el local porque se te ha olvidado poner un parámetro o algo parecido.

            ¿Como podría ser mejor? Ni idea, como herramienta sigue siendo utilísima y las quejas son más del estilo "que dura es la vida" más que decir que la herramienta es una mierda, pero a veces dan ganas de cagarse en todo cristo.

            • Bilki /  hace 1 año

              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á claro es que la cosa se complica si tienes el histórico hecho unos zorros, varios remotos, ramas que llevan siglos sin mergear, etc. Pero eso ya es un caso específico bastante complejo, ¿no crees? Mi comentario iba más por desarrollos realizados por equipos pequeños.

              • sagnus /  hace 1 año

                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.

              • sin_animo_de_lucro /  hace 1 año

                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.

        • plastname /  hace 1 año

          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

          • vorotas /  hace 1 año

            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.

            • plastname /  hace 1 año

              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.

          • redscare /  hace 1 año

            jajajaja xD Me siento identificado ahí.

        • cosmonauta /  hace 1 año

          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.

          • xenko /  hace 1 año

            ¿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.

            • cosmonauta /  hace 1 año

              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.

        • mr_b /  hace 1 año

          Si crees que es difícil, prueba con Subversion :troll:

          /cc #11

          • llorencs /  hace 1 año

            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:

            • mr_b /  hace 1 año

              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.

              • llorencs /  hace 1 año

                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?

          • xenko /  hace 1 año

            di no a las drogas.

      • Trublux /  hace 1 año

        Esta tarde lo intento.

        • Aokromes /  hace 1 año

          para lo 2º
          git cherry -v origin/4.3.4 3.3.5
          no va bien xD saca muchos falsos positivos.

    • redscare /  hace 1 año

      A mi me sacas de los 4 botones del sourcetree y me matas xD

    • ElPerroDeLosCinco /  hace 1 año

      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.

  11. Zeioth /  hace 1 año

    G.I.T -> Search Engine Powered Repository System.
    Te lo dice el propio nombre.

  12. TommyRabo /  hace 1 año

    Resumiendo, Git funciona así:

  13. radioman /  hace 1 año

    Cómo funciona Git

    La verdad es que funciona muy bien :-D

    • Aokromes /  hace 1 año

      si yo te contase las pesadillas de mergear 2 branch que tengo........

    • avalancha971 /  hace 1 año

      Funciona muy bien si sólo utilizas las cuatro funciones básicas o si sabes utilizarlo bien.

      Si no...

      • Aokromes /  hace 1 año

        gran verdad! xD

      • adrigm /  hace 1 año

        Que tire el primer negativo el que haya usado Git y no lo haya hecho alguna vez.

        • Interrogación /  hace 1 año

          Yo uso git y nunca he hecho eso.

          • adrigm /  hace 1 año

            :roll:

      • Sandler /  hace 1 año

        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.

        • avalancha971 /  hace 1 año

          Mientras haya un par de empleados que lo dominen y se encarguen de mantenerlo y solucionar los problemas, todo normal.

          • Sandler /  hace 1 año

            si, es básicamente nuestro caso.

      • johan91 /  hace 1 año

        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.

        • avalancha971 /  hace 1 año

          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.

  14. gobolino /  hace 1 año

    Es un post de enero... :palm:

    • maxmalkav /  hace 1 año

      ¿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.

    • dkalvo /  hace 1 año

      Añadiría a #2 que además, independientemente del contenido, no es un envío al sub actualidad.

    • Kip /  hace 1 año

      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.

    • joffer /  hace 1 año

      tiene 4 partes. La enlazada es la primera.

    • chiniwini /  hace 1 año

      ¿Ha cambiado mucho Git desde enero?

      • meneameapesta /  hace 1 año

        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.

        • chiniwini /  hace 1 año

          Gracias Sara.

          • meneameapesta /  hace 1 año

            para que preguntas

Ofertas

Loader noticialalminuto

Volver arriba

Esta web utiliza cookies, puedes ver nuestra política de cookies, aquí Si continuas navegando estás aceptándola