Portada
mis comunidades
otras secciones
#2:
#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.
Si fuese un artículo sobre como usar CVS en 1998 sí se podría argumentar que no tiene mucha relevancia en el presente.
#27:
#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á 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.
#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.
Comentarios
Resumiendo, Git funciona así:
#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 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.
#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á 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.
#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.
https://media.giphy.com/media/cFkiFMDg3iFoI/giphy.gif
#26 jajajaja
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:
https://github.com/TrinityCore/TrinityCore/pulls?page=3&q=is%3Apr+is%3Aopen 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
/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
#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.
#0 Muy interesante el blog, gracias por el descubrimiento.
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!
G.I.T -> Search Engine Powered Repository System.
Te lo dice el propio nombre.
Raúl Ávila, el autor, ha sido mi gran descubrimiento de este 2017. Su blog es oro puro para programadores.
Bromas aparte, a quienes tengais ya unos conceptos de GIT os recomiendo GItKraken. Te agiliza mucho al hacer comandos poco intuitivos.
https://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
Cómo funciona Git
La verdad es que funciona muy bien
#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...
#12 gran verdad!
#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.
#32
#59 Te puse un positivo para compensar
#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.
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.
#9 te invito a intentar mergear los commits que faltan de https://github.com/TrinityCore/TrinityCore en https://gitlab.com/trinitycore/TrinityCore_434/tree/4.3.4 a ver si sigues opinando lo mismo
(o incluso encontrar los commits que realmente faltan en el 2º) 
#15 Esta tarde lo intento.
#40 para lo 2º
saca muchos falsos positivos.
git cherry -v origin/4.3.4 3.3.5
no va bien
#9 A mi me sacas de los 4 botones del sourcetree y me matas
#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.
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.
#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 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.
#57 para que preguntas
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.
La verdad sobre git
https://media.giphy.com/media/cFkiFMDg3iFoI/giphy.gif
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
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.
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
Pfff a estas alturas
Yo es que soy de Sistemas...
Es un post de enero...
#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 .
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 https://github.com/git/git/tree/master/Documentation/RelNotes por si acaso.
#55 Gracias Sara.
#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.