¿Enviar el parche al proyecto de Github sin clonar el depósito en Github?

Question

Tengo un repositorio local que es una copia completa de un repositorio en Github. Hice un cambio que me gustaría contribuir al proyecto original.

¿Cómo puedo hacer esto sin volver a cargar mi proyecto en Github? No creo que la apertura de un problema es la forma correcta ..

que vi en How can I contribute a patch to github? que yo debería tenedor del proyecto, pero desde mi repositorio local está "ligado" al repositorio de Github originales, no hacer quiero estropearlo

Por lo tanto, si es realmente desaconsejado compartir el parche de cualquier manera que no sea fork, ¿cómo puedo simplemente mover el proyecto original, fusionar mis cambios y luego compartirlos con el repositorio original?

Si borro el tenedor después de haber "confirmado" el cambio pero aún no se acepta, ¿mi confirmación desaparece?

Answer 1

Debe bifurcar el proyecto, sí. Sin embargo, esto no significa que deba volver a clonar toda la información localmente.

Explicación: una forma simple de ver un repositorio de git es un gráfico de confirmaciones (es directo y acíclico, pero eso es irrelevante para esta discusión); y todos los nodos de este gráfico, es decir, los commits, tienen un identificador único en todos los repositorios de git en el mundo. En cuanto a las ramas, son solo referencias simbólicas a una confirmación (en el lenguaje git, una rama - o una etiqueta - se llama refspec).

Además, usted es nunca vinculado a un repositorio remoto de ninguna manera. Lo único que realmente está "vinculado" es el gráfico de confirmación. Un repositorio remoto simplemente tiene un conjunto de refspecs (ramas, etiquetas) ... que apuntan a un gráfico de compromiso, que también tienen: a nadie le gusta las referencias colgantes. Cuando clonas un repositorio, obtienes el gráfico de compromiso (y los árboles asociados) y el conjunto de refspecs (es decir, ramas, etiquetas). Un refspec apunta a un árbol. Y eso es todo.

Esto significa lo siguiente:

• que tiene el repositorio GitHub originales: un gráfico de confirmaciones y árboles asociados, un conjunto de refspecs;
• lo ha clonado localmente: el mismo gráfico de confirmaciones y árboles asociados, el mismo conjunto de referencias;
• ha asignado material localmente: ha agregado este gráfico y los árboles asociados, y ha agregado un nuevo conjunto de réplicas.

bien, ahora lo siguiente:

• clon del repositorio original en github: el mismo gráfico de confirmaciones y árboles como el original; las refspecs están aquí, solo precedidas con el nombre remoto, que es origin de forma predeterminada. ¿Y ahora qué?
• en su repositorio local, añadir su tenedor como un control remoto;
• empuje hacia esa horquilla (esto empujará las refspecs y los árboles);
• envíe una solicitud de extracción.

Agregando su tenedor como un control remoto es tan "simple" como:

git remote add myfork git@github.com:youruser/theproject 

empujar su refspec (rama) a la misma:

git push myfork mybranch 

y luego presentar una solicitud de extracción a la autor original

Cabe señalar que, en teoría, puede agregar un control remoto para un repositorio Git que no tiene relevancia en absoluto con el repositorio "original": esto es, simplemente, que los dos se comprometen gráficos serán completamente inconexos entre sí - Sin embargo, los casos de uso para esto son raros

Answer 2

Siempre puede enviar un archivo de parche al responsable por correo electrónico. El kernel de Linux se ha diseñado de esa manera durante mucho tiempo.

Answer 3

Sí, debe duplicar el proyecto, pero no es necesario clonar/arrastrar/fusionar nada. Después de hacer clic en el botón tenedor, hacer

git remote add yourfork git@github.com:<yourname>/<project>.git 

y empujar a su sucursal a su tenedor con

git push yourfork branchname 

luego emitir una solicitud de extracción.

Si elimina la horquilla después de el parche se combina con el flujo ascendente, no debería haber ningún problema. No estoy seguro de qué sucede cuando quitas tu tenedor antes de que eso suceda.

No hay necesidad de fusionar nada.

Answer 4

Sin tocar el violín con su copia actual del repositorio.

• Crea los parches con format-patch.
• Tenedor aguas arriba y lo clona, ​​pero no reemplace su copia de trabajo.
• aplicar los parches con git am al proyecto de nueva forma de horquilla, empuje y crear la petición de fusión.

Esta no es la mejor solución, pero evita que pierda accidentalmente los cambios.