No recuerdo cuantos han sido los lugares entre mis consultorias, creo que 4 o 5, donde esta frase del infierno ha surgido ‘Merge pull’, curiosamente siempre significa algo diferente.
Antes de contar la historia de terror. Voy a definir que es un Merge, y un Pull.
En Git, para trabajar con personas de forma remota, es decir conectar dos computadores via ssh, mediante IPs publicos. Se usan dos terminos.
Merge: Permite mezclar dos ramas. git merge nombre_rama, aplicada sobre la rama donde estamos posicionados actualmente. Evaluamos ambas versiones y crea una confirmacion (commit) con los cambios que decidimos.
Pull: Traer de una fuente remota, los commits de una o mas ramas.
¿Por que digo una fuente remota y no un repositorio? Bien Gen Z que estas leyendo. Git existe antes de Github, Github es quien introdujo los terminos de repositorios en un host centralizado, donde cada quien por USUARIO es capaz de crear sus copias todo en internet.
Git fue hecho para usuarios por dispositivo. Y la idea es cualquiera en cualquie lugar. Y trae un comando para compartir tus cambios con el publicador original. Si es el proyecto de linux, hay forma de pedirle a Linus Torwalds un pull.
El proceso es simple, enviar un correo a la lista de distribucion, compartiendo tu IP publica o Host, con un clon del repositorio de linux y el nombre de tu rama.
¿Y como generas esos cambios? Pues con git request-pull
Un ejemplo de esto seria:
git request-pull https://10.0.0.0/repository.git main branchEsto va a generar un texto, que indica para tu host / upstream, las diferencias de main a branch. Este lo copias y lo pegas lo envias por correo.
¿Pero esto es bien diferente de un Pull Request, o un Merge Request? Si es cierto, Pull request es un termino creado por Github, dentro de la UI de Github y su propio flujo, que hace esto mismo de forma elegante. Puedes solicitar desde el mismo proyecto o desde un Fork, por la interfaz de Github, que el dueño de un repositorio mediante Github aplique un Pull y automaticamente un Merge siendo asi tus cambios integrados. Y el Merge Request es la version de Gitlab pero sobre el conocimiento generado por Github donde estas solicitando Merge de tus cambios a una rama.
¿Y qué rayos es un Merge Pull?
Pues bien, Bitbucket y Github como mensajes automaticos escriben algo como
‘Merge pull request named abcd from branch to master: with changes’
Muy similar al comando que genera git request-pull.
Ven las primeras dos palabras ‘Merge pull’. Eso es, un mensaje mal recortado dentro de un commit automatico.
Entre las versiones que he tenido que sufrir un ‘Merge pull’ ha sido
- El commit que define una integracion. Si no dice este mensaje es rechazado.
- La logica detras de esto. Es que quienes evaluaban se acostumbraro a hacer todo por la UI. Con el tiempo se dieron cuenta que siempre decia ‘Merge Pull’ lo pegaron en un manual de capacitacion y vuala.
- La precondicion de pases a produccion. Donde se indica que antes de unir cualquier rama “develop/” a “master” para los flujos automatizados de despliegue. Debe decir esta palabra exacta desde una rama “feature”
- La validacion de calidad en master. El evaluador sistema evaluador que disparaba las reversiones. Si un commit no tenia el mensaje por defecto de bitbucket, revertia el pase.
En general son conceptualmente el mismo horror, usar el mensaje de commit (nisiquiera el tipo de commit, por ejemplo un commit de tipo merge) como punto de validación de calidad del proceso. En retrospectiva en menos malo es el primero, aunque en su momento me causo mi dosis de gastritis.
Eso quiere decir que alguien con suficientes privilegios, y que entendiese esas cosas no documentadas, (solo documentadas en el codigo de los scripts pero sin documentacion humana) podia hacer suficiente daño en las historias o en los workloads de despliegue.
¿Parece tonto no? A falta de conocimiento y controles practicos, se crean reglas inpracticas e insostenibles. Varios años han pasado desde que me tope con esos procesos, me pregunto si seguiran asi o alguien los reparo.
Por ello, es muy importante conocer los fundamenos y las razones de ser, de las herramientas y procesos. Y mi material educativo de git tendra esos principios.