Feda /dev/ - No Javascript allowed | Página 1807

Kaledros #54181 22 Mar

#54180 Feature flags.

desu #54182 22 Mar

#54180 Partes todo el codigo en PRs pequeñas.

PR_A,
PR_B,
PR_C

En lugar de mergear una a una a master, haces que todas dependan en cadena.

PR_A <- PR_B <- PR_C

Cuando te aprueban todas, mergeas.

Master <- PR_A <- PR_B <- PR_C
Master <- PR_A <- PR_B+C
Master <- PR_A+B+C
Master <- PR_A+B+C
MASTER+A+B+C

No se... Sois subnormales? No habeis aprendido git en el colegio?

Ni puto caso a las feature flags, no pierdas el tiempo.

1 1 respuesta

pantocreitor #54183 22 Mar

#54182 eso es lo que hago cuando la fearure es un monstruo.
A lo que voy es que no entiendo las “normas” de max x líneas o clases por commit, cuando no es una gran cantidad, no saben leer código cuando es más de un método?

1 respuesta

desu #54184 22 Mar

#54183pantocreitor:
no saben leer código cuando es más de un método?

no quieren trabajar

1 respuesta

pantocreitor #54185 22 Mar

#54184 He ahí el tema

Lecherito #54186 22 Mar A toda leche

Las pull request son un cáncer. Seguid pensando en ramas en vez de commits y os irá genial.

Para la basura que son las prs pues casi que prefiero hacer un amend y push -f que hacer un commit de mierda

1 1 respuesta

pantocreitor #54187 22 Mar

Empecé a verle sentido a las PR/MR viendo lo que subía cierta gente a proyectos...
Hay cosas que no deberían entrar nunca a producción

desu #54188 22 Mar

#54186 que mas da? solo es un mecanismo de documentacion usando github/gitlab como porcelana.

podrias usar git-notes y por mi perfecto, pero el fpero random se le atraganta darle a squash, se le atraganta revisar mas de 10 lineas en un editor visual online donde puedes dejar comentarios... se le atraganta no cagarse encima a los muy subnormales del 99% de software del planeta.. que quieres?

tienes esta por ejemplo: https://github.com/google/git-appraise

a github y demas no le interesa que la gente sepa usar git ni usarlo bien: https://github.blog/2010-08-25-git-notes-display/ quieren que uses su web de mierda mal hecha y git-flow con muchas ramas, github actions y demas porquerias.

esto es lo que usa gerrit y en google, y creo que la gente en google estan contentos con su tooling de git la verdad.

1 1 respuesta

Lifecasi0 #54189 22 Mar

No se porqué os complicais tanto la vida, only master y rebase.

1 respuesta

desu #54190 22 Mar

#54189 https://git-send-email.io/

Lecherito #54191 22 Mar A toda leche

#54188 Gerrit es el peor cáncer de sida jamás visto, solo igualado por crear una rama por ticket.

Estar en master, rebases y las reviews por commits, no por branches es lo mejor que existe. Y al ser por commits, pueden ser commits de diferentes repos y hacer un push atómico en diferentes repos.

Pero el público general está encantado con la basura del git flow y sus 400 ramas que no sirven para nada

1 respuesta

desu #54192 22 Mar

#54191Lecherito:
Estar en master, rebases y las reviews por commits, no por branches es lo mejor que existe. Y al ser por commits, pueden ser commits de diferentes repos y hacer un push atómico en diferentes repos.

Tu puedes mergear a master un commit de cualquier rama, igual que puede ser de distinto repo. De hecho puedes mergear un diff/patch directamente que te he pasado por slack. Que mas da?

Lo que dices no tiene sentido.

#54191Lecherito:
Pero el público general está encantado con la basura del git flow y sus 400 ramas que no sirven para nada

Por aqui todos estamos hablando de ramas que solo van a contener 1 commit al final, porque harás squash, y vas a borrar la rama después de merge. La rama es necesaria para hacer pull/merge requests en las paginas habituales Github/Gitlab.

La única diferencia con pushear a master directo es que corres una etapa de CI previa en la PR y haces approvals.

No tiene sentido lo que has dicho, leetelo otra vez y veras, porque estas diciendo lo mismo que nosotros.

La única gente que se que tiene ramas o releases que hacen cherrypick al final, son gente que saca binarios periódicos como mobile o video juegos que requieren assets... Que lo hacen para saber que tienen varias cosas a la vez estables. Y para estos seguramente git no es la mejor herramienta.

1 respuesta

Lecherito #54193 22 Mar A toda leche

