Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev


uchar

#8847 Si aprendes a usar "rebase" tienes el 90% del operativo diario hecho.

1 respuesta
Naith

#8847 https://git-scm.com/book/en/v2

1 respuesta
Fyn4r

#8846 lo seré en un par de años si todo va como dios manda

2
raul_ct

#8850 muchas gracias por el consejo, pero ahora mismo me suena a chino xd

raul_ct

#8851 gracias, pero lo mismo que el otro, ahora mismo me suena a chino (eso no tanto) #8852 perfecto! Voy a leerlo

1 respuesta
pastaa

#8842 El proyecto tenia casi 20 años y sin problema va a estar ahi otros 10-20 años.

desu

#8855 Git es una mierda. Si tu equipo no esta trabjando con alguna capa por encima estas en un equipo de pajeets. En FAANGs tienen monstruos por encima por problemas de escalabilidad, en industria videojuegos, embedded, sistemas tienen otras capas por temas de binarios, en open source otra por tema de control sobre el historico, para la otra gran mayoria de usuarios git es como programar en asamblador a nivel de UX (una autentica mierda)... El control de versiones es un problema abierto que espero ver resulto pronto. Te recomiendo googlear sobre el tema antes de que te metan los pajeets en la cabeza de que git es la polla, ninguno te sabria razonar el porque. Mi aporte.

1 respuesta
raul_ct

#8857 si es por aprender por gusto, nada más

1 respuesta
desu

#8858 Entonces olvida todo lo que he dicho, que ha sido no solo dirigido hacia a ti sino para compartirlo con el resto de usuarios.

En tu caso ademas de usarlo te recomiendo que mires sobre merkle trees y como funciona git (a muy basico nivel) por dentro. Git como implementacion es un monstruo caotico pero la criptografia aplicada es elegante y me gusta mucho. Deberias poder implementar tu propio git basico de 0 en un par de dias y es un buen ejercicio tipico de la uni.

1 respuesta
isvidal

#8842 Mi primer código es posible, era un proyecto de mierda, pero seguirá seguirá un tiempo seguro.

El que seguro estará décadas es el que he picado en mi ultima empresa, donde implemente muchísima lógica de negocio en el core mismo de la empresa, y siendo una comercializadora eléctrica con 20 a;os a sus espaldas, dentro de 20 a;os algún masilla recién salido de FP estará aun pasando por encima de mi código.

Ranthas

Pues ni idea de si mi primer codigo aun se sigue usando, teniendo en cuenta lo inutiles q eran en aquella empresa lo mas probable es q si xdd

eXtreM3

#8847 busca gitflow.

1 1 respuesta
Fyn4r

> asamblador

1 respuesta
Markitos_182

#8863
> ensamblea

raul_ct

#8862 que locura, que estoy empezando xd

1 respuesta
Grise

#8865 Pero si Gitflow es para monos, que lo único que hace es estructurar un flujo de trabajo en Git para que no sea un puto caos. Aprender a usar Git en si es una tontería que te cuesta una tarde, tienes que saber cuatro cosas para hacer un uso básico. Ver el código y lo que hace es otra historia, pero usarlo es una chorrada.

aren-pulid0

Yo creo que aveces no recordáis cuando empezasteis

2
JuAn4k4

#8859 Si git tiene menos lineas de código que tu blog.

1 respuesta
desu

#8868 Ese bait es tan malo que no voy a entrar, imaginate. (El comentario es ingenioso, falaz y falso, pero inginioso, 0 contenido, 6 en estilo, te queda un 3 de media).

Pero si que te animo a que nos compartas tu experiencia con otros svc/wrappers como hg, git-repo, fossil (imagino que la tienes). Yo no los he probado y solo se lo que me han dicho mis amigos en empresas grandes que tienen sus soluciones.

1 respuesta
Ranthas

Si no haces tu propia implementacion de un cvs eres un puto masilla y te mereces picar cruds en la carnica de turno hasta que los patos crien pelo

1
Mahjunia

Alguien sabe el link de una página donde la gente posteaba como "ideas" de apps y tal?

1 respuesta
Wei-Yu

#8871 no era un subreddit? yo al menos conozco este

https://www.reddit.com/r/showerthoughtapps

1
JuAn4k4

#8869 Lo de falso depende de lo que uses como blog, si es un WordPress no lo es.
He usado git repo, pero vamos, que sin necesidad real, pese a tener muchos repos, al final si tu workflow no es de pajeets, tocas uno o dos. Al final los problemas que solucionan estas herramientas no son de git, sino del workflow en general.

