Práctica de pull requests
TL;DR: ¡Ya puedes practicar cómo crear pull requests en GitByBit!
¿Alguna vez has encontrado un bug en el código de otra persona y has pensado: "¿por qué no han arreglado esto todavía?" Abres un issue, esperas... y no pasa nada.
La cosa es que ya no tienes por qué esperar.
Puedes arremangarte y aportar tú la corrección. Envías una pull request, consigues que se fusione y, de repente, toda la gente que usa esa librería se beneficia de tu trabajo.
Nunca sabes qué puedes sacar de una pull request.
Un bug real, una corrección real
La práctica empieza con una situación muy reconocible: tu app de seguimiento deportivo falla cuando alguien intenta registrar su actividad en un campo de golf usando distancias en yardas. La app no sabe convertir yardas a metros y se rompe. La corrección es sencilla: añadir la conversión que falta (1 yarda = 0,9144 metros). Parcheas la librería y sigues con tu día.
Pero, al cabo de un tiempo, llega una actualización que rompe tu corrección. Tienes que volver a aplicar el parche. Luego vuelve a pasar. Y otra vez. Te das cuenta de que estás perdiendo el tiempo parcheando sin sentido, cuando la corrección debería estar en la propia librería. ¿Cómo la metes ahí?
La todopoderosa pull request
La mayoría de proyectos de código abierto están alojados en GitHub o plataformas parecidas, y todos permiten usar pull requests. Una pull request (PR) es una solicitud para incorporar cambios a un proyecto. Haces un fork del repositorio, aplicas tus cambios y luego envías una pull request al repositorio original, proponiendo que tus cambios se fusionen en la base de código principal.
Además de la parte técnica de hacer forks, trabajar con ramas y fusionar cambios, el proceso de una pull request también va de comunicación. Tienes que explicar qué has hecho, por qué hace falta y cómo mejora el proyecto. Ahí puedes demostrar que entiendes la base de código y que sabes contribuir con criterio. No sirve de mucho destrozar una pull request con mensajes de commit cutres, subir un montón de cambios sin relación o no seguir las guías de contribución del proyecto.
Esta actitud en los comentarios de una pull request no te lleva a ninguna parte.
Además, las idas y venidas de una pull request pueden obligarte a actualizar tu fork, hacer rebase y resolver conflictos. El proceso implica todo un paquete de habilidades de Git, y ahora puedes practicarlas todas con GitByBit en un escenario realista con repositorios reales de GitHub.
Bordar una pull request exige mucha paciencia y atención al detalle.
Además de la práctica de pull requests, he añadido varias entradas nuevas a Gitopedia, incluidas y . También hay dos buenas prácticas nuevas: y .
