- El objetivo es crear la herramienta de colaboración para git más simple posible
- Hacer que ejecutar un servidor git autoalojado sea tan sencillo como ejecutar un servidor SSH, sin sacrificar el tiempo ni la energía de los colaboradores externos
- Combina listas de correo y el flujo de trabajo de pull request
- Busca crear una herramienta de colaboración tan simple como generar parches, pero con la facilidad de uso de los pull request
- No busca crear otro repositorio de código, sino una solución git autoalojada muy simple para colaborar con contribuidores externos
Qué se necesita
- Lo que necesita el propietario del código para ejecutar un servidor git:
- Un único binario de golang
- Lo que necesita un contribuidor externo:
- Un par de claves SSH
- Un cliente SSH
Problemas actuales
- El correo electrónico es excelente como sistema distribuido para enviar y recibir cambios a un repositorio git (conjuntos de parches), pero incorporar nuevos usuarios a una lista de correo, configurar correctamente el cliente de correo y luego enviar una contribución de código hace que muchos desarrolladores se rindan
- Como la colaboración aprovecha el protocolo de correo electrónico, hay limitaciones en el conjunto de funciones. Por ejemplo, no se pueden editar correos, cada persona usa un cliente distinto y esos clientes tienen diferentes limitaciones respecto a correos en texto plano y descarga de parches
- Los pull request de Github son fáciles de usar, editar y gestionar, pero tienen la desventaja de que el usuario debe estar dentro del sitio web de Github para hacer revisión de código
- Eso está bien para cambios rápidos, pero una vez que empiezas a leer código dentro del navegador web aparecen desventajas importantes. Llega un punto en que tiene más sentido revisar el código en un entorno de desarrollo local o en un IDE
- Existen herramientas y plugins para revisar PR dentro del IDE, pero hacerlos utilizables requiere muchísimo esfuerzo
- Además, las soluciones autoalojadas que imitan los pull request requieren mucha infraestructura para administrarlas: bases de datos, un sitio web conectado a git, gestión administrativa, servicios, etc.
- Otro gran punto de fricción es que los usuarios externos primero tienen que crear una cuenta e iniciar sesión antes de poder enviar cambios de código. Esto añade bastante fricción, tanto para contribuidores externos como para los propietarios del código, que además deben aprovisionar infraestructura
- A menudo también hay que hacer un fork del repositorio antes de enviar un PR. Luego muchas veces no se vuelve a contribuir nunca más y ese repositorio bifurcado queda ahí para siempre. Eso parece absurdo
Introducción a Patch Request (PR)
- Busca crear un "servidor" git autoalojado que permita enviar y recibir parches sin la molestia de configurar correo electrónico ni las limitaciones impuestas por ese protocolo
- También quiere que el flujo de trabajo principal gire en torno al entorno de desarrollo local. Github está llevando el IDE al navegador para apoyar ese flujo, pero aquí quieren darle la vuelta a esa idea y convertir la revisión de código dentro del entorno local en una experiencia de primera clase
- Lo ven como un punto intermedio entre el flujo de trabajo de pull request de Github y el envío/recepción de parches por correo electrónico
- La idea central es usar una app SSH para manejar la mayoría de las interacciones entre contribuidores y propietarios del proyecto. Todo puede hacerse desde la terminal de forma ergonómica y completa
- Las notificaciones se hacen por RSS y todos los cambios de estado generan activos web estáticos, de modo que todo puede alojarse usando un servidor web simple de archivos
Flujo de trabajo de format-patch
- Aquí la herramienta básica de colaboración es format-patch
- Tanto si se envían cambios de código como si se revisan, todo ocurre en el código
- Tanto los contribuidores como los propietarios crean nuevos commits y generan parches unos sobre otros
- Esto elimina la necesidad de tener un visor web donde el revisor pueda dejar un "comentario" en una línea de un bloque de código. No hace falta. Basta con aplicar el parche del contribuidor, escribir comentarios o cambios en el código, generar un nuevo parche y enviar ese parche como "review" al servidor git
- Este flujo funciona exactamente igual incluso si dos usuarios colaboran sobre una serie de cambios
- También resuelve el problema de enviar varios conjuntos de parches para el mismo cambio de código. Hay un único Patch Request central donde ocurren todos los cambios y la colaboración
- Se podría buscar una forma de aprovechar git note para habilitar reviews/comentarios, pero sinceramente esa solución se siente brutal y fuera del nivel de comodidad de la mayoría de usuarios de git
- Basta con enviar la revisión como código y escribir anotaciones en el código usando el lenguaje de programación que se esté utilizando
- Procesar esas anotaciones y eliminarlas en parches posteriores es tarea del contribuidor
- Función obligatoria para atender todos los comentarios: si hay anotaciones sin resolver en el código, el parche no se fusiona. No se pueden ignorar, porque si no terminarían subiendo por error
Cómo funciona Patch Request
- Patch Request (PR) es la forma más simple de enviar, revisar y aceptar cambios en un repositorio git. Funciona así:
- Un contribuidor externo clona el repositorio (
git-clone)
- Un contribuidor externo hace cambios en el código (
git-add & git-commit)
- Un contribuidor externo genera un parche (
git-format-patch)
- Un contribuidor externo envía el PR al servidor SSH
- El propietario recibe una notificación RSS de un nuevo PR
- El propietario aplica localmente el parche desde el servidor SSH (
git-am)
- El propietario escribe sugerencias en el código (
git-add & git-commit)
- El propietario envía la revisión canalizando el parche al servidor SSH (
git-format-patch)
- El contribuidor externo recibe una notificación RSS sobre la revisión del PR
- El contribuidor externo vuelve a aplicar el parche (
git-am)
- El contribuidor externo revisa y elimina las anotaciones del código
- El contribuidor externo envía otro parche (
git-format-patch)
- El propietario aplica localmente el parche (
git-am)
- El propietario marca el PR como aprobado y hace push del código a
main (git-push)
1 comentarios
Parece que es una incorporación nueva a Pico.sh - una colección de software de código abierto para gestionar servicios web usando SSH para todo.
Antes ya incluía cosas como las siguientes.