No te digo que no tenga mejoras, la solución de conflictos en código es muy mejorable si tienes en cuenta el lenguaje del fichero. Pero git no va a abrir ese melón.

1 respuesta
desu
#8873JuAn4k4:

Al final los problemas que solucionan estas herramientas no son de git, sino del workflow en general.

Claro es que eso es exactamente lo que he dicho, git como idea elegante pero en estos 30 ao;s nadie ha solucionado el como usarlo.

Me suena una talk de Jon Blow o George Hotz donde comentaban el tema, creo que era Jon, y decia que para el programador deberia ser completamente transparente, solo deberias escribir codigo y no te debes enterar de nada, ni el resolver conflictos.

Yo estube pensando el tema hace unas semanas, queria a;adir una capa de logica formal con smt por encima de mis ficheros y crear unos grafos de dependencias para replicar la idea de ownership de rust. (si un programador toca estos ficheros, estos modulos, otro no puede hacer push p.e a nivel mas basico) pero es una idea a medias que no va a solucionar edge cases (hot fixes que te tienes que tragar en prod). Para proyectos peque;os (3-4 personas, <100k loc) tener un par de reglas asi me parece suficiente y no es dificil automatizar. hice la poc y al ser algo tan basico llegue a la conclusion de que otra solucion ya existente (las mencionadas atras) serian ya utiles.

Esto de hacer pull y merge de partes del codigo automatico por lo que vi lo resuelven mediante testeo de las apis, si modificas el codigo de dentro de una funcion pero los tests de los modulos que utilizan esa funcion pasan sin problemas hacen el merge automatico y pasas a un estado de merge parcial.

Si estas escribiendo tests o anotaciones para automatizar todo esto, que benficio realmente has sacado? No es transparante, igualmente el progamador tiene que hacer trabajo extra. Pero bueno, para la mayoria de gente creo que seria mejor obligarles a hacer tests y tener git automatico que no obligarles a aprender gitflow/github flow, no tendras ni tests ni te aseguras buen uso de git. Concluyo y cierro.

1 respuesta
JuAn4k4

#8874 Entonces estamos de acuerdo en que no es git lo que es una mierda.

Para que el dev no tenga que hacer nada falta mucho en la resolución de conflictos, si juntasemos el análisis sintáctico y semántico del propio lenguaje al diff de texto, se podrían resolver michos de los conflictos de hoy en día, salvo casos de conflicto real.

Se me ocurren cosas, pero hay cierto nivel que ha de controlar el usuario (crear una rama o marcarlo como terminado por ejemplo).

Se podría llegar a hacer:
Rebases automáticos en ramas locales antes finalizar el trabajo, y crear el PR.
Hacer auto-commits para guardar en la rama local con cada cambio de fichero en disco (el IDE hace el auto-guardado, se podría llegar a incorporar) - Aunque entran los hooks... (no verify?)

Si se resolvieran el 99% de conflictos, al usuario le dejas con: empezar (ticket n# -> rama), terminar (rebase+pr + checkout de máster/develop)

Es interesante, pero todo esto queda totalmente fuera de lo que es git como producto, y hacen bien en dejarlo fuera.

Al final para mi es lo de siempre, empresas haciendo las cosas mal y echando más madera (pajeets), cuando con un grupo reducido de devs y haciendo las cosas bien, se consigue mucho más.

1 respuesta
r2d2rigo

#8875 felicidades, has descubierto el producto de una empresa espa;ola: https://www.semanticmerge.com/

1 1 respuesta
Wei-Yu

"descubierto" una idea que tiene 40 años

JuAn4k4

#8876 A eso me refiero, además de binarios como Office por ejemplo, que no sería complicado tampoco. Pero ya hay que hacerse cada uno. Las ideas que digo son para lo que pide desu, de no tener que hacer nada.

No sabía que existiera la verdad, nunca me ha supuesto mucho problema arreglar conflictos, pero he de decir que ahorra tiempo y no es nada caro.

Merkury

#8839 Yo de esas cosas no se nada.

Por cierto el dia 19 despues de cuatro años cambio de curro y ya paso de los 4.5k/mes limpios :D

15 6 respuestas
desu

#8879 Enhorabuena tio, hoy ando liado pero que sepas que me he logeado SOLO para darte manita y felicitarte. Pensaba que eras mas mayor, 4 años de experiencia (o del mismo curro?) casi 5k, ya gustarian a muchos yo incluido.

La harina con la que juegas seguro que es para hacer pan?

1 1 respuesta

Usuarios habituales

  • desu
  • Ranthas
  • Fyn4r
  • HeXaN
  • Kaledros
  • eondev
  • Wei-Yu