tab - git tag commits

¿Cuál es el flujo de trabajo para contribuir a un proyecto de código abierto utilizando las solicitudes de extracción de git?(por ejemplo, a través de Github)

Question

Tengo una descripción exhaustiva paso a paso sobre cómo hago esto y quería compartirla aquí para que los desarrolladores puedan beneficiarse de ella (responderé a mi propia pregunta).

Answer 1

Dado que los cambios contribuidos a proyectos de código abierto tendrán que ser revisados ​​por expertos, es común ver un flujo de trabajo que se basa en las solicitudes de extracción de git. Las solicitudes de extracción no están permitidas desde los repositorios clonados directamente (usted necesita su propio fork). Así que estos son los pasos que sigo para mantener un tenedor saludable y contribuir periódicamente a un código abierto:

Nota: los pasos 1, 2 y 3 solo se realizan una vez en una sola máquina de desarrollo para configurar todo:

1) Asegúrese de que está trabajando localmente en su "bifurcación" del proyecto en lugar de en un repositorio clonado que apunta al proyecto como origen. Para obtener un proyecto de Github, vaya a https://github.com/entity/project , haga clic en "Fork" y elija una cuenta de GitHub adecuada para el fork, por ejemplo. tu cuenta personal de Github Tenga en cuenta que el "origen" de su proyecto bifurcado ya no será el repositorio del proyecto original, sino su propio bifurcación en Github. Tenga cuidado con la privacidad si está vendiendo un proyecto privado, ya que probablemente no quiera que su fork sea pública.

2) Clone su propia bifurcación de proyecto en su máquina de desarrollo y cd en ese directorio.

git clone [email protected]:yourgithubuser/project.git

3) Agregue el repositorio original del proyecto como repositorio ascendente en su proyecto bifurcado.

git remote add upstream [email protected]:entity/project.git

El repositorio original del proyecto principal es ahora "upstream" pero no "origin"

Y ahora viene el ciclo de trabajo que repetirá cuando trabaje con su proyecto bifurcado:

4) Antes de comenzar su trabajo, siempre asegúrese de que la rama maestra de su repositorio bifurcado esté sincronizada con la rama maestra del proyecto original:

git checkout master
git fetch upstream
git merge upstream/master
git push origin master

5) Cree una nueva rama en la bifurcación de su proyecto para los arreglos específicos que desea aportar (nombre después de una corrección de errores, un problema de seguimiento, una sección de documentación, etc.) y cambie a ella.

git checkout -b myfixes

Esto crea automáticamente la rama y cambia a ella. Asegúrese de que la rama no existe ya . También es posible que desee deshacerse de sus sucursales de arreglos anteriores que ya se han fusionado en los documentos (de lo contrario, tendrá un montón de sucursales inútiles en su proyecto). Puede echar un vistazo a sus sucursales locales emitiendo una git branch y si en esa lista encuentra una sucursal que ya se ha fusionado con el proyecto anterior, puede hacer lo siguiente:

git branch -D myoldfixes
git push origin --delete myoldfixes

Nota importante : si ya estaba trabajando en una sucursal en una máquina diferente y desea continuar ese trabajo en una máquina nueva, debe rehacer los pasos 2, 3 y 4 en la máquina nueva y en el paso 5 en lugar de hacer git checkout -b myfixes debes hacer git checkout myfixes (elimina la -b). De lo contrario, puede terminar con un estado de "cabeza separada" que no es bueno (una especie de sucursal anónima)

6) Trabaje en esa rama (por ejemplo, myfixes) y confirme sus cambios:

git commit -a -m "My fixes"

(De manera alternativa, puede crear archivos específicos y ejecutar sin usar -a. Puede realizar tantas veces como desee, pero no deje cambios sin compromiso en la rama)

7) Mientras trabajaba en sus arreglos, el repositorio original del proyecto ascendente podría haber cambiado (debido a otros colaboradores que trabajan en él). Por lo tanto, primero tendrá que volver a ajustar su rama actual (myfixes) desde la rama de destino en sentido ascendente. En otras palabras, debe volver a reproducir sus arreglos en la parte superior del trabajo más reciente de la rama maestra de repositorio ascendente para asegurarse de que sus confirmaciones siguen siendo compatibles con las últimas confirmaciones en sentido ascendente. Esto dará como resultado una combinación de avance rápido para la solicitud de extracción que es lo que queremos:

git checkout myfixes
git pull --rebase upstream master

Nota : esto puede dar lugar a conflictos, pero esto es normal, corregirlos es parte del proceso (esto sucede con más frecuencia en proyectos muy activos)

8) Después de corregir los conflictos (si los hay) del paso anterior, ha aplicado sus arreglos sobre la última versión del maestro ascendente. Dado que las solicitudes de extracción se inician desde su repositorio bifurcado en Github, también desea mantenerlo sincronizado:

git checkout myfixes
git push origin myfixes -f

9) Finalmente, puede ir a Github https://github.com/entity/project (el proyecto original no es su fork) y hacer clic en "Solicitar solicitud". Asegúrese de elegir "maestro" del repositorio en sentido ascendente como la rama de destino y su "bifurcación" del repositorio bifurcado como la rama de origen (la rama se eliminará automáticamente después de que se acepte la solicitud de extracción)

¡Disfrutar!

Answer 2

6a) El tema de la confirmación y el formato del mensaje de confirmación también son críticos.

Cometer tema

El tema de compromiso debe cubrir solo un cambio lógico. Por ejemplo, si tuviera que describir los cambios a alguien (por ejemplo, en un mensaje de confirmación, vea más abajo) no debería poder usar la palabra "y" para describir el tema, ej. no "Arreglar el error 123 y actualizar la configuración por defecto". Estos deben ser dos compromisos separados.

Si tiene un montón de problemas separados resueltos pero no comprometidos en su árbol de trabajo, una gran herramienta es el complemento interactivo. Haga que sus dedos recuerden este lote de comandos, luego siga las instrucciones:

git add -i
5<CR>
*<CR>

Puede ser más sofisticado con las otras opciones, pero eso dice "muéstrame cada cambio en mi árbol de trabajo y déjame elegir qué escenario".

Entonces, como de costumbre:

git ci

Cometer mensaje

Desea ser conciso y preciso en el título para las personas que analizan la historia, al mismo tiempo que proporciona buenos detalles en el cuerpo para las personas en el futuro (¡incluyéndolo a usted en seis meses!) Investigando un problema que involucra su cambio.

Mi guía favorita para escribir buenos mensajes de confirmación es la página wiki de Erlang / OTP sobre buenos mensajes de confirmación , y a eso agregaré que no puedes equivocarte con el siguiente formato:

Short (<50 chars) present-tense summary of changes
Previously, <a couple sentences clearly describing the previous behavior
and the resulting customer issue>.
This commit <a sentence or two clearly describing the code change, and the
resulting expected behavior>.