¿Puedo crear una request de extracción usando la misma twig que la base y comparar la twig?

Tengo un repository github que tiene maestro y una twig. Hemos estado desarrollando en una sucursal y cada vez que lanzamos un lanzamiento, fusionamos los cambios de la sucursal en master y luego comenzamos la siguiente fase de desarrollo en branch nuevamente. Ahora, se nos pide que usemos la request de extracción para corregir errores en la twig. Entonces la pregunta es, ¿cómo hacer toda la request de extracción solo en la twig, sin involucrar al maestro?

Más específicamente, tengo branchA que tiene un cambio de corrección de errores, luego confirmo y envío al repository de branchA, luego voy a mi página web github repo y trato de hacer una request de extracción especificando tanto la twig base como la twig comparar como 'branchA ', entonces github dice: No hay nada para comparar. Tendrá que usar dos nombres de twigs diferentes para get una comparación válida . Esto definitivamente tiene sentido, así que estoy preguntando si es posible comparar de alguna manera la MISMA twig antes y después de la corrección de errores a través de una request de extracción.

Las frases "hacer toda la request de extracción solo en la twig" y "no involucrar al máster" realmente no tienen sentido, porque una request de extracción es básicamente un set de cambios que se solicita fusionar en una twig, que en su caso sería la twig master .

Aquí hay una descripción de la página de GitHub sobre requestes de extracción :

Las requestes de extracción le permiten informar a otros acerca de los cambios que ha enviado a un repository en GitHub. Una vez que se abre una request de extracción, puede analizar y analizar los posibles cambios con los queueboradores y agregar confirmaciones de seguimiento antes de que los cambios se fusionen en el repository .

Después de inicializar una request de extracción, verá una página de revisión que muestra una descripción general de alto nivel de los cambios entre su twig (la twig de comparación) y la twig base del repository.

Además, crear una request de extracción requerirá que especifique la twig en la que desea fusionar los cambios, que en su caso sería la twig master .

Si tiene la intención de no involucrar nunca a la twig master , puede crear un parche para las confirmaciones relacionadas con las correcciones de errores, luego realice la revisión del código allí. (También puede crear un parche difiriendo los files modificados). Pero eso hará que la revisión del código sea más difícil.

Las requestes de extracción son simplemente decirle a github que quiero que esta sucursal tome este compromiso solo después de haber sido revisado y aprobado.

Al realizar una request de extracción, implica dos twigs 1. La twig de comparación (La que está presionando) 2. La twig de base (La que revisa los cambios después de la aprobación)

La twig base suele ser maestra, pero no se limita a la maestra.

Simplemente cámbialo a la twig en la que deseas fusionar el PR y ¡listo!

¡Las requestes de extracción no están pensadas solo para el maestro!

Si el PR se emitirá desde el mismo repo de github, entonces tiene que hacerse a través de una bifurcación, es decir, crear una twig fuera de una twig conocida y hacer cambios, luego crear PR comparando las dos twigs. Gracias a todos los que ayudaron a confirmar esto.

Si alguien hace una bifurcación de un repo github, entonces los cambios en el repo bifurcado se pueden usar para emitir PR basándose aparentemente en la misma bifurcación (en dos repositorys diferentes, es decir, uno original y el otro el tenedor). Aquí es donde estaba confundido porque vi que el PR venía de aparentemente la misma twig, pero en realidad, es de un repository (un tenedor) diferente, técnicamente.

Como mencionaste, hiciste tu desarrollo en una twig (tema) y luego la fusionaste en principal. Idealmente, este también es un tema para usar la request de extracción (PR).

Piense en PR como una request para fusionar branchA (topi / development / bugfix) con branchB (master). ¿Por qué no fusionarse directamente como lo hizo antes? Permitir que otros desarrolladores revisen el código antes de fusionarlo en branchehs estables o utilizar serveres CI / CD.