¿Hay algún propósito para usar solicitudes de extracción en mi propio repositorio si soy el único desarrollador?

Así que comencé con un proyecto real mío en GitHub y las cosas van bastante bien y las ideas fluyen mucho más rápido de lo que inicialmente pensé. Para mantener las cosas organizadas, configuro algunas ramas para poder desarrollar diferentes características por separado.

Ahora, cuando empujo mi rama a GitHub, tengo esa sección donde tengo dos botones: Pull Requesty Comparecon el nombre de la rama a la que presioné recientemente. Entiendo el propósito del Comparebotón, pero no entiendo por qué querría crear una solicitud de extracción en mi propio repositorio.

¿Alguien puede explicarme por qué haría eso? ¿Es útil hacer una solicitud de extracción en mi propio repositorio si soy el único desarrollador?

Para muchos (quizás la mayoría) desarrolladores individuales que trabajan por su cuenta, probablemente no valga la pena crear solicitudes de extracción. Sin embargo, puedo pensar en al menos una razón potencial para hacerlo:

Las solicitudes de extracción se pueden utilizar para realizar un seguimiento del historial de su proyecto más fácilmente. Una solicitud de extracción tiene un ID de problema al que se puede hacer referencia desde los mensajes de confirmación y en un registro de cambios, que le permite regresar fácilmente y encontrar el punto de fusión y el conjunto de confirmaciones fusionadas para un cambio en particular, sin tener que retener su función ramas indefinidamente.

Por ejemplo, en Pioneer (conector descarado), cuando fusionamos una solicitud de extracción, agregamos un elemento al registro de cambios , con una descripción de una línea del cambio y una referencia al ID de la solicitud de extracción. Por supuesto, Pioneer tiene varios desarrolladores, pero el mismo mecanismo podría ser útil para un desarrollador que trabaje solo.

Esto puede ser menos útil si decide apegarse a un historial de confirmación lineal (al cambiar las ramas de sus características antes de fusionar, para que la fusión siempre se pueda realizar como un avance rápido), y si es muy disciplinado sobre la edición y el aplastamiento de su commit antes de fusionarse con master, porque en ese caso los mensajes de commit individuales se pueden usar como un registro de cambios en sí mismos.

Las solicitudes de extracción se crean para que alguien pueda revisar el trabajo, hacer comentarios, sugerencias, realizar o solicitar ediciones y luego combinar el código para dominarlo.

En tu caso el alguien eres tú.

Como desarrollador exclusivo, aún debe revisar su propio trabajo, refactorizarlo y fusionarlo para dominarlo cuando esté listo.

Un enfoque que uso mucho es tratar de 'ponerme otro sombrero', 'probar otras personas'. Así que siéntate un rato y colócate en la situación de: novato en el grupo; Desarrollador junior; colega que respetaste en el pasado, etc. Intenta mirarlo a través de sus ojos e intenta pensar simplemente qué podrías hacer para que el cambio sea más obvio, mejor escrito con nombres aún mejores que eviten el conocimiento tribal y de dominio tanto como sea posible .

Por lo tanto, como ha indicado, debe trabajar en ramas cuando desee separar las características y los cambios que no están listos para el maestro. Puede hacer todo eso en las sucursales (ni siquiera necesita solicitudes de extracción para administrarlas si realiza las tareas de relaciones públicas de todos modos, pero puede proporcionarle una estructura útil).

Además, a veces me doy cuenta de que mi cambio no está funcionando, pero en lugar del horror de intentar retrocederlo del maestro, tal vez ahora mezclado con otros cambios maestros, puedo hacerlo todo en una rama que luego puedo ignorar / eliminar si comienza a salir mal. Este es un gran beneficio.

Por lo tanto, debe trabajar en sucursales y no comprometerse directamente a dominar hasta que decida fusionar toda la sucursal.

Estas son pautas, y no reglas, a seguir. Intencionalmente los rompo a veces. Por ejemplo, ayer cometí un error tipográfico para masterizar.

Parece que tiene sucursales remotas, así como sucursales locales. Si encuentra demasiado la sobrecarga de ese flujo de trabajo, siempre puede trabajar en diferentes funciones utilizando sucursales locales sin presionarlas.

Básicamente se trata de hacer lo que funciona para ti. Trabajar con sucursales es un gran beneficio para git, y github lo hace realmente fácil, pero como desarrollador solitario no hay una gran necesidad de usar el modelo de solicitud de extracción y comprometerse directamente con el maestro debería funcionar bien. Cuando su proyecto finalmente sea increíblemente exitoso y decenas o cientos de desarrolladores estén trabajando en él, encontrará que recibir solicitudes de extracción de sus tenedores es una excelente manera de realizar un seguimiento del proyecto.

Las solicitudes de extracción generalmente se usarían para revisiones de código o contribuciones de los usuarios con su propia bifurcación del proyecto; para un solo desarrollador en un proyecto, realmente no veo un propósito.

La razón por la que lo hago es que es una manera conveniente de asegurarse de que todas las verificaciones automáticas pasen (se compila, tiene el formato correcto, las pruebas unitarias pasan ...).

No necesito necesariamente que se pasen todas las verificaciones para cada confirmación, pero sí quiero que el jefe de la rama principal siempre pase las verificaciones. Creo que las solicitudes de extracción son la forma fácil (quizás no la única).

De manera más general, es una forma de conectar ganchos para completar los cambios. Las pruebas son un ejemplo; @John mencionó la creación de notas de lanzamiento como otro ejemplo.

Las solicitudes de extracción frente a git push finalmente se reducen a una historia individual o compartida. El repositorio principal es la fuente de todos los cambios, si otros están retirando y potencialmente haciendo cambios locales, entonces una solicitud de inserción puede causar problemas a esos usuarios como el árbol que derivan de los cambios.

El modelo de solicitud de extracción (ya sea de sucursales personalizadas o repositorios personales) sirve como una forma de proporcionar un historial consistente para todos aquellos que usan y derivan del código.

Parte de la razón por la que está poniendo código en github sería hacer que el código esté disponible para bifurcación y extraer solicitudes. Nunca supiste cuándo sucederá, y mantener constantes tus historias de co-desarrolladores sería una gran ventaja.