#54192 pues seré yo que no me explico bien. Pero he estado 5 años trabajando de esa manera y te digo que lo que hay públicamente es sidoso todo. Github, gitlab, bitbucker y toda la parafernalia de las ramas da asco.

Lo que me refiero es que si tienes la definición de la api y el cliente en dos repos diferentes, puedes hacer una review con los dos repos porque se usan los commits y no las ramas. No hace falta crear ramas para nada, siempre estas en master, es básicamente lo que dices tú de send email donde envías el commit pero con una herramienta bonita.

1 respuesta

desu #54194 22 Mar

#54193Lecherito:
Github, gitlab, bitbucker y toda la parafernalia de las ramas da asco.

Si en eso estamos de acuerdo.

#54193Lecherito:
Lo que me refiero es que si tienes la definición de la api y el cliente en dos repos diferentes, puedes hacer una review con los dos repos porque se usan los commits y no las ramas.

Vale, creo que tu estas hablando de realizar un cambio que afecte a multiples servicios, que estos tienen su propio repositorio. Ese seria el caso de uso no? Hacer un commit en múltiples repos? O estar trabajando en repo A y traerte un commit de repo B? No? Por ejemplo cambios que afectan a la api y al cliente.

Si para ello necesitas hacer diffs/patches como en el email. Que es lo mas flexible.

1 respuesta

Lecherito #54195 22 Mar A toda leche

#54194 hacer N commits en M repos es a lo que me refiero en una misma review

1 respuesta

desu #54196 22 Mar

#54195 HAHAHAH si si, eso para un fpero es magia negra, es imposible HAHAHA

en la practica, sincronizar los diffs con tu entorno de integracion y tener un lock al mergearlos para evitar otros merges hasta que todo el CI/CD termine.

el problema real ahi es la CI, el git con un lock en si mismo no tiene mucho secreto.

pero vamos, para la mayoria de equipos de desarrollo seguramente si se hiceise esa herramienta, seria mejor que github y gitlab.

necesitarias una cola FIFO de merge.

con github/gitlab y PRs, lo que deberias hacer es en tu entorno de DEV, tirar todo lo necesario con un tag para correr la CI. Y tendrias las review por separado, cada commit en cada rama. Necesitarias tener en tus checks de CI, un check en el entorno de DEV con ese tag para ver que nada esta roto distribuido. Mucho mareo eh?

GaN2 #54197 22 Mar Inocente

Es leeros y me alegro de tener cosas como estas con las que trabajar a diario:

https://www.reddit.com/r/programming/comments/18ae0gc/a_look_at_googles_internal_code_review_tool/

2 respuestas

laZAr0 #54198 22 Mar Cofarde

Si os hubieseis leído el libro de Git de Miguel Ángel Durán esto no os pasaría.

3

Slowbro #54199 22 Mar

#54197 Aprovecho para preguntarte:

Tanta diferencia hay entre bazel y blaze?

1 respuesta

GaN2 #54200 22 Mar Inocente

#54199 hasta donde se son lo mismo, creo que cualquier cambio en el repo interno que afecta a Blaze se copia directamente al repo de GitHub via Copybara. Lo mismo hay alguna parte muy específica que se quede solo para Google pero en teoría es lo mismo.

Yo Blaze lo he usado lo justo pero los SWEe con los que trato a diario están encantados

1

Lecherito #54201 22 Mar A toda leche

#54197 por casualidad has usado crux de Amazon? Luego le preguntaré a un ex de Google a ver que es mejor porque veo esa interfaz de critique y me da cosa al recordarme a gerrit

1 respuesta

Kaledros #54202 22 Mar

Diréis lo que queráis de Github, pero la mierda del Gerrit ni siquiera se actualiza en tiempo real con los cambios cuando pasan los checks, alguien te aprueba, etc. Que hay que ser MANDRIL.

GaN2 #54203 22 Mar Inocente

#54201 Nope, nunca he currado en Amazon. De Critique te puedo decir qeu aunque la interfaz no te guste a nivel de usabilidad y funciones es la polla en verso, tambien te digo que una herramienta es tan buena como la gente que lo usa. De nada te sirve tener la mejor herramienta de codigo si luego la gente no la usa, pone comentarios destructivos o no se sigue el workflow correcto.

1 respuesta

Lecherito #54204 22 Mar A toda leche

#54203 AJAJAJAJAJ a mi ahora me ponen solo nits en el código y me toca los cojones de una manera brutal

1 respuesta

GaN2 #54205 22 Mar Inocente

