Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev


Leos

En mi primer curro el senior/cto ponía lo mismo en todos los commits que era some stuff y al final todo los proyectos solo tenían ese mensaje xD

1 1 respuesta
eondev

#14847 nada como u buen puchero un día de domingo. Pizza, putos urbanitas milenials xddddddddddddd

#14851 Es la ostia, cuando ves todos esos pequeños detalles en el que según creías debería ser la referencia de la empresa te planteas muchas cosas xD.

1 2 respuestas
Lecherito

#14852 Urbanitas milenials cuando vivo en un pueblo con una unica pizzeria, y suerte es que abre los domingos por la mediodia, que de normal es solo por la noche. Las habichuelas con chorizo en puchero fueron ayer, no te preocupes.

2 1 respuesta
eondev

#14853 vale, entonces tienes mis respetos

desu

En mis proyectos personales:

En el trabajo solo:
https://www.conventionalcommits.org/en/v1.0.0/
Sobretodo hago feature/refactor/fix y uso ! cuando hay un breaking. Cuando estoy solo.

Si trabajo con un equipo:
Pull request y hago commit squash por PR.
Issue = PR.
Issues lo mas peque;as posibles para que se vea facil lo que se ha cambiado.

PS: No entiendo que haceis posteando en este hilo si no estais trabajando. A no ser que trabajeis en findes... ay lmaoooooooooo

Leos

#14852 y mas cuándo es tu primer trabajo que te distorsiona mucho el como deberías hacer las cosas xD

1
isvidal

Con la prespectiva me doy cuenta de la subnormalidades que han pedido historicamente en git, imposible de aprender bien. En el curro inicial que el nombre del commit fuera el dia/mes/a;o ?? la fecha ya te la trae el puto commit pa que lo quieres como texto?? Y esto peticion de gente con los huevos pelados y se supone senior. Luego en otro curro, por cada tiquet, crear una rama con el id del tiquet y luego hacer merge, si, por cada tiquet, una puta rama, aun siendo "Cambia el label de ok por entendido", rama nueva, toma ya.

Luego Eisen que como es que no sabemos git.

2 respuestas
KazuluDev
#14857isvidal:

por cada tiquet, crear una rama con el id del tiquet y luego hacer merge, si, por cada tiquet, una puta rama

Si cada ticket es independiente de los demás no entiendo porque no hacer una rama para cada uno.

1 1 respuesta
isvidal

#14858 Simplemente porque me parece una perdida de tiempo sin que aporte nada de valor en el 90% de los casos.

1 respuesta
KazuluDev

#14859 bajo mi punto de vista aportan valor si se hacen review de las PR, por pequeño que sea el cambio

a eso le incluyo pasar test sobre las PR y obligatorio review para mergear

1 respuesta
Kaledros
#14857isvidal:

por cada tiquet, una puta rama, aun siendo "Cambia el label de ok por entendido

¿Qué harías en este caso? ¿Cambiarlo directamente en develop?

Lecherito

Pues yo digo que hacer una rama para una mierda de pull request es perder el tiempo. Las pull request deberian poder hacerse sobre cambios no solo sobre ramas, change my mind.

isvidal

#14860 Presupones que hay PR y review. Si no lo hay, no cumple ninguna funcionalidad, solo marear la perdiz, luego tienes que volver a master por X, no recuerdas el puto id del tiquet, tienes 100 ramas en local con distintas id... Ve a jira a por el tiquet para mirar como se llamaba la puta rama, perdida de tiempo total y absoluta.

Yo lo que haria es plantar un GERRIT en el medio, de tal forma que puedes tirar commits tranquilamente a """master""" (Realmente no tiras a master), de tal forma que tienes un flujo de trabajo comodo, git add ., git commit, git push refs/master y donde el resto de gente puede ver facilmente que mierdas has hecho en el commit, sea grande mediano o gigante.

Edit: He ido a googlear a ver como volver a la rama anterior y parece que existe esta cosa tan bonita: git checkout - , gracias a una discusion futil en MV he aprendido un poco mas de git hoy.

1 2 respuestas
vago_21

donde esté un buen ftp que se quite la mierda esa de git y sus putos conflictos

KazuluDev

#14863 presupongo que hay PR y review porque sinceramente no concibo que salgan las cosas bien a la larga de otra manera.

2 2 respuestas
eondev

#14863 el - es un must para varios comandos en linux xD
#14865 joder el junior lleva medio mes y ya maneja más que la mayoría

2 respuestas
isvidal

#14865 Por mi experiencia PR y review son la exepcion en empresas de Espa;ita, no la norma.

1 respuesta
Lecherito

#14866 Imagina llevar a;os sin hacer cd - xdddd, o pushd/popd en su defecto

1 1 respuesta
isvidal

#14868 Mi cerebro nunca vinculo el - de linux con usarlo para irte una rama atras en git. Llamame loco.

KazuluDev

#14866 #14867 Si lo sé... Por eso las cosas salen como salen. En mi empresa PR y review es la norma desde que llegué yo.

Fyn4r

Me gustaría unirme al apaleamiento pero esta última semana todos mis commits han sido "fix model"

1 respuesta
MisKo

#14871 Pero es que hay algunos commits cuya descripción es más grande que el cambio. Yo tb hay veces que pongo algo tipo "Fix ..." y pista xD

isvidal

Acabo de pasarme 30 minutos picando una query y al terminarla me he dado cuenta de que puedo descartar con un where directo si es null en una columna. Nice.

JuAn4k4

PR, review, CI con tests unitarios y de integracion y CD al mergear, con sus tests e2e.

4 respuestas
KazuluDev

#14874 ahora toca aprender a hacerlo bien y que los test testeen realmente lo que se pretende

Naith

#14874 que paja más tonta.

isvidal

#14874 Me falta el final feliz a cargo de la peluqueria china mas cercana, el resto 10/10

Ranthas

Masillas masilleando

desu

Cuando abro este hilo me salta el traductor de google preguntandome si quiero traducier del hindi al espa;ol.

> 2020
> Ramas en git aparte de master
> "gitflow"

ayy

2 respuestas
aren-pulid0

#14874 eso es lo que estoy intentando implantar en mi empresa 😁

1 respuesta

Usuarios habituales

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