#54204 aquí los nits se usan raramente y no bloquean el CL para submit. Vamos que se los puedes pasar por el forro de los cojones si quieres

D10X #54206 24 Mar

Pensaba q ya lo habia visto todo cuando para la AAPP estuve en un proyecto donde dimitió la mitad del equipo (20 personas) en plena reunión diaria de la mañana.

Pero, tras un año trabajando en un proyecto de una entidad financiera lider a nivel mundial. Las cifras, en un proyecto de unas 12 personas:

2 devs y un arquitecto en baja por estrés, y han abandonado la compañía.
1 dev de excedencia perpetua.
4 analistas saltaron de empresa.
3 jefes de proyecto largados del proyecto (en busca del cuarto pero nadie quiere asumir).

Y me entere hace poco, q un compañero de otro proyecto le han dado incapacidad y no puede trabajar en IT por estrés.

Y yo aquí, ya con 20 años de experiencia, viendo como todo va explotando alrededor mío ... xD

3 3 respuestas

JuAn4k4 #54207 24 Mar

#54206 Pero que os hacen ? Porque para acabar así tiene que ser horrible. Di que hay gente que se toma en serio las presiones y demás mierdas. Yo recuerdo ya en mi primer trabajo, cuando dijeron que me quedara ahí hasta acabar el proyecto un Viernes les dije, mira yo me voy a la nieve a esquiar, a las 18 salgo por esa puerta, dime si quieres que vuelva el lunes a las 9 a trabajar o a las 12 a por el finiquito.

1 1 respuesta

D10X #54208 24 Mar

#54207 Tengo un perfil por el cual me meten a proyectos en llamas para intentar rescatar lo q se pueda, por eso suelo ver esas cosas.

Causas del estres? Variadas ... En muchos casos gente q no sabe trabajar en grupo (ya no hablo de equipo). Lo q implica q no saben delegar, y lo mas importante, ni reportar. Joder, si ves q tienes que hacer 10 cosas en un mes, llevas 1 semana y solo has terminado la primera ... Levanta la mano, porque no vas a llegar. Se busca mas gente, se te busca ayuda, gestionamos expectativas del cliente ... Lo q sea, pero claro si lo dices el dia de antes, pues ... Luego estos son los q mas se quejan de micromanagement.

Y por otro lado, los clientes, he trabajado con clientes q eran gloria bendita, amenazas, insultos, vejaciones por tener jornada reducida o poner en duda tu conocimiento técnico, pasivos agresivos, rastreros haciéndote la cama con otro proveedor, incluso altos cargos como putas cubas un miércoles por la mañana, etc ...

Al final, algunos no lo soportan (lógico), otros no estan dispuestos a aguantarlo y bajan al mismo nivel por lo q la relación profesional se va a la puta y si tu empresa te puede sustituir pues guay, si no, ya sabes dónde está la puerta.

Y muchas veces tienes q sortearlo por el contexto o situacion (si pierdes el contrato, os vais a la calle tú y 10 mas porque no queda otra, q es mucha pasta).

Ahí suelo entrar yo, todo bien atado, y a la mínima, sacar hemeroteca o plantear los riesgos de sus decisiones. Y sobre todo plantarte, q tu quieres esto el Sabado? Ya no te digo q yo no curro los findes, es q hacerlo el sabado por tus huevos, te supone A, B y C. Y se de sobra q no vas a tragar con eso, porque no puedes, asi q reculas, y me pones la cruz, y tu me odias, y yo lo se, y me la suda ... Y si mañana me largas de tu proyecto, se q tengo otro al dia siguiente, y si no lo tuviese, pues me voy a servir cafes ... Y vivo en plena paz interior, pero sin perder nunca la profesionalidad, q eso es lo jodido.

Q ojo, llegar a este punto de profesionalidad y paz interior me ha costado muchos años y casi me provoca un divorcio.

desu #54209 24 Mar

#54206 xq sois unos fperos

1 respuesta

B

[Borrado] #54210 24 Mar

git checkout -b lazyppl
<... bonita rama donde no jodo a nadie ...>
touch shit
git add -A
git commit -m "fuck"

<... mierda, que me he tirado 2 semanas con esta subnormalidad y necesito traerme cambios cojones! ...>
git pull --rebase origin main
<.. mierda hostia, alguien ha tocado lo mismo que yo... su puta madre ...>
git add -A
git rebase --continue

<... he terminado ya leches! ...>
git push origin lazyppl

[bucle]
<... No te revisa ni cristo durante semanas ...>
<... El PR queda desfasado, necesitas hacer rebase ...>
[fin bucle]

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales