Chapters ā–¾ 2nd Edition

5.2 Git en entornos distribuidos - Contribuyendo a un Proyecto

Contribuyendo a un Proyecto

La principal dificultad con la descripciĆ³n de cĆ³mo contribuir a un proyecto es que hay una gran cantidad de variaciones sobre cĆ³mo se hace. Debido a que Git es muy flexible, las personas pueden trabajar juntas de muchas maneras, y es problemĆ”tico describir cĆ³mo deberĆ­an contribuir: cada proyecto es un poco diferente. Algunas de las variables involucradas son conteo de contribuyentes activos, flujo de trabajo elegido, acceso de confirmaciĆ³n y posiblemente el mĆ©todo de contribuciĆ³n externa.

La primera variable es el conteo de contribuyentes activos: ĀæcuĆ”ntos usuarios estĆ”n contribuyendo activamente al cĆ³digo de un proyecto y con quĆ© frecuencia? En muchos casos, tendrĆ” dos o tres desarrolladores con algunos commits por dĆ­a o posiblemente menos para proyectos un tanto inactivos. Para empresas o proyectos mĆ”s grandes, la cantidad de desarrolladores podrĆ­a ser de miles, con cientos o miles de compromisos cada dĆ­a. Esto es importante porque con mĆ”s y mĆ”s desarrolladores, se encontrarĆ” con mĆ”s problemas para asegurarse de que su cĆ³digo se aplique de forma limpia o se pueda fusionar fĆ”cilmente. Los cambios que envĆ­e pueden quedar obsoletos o severamente interrumpidos por el trabajo que se fusionĆ³ mientras estaba trabajando o mientras los cambios estaban esperando ser aprobados o aplicados. ĀæCĆ³mo puede mantener su cĆ³digo constantemente actualizado y sus confirmaciones vĆ”lidas?

La siguiente variable es el flujo de trabajo en uso para el proyecto. ĀæEstĆ” centralizado, con cada desarrollador teniendo el mismo acceso de escritura a la lĆ­nea de cĆ³digo principal? ĀæEl proyecto tiene un mantenedor o un gerente de integraciĆ³n que verifica todos los parches? ĀæEstĆ”n todos los parches revisados por pares y aprobados? ĀæEstĆ” usted involucrado en ese proceso? ĀæHay un sistema de tenientes en su lugar, y tiene que enviar su trabajo primero?

El siguiente problema es su acceso de confirmaciĆ³n. El flujo de trabajo requerido para contribuir a un proyecto es muy diferente si usted tiene acceso de escritura al proyecto que si no lo tiene. Si no tiene acceso de escritura, ĀæcĆ³mo prefiere el proyecto aceptar el trabajo contribuido? ĀæIncluso tiene una polĆ­tica? ĀæCuĆ”nto trabajo estĆ”s contribuyendo a la vez? ĀæCon quĆ© frecuencia contribuye?

Todas estas preguntas pueden afectar la forma en que se contribuye de manera efectiva a un proyecto y los flujos de trabajo preferidos o disponibles para usted. Cubriremos aspectos de cada uno de Ʃstos en una serie de casos de uso, pasando de simples a mƔs complejos; deberƭa poder construir los flujos de trabajo especƭficos que necesita en la prƔctica a partir de estos ejemplos.

Pautas de confirmaciĆ³n

Antes de comenzar a buscar casos de uso especĆ­ficos, aquĆ­ hay una nota rĆ”pida sobre los mensajes de confirmaciĆ³n. Tener una buena guĆ­a para crear compromisos y apegarse a ella hace que trabajar con Git y colaborar con otros sea mucho mĆ”s fĆ”cil. El proyecto Git proporciona un documento que presenta una serie de buenos consejos para crear compromisos a partir de los cuales enviar parches: puede leerlos en el cĆ³digo fuente de Git en el archivo Documentation / SubmittingPatches.

En primer lugar, no desea enviar ningĆŗn error de espacios en blanco. Git proporciona una manera fĆ”cil de verificar esto: antes de comprometerse, ejecute git diff --check, que identifica posibles errores de espacio en blanco y los enumera por usted.

Output of `git diff --check`.
Figura 57. Output of git diff --check.

Si ejecuta ese comando antes de confirmar, puede ver si estĆ” a punto de cometer errores de espacio en blanco que pueden molestar a otros desarrolladores.

A continuaciĆ³n, intente hacer de cada commit un conjunto de cambios lĆ³gicamente separado. Si puede, trate de hacer que sus cambios sean digeribles: no codifique durante un fin de semana entero en cinco asuntos diferentes para luego envĆ­arlos todos como un compromiso masivo el lunes. Incluso si no confirma durante el fin de semana, utilice el Ć”rea de etapas el lunes para dividir su trabajo en al menos una confirmaciĆ³n por cuestiĆ³n, con un mensaje Ćŗtil por confirmaciĆ³n. Si algunos de los cambios modifican el mismo archivo, intente utilizar git add --patch para representar parcialmente los archivos (se detalla en << _ interactive_staging >>). La instantĆ”nea del proyecto en la punta de la rama es idĆ©ntica, ya sea que realice una confirmaciĆ³n o cinco, siempre que todos los cambios se agreguen en algĆŗn momento, asĆ­ que trate de facilitar las cosas a sus compaƱeros desarrolladores cuando tengan que revisar sus cambios. Este enfoque tambiĆ©n hace que sea mĆ”s fĆ”cil retirar o revertir uno de los conjuntos de cambios si lo necesita mĆ”s adelante. << _ rewriting_history >> describe una serie de trucos Ćŗtiles de Git para reescribir el historial y organizar de forma interactiva los archivos: use estas herramientas para crear un historial limpio y comprensible antes de enviar el trabajo a otra persona.

Lo Ćŗltimo a tener en cuenta es el mensaje de compromiso. Tener el hĆ”bito de crear mensajes de compromiso de calidad hace que usar y colaborar con Git sea mucho mĆ”s fĆ”cil. Como regla general, sus mensajes deben comenzar con una sola lĆ­nea que no supere los 50 caracteres y que describa el conjunto de cambios de forma concisa, seguido de una lĆ­nea en blanco, seguida de una explicaciĆ³n mĆ”s detallada. El proyecto Git requiere que la explicaciĆ³n mĆ”s detallada incluya su motivaciĆ³n para el cambio y contraste su implementaciĆ³n con el comportamiento anterior: esta es una buena guĆ­a a seguir. TambiĆ©n es una buena idea usar el tiempo presente imperativo en estos mensajes. En otras palabras, use comandos. En lugar de ā€˜` agreguĆ© pruebas para ā€™ o ā€˜` AƱadir pruebas para ', use `` Agregar pruebas para 'ā€™. AquĆ­ hay una plantilla escrita originalmente por Tim Pope:

Resumen de cambios cortos (50 caracteres o menos)

Texto explicativo mƔs detallado, si es necesario. Ajustarlo a
aproximadamente 72 caracteres mƔs o menos. En algunos contextos, la primera
lĆ­nea se trata como el tema de un correo electrĆ³nico y el resto de
el texto como el cuerpo. La lĆ­nea en blanco que separa el
resumen del cuerpo es crĆ­tica (a menos que omita el cuerpo
enteramente); herramientas como ``rebase'' pueden confundirse si ejecuta
los dos juntos.

Otros pƔrrafos vienen despuƩs de las lƭneas en blanco.

  - Los puntos de viƱetas tambiƩn estƔn bien

  - TĆ­picamente se usa un guiĆ³n o asterisco para la viƱeta,
    precedido por un solo espacio, con lĆ­neas en blanco
    entre viƱetas, pero las convenciones varƭan aquƭ

Si todos sus mensajes de confirmaciĆ³n se ven asĆ­, las cosas serĆ”n mucho mĆ”s fĆ”ciles para usted y para los desarrolladores con los que trabaja. El proyecto Git tiene mensajes de confirmaciĆ³n bien formateados. Intente ejecutar git log --no-merges allĆ­ para ver cĆ³mo se ve un historial de commit de proyecto muy bien formateado.

En los siguientes ejemplos y en la mayor parte de este libro, en aras de la brevedad, no verĆ” mensajes con un formato agradable como Ć©ste; en cambio, usamos la opciĆ³n -m para` git commit`. Haz lo que decimos, no como lo hacemos.

PequeƱo equipo privado

La configuraciĆ³n mĆ”s simple que es probable encuentre, es un proyecto privado con uno o dos desarrolladores mĆ”s. ā€˜` Privado 'ā€™, en este contexto, significa fuente cerrada, no accesible para el mundo exterior. Usted y los demĆ”s desarrolladores son los Ćŗnicos que tienen acceso de inserciĆ³n al repositorio.

En este entorno, puede seguir un flujo de trabajo similar a lo que podrĆ­a hacer al usar Subversion u otro sistema centralizado. AĆŗn obtiene las ventajas de cosas como el compromiso fuera de lĆ­nea y una bifurcaciĆ³n y fusiĆ³n mucho mĆ”s simples, pero el flujo de trabajo puede ser muy similar; la principal diferencia es que las fusiones ocurren en el lado del cliente en lugar del servidor en el momento de la confirmaciĆ³n. Veamos cĆ³mo se verĆ­a cuando dos desarrolladores comiencen a trabajar juntos con un repositorio compartido. El primer desarrollador, John, clona el repositorio, hace un cambio y se compromete localmente. (Los mensajes de protocolo se han reemplazado con ... en estos ejemplos para acortarlos un poco).

# John's Machine
$ git clone john@githost:simplegit.git
Initialized empty Git repository in /home/john/simplegit/.git/
...
$ cd simplegit/
$ vim lib/simplegit.rb
$ git commit -am 'removed invalid default value'
[master 738ee87] removed invalid default value
 1 files changed, 1 insertions(+), 1 deletions(-)

El segundo desarrollador, Jessica, hace lo mismo: clona el repositorio y comete un cambio:

# Jessica's Machine
$ git clone jessica@githost:simplegit.git
Initialized empty Git repository in /home/jessica/simplegit/.git/
...
$ cd simplegit/
$ vim TODO
$ git commit -am 'add reset task'
[master fbff5bc] add reset task
 1 files changed, 1 insertions(+), 0 deletions(-)

Ahora, Jessica lleva su trabajo al servidor:

# Jessica's Machine
$ git push origin master
...
To jessica@githost:simplegit.git
   1edee6b..fbff5bc  master -> master

John intenta impulsar su cambio, tambiƩn:

# John's Machine
$ git push origin master
To john@githost:simplegit.git
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'john@githost:simplegit.git'

John no puede presionar porque Jessica ha presionado mientras tanto. Esto es especialmente importante de entender si estĆ” acostumbrado a Subversion, porque notarĆ” que los dos desarrolladores no editaron el mismo archivo. Aunque Subversion realiza automĆ”ticamente una fusiĆ³n de este tipo en el servidor si se editan diferentes archivos, en Git debe fusionar los commit localmente. John tiene que buscar los cambios de Jessica y fusionarlos antes de que se le permita presionar:

$ git fetch origin
...
From john@githost:simplegit
 + 049d078...fbff5bc master     -> origin/master

En este punto, el repositorio local de John se ve asĆ­:

Johnā€™s divergent history.
Figura 58. Johnā€™s divergent history.

John tiene una referencia a los cambios que Jessica elevĆ³, pero tiene que fusionarlos en su propio trabajo antes de que se le permita presionar:

$ git merge origin/master
Merge made by recursive.
 TODO |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

La fusiĆ³n funciona sin problemas: el historial de compromisos de John ahora se ve asĆ­:

Johnā€™s repository after merging `origin/master`.
Figura 59. Johnā€™s repository after merging origin/master.

Ahora, John puede probar su cĆ³digo para asegurarse de que todavĆ­a funciona correctamente, y luego puede enviar su nuevo trabajo combinado al servidor:

$ git push origin master
...
To john@githost:simplegit.git
   fbff5bc..72bbc59  master -> master

Finalmente, el historial de compromisos de John se ve asĆ­:

Johnā€™s history after pushing to the `origin` server.
Figura 60. Johnā€™s history after pushing to the origin server.

Mientras tanto, Jessica ha estado trabajando en una rama temĆ”tica. Ella creĆ³ una rama temĆ”tica llamada issue54 y realizĆ³ tres commits en esa rama. TodavĆ­a no ha revisado los cambios de John, por lo que su historial de commit se ve asĆ­:

Jessicaā€™s topic branch.
Figura 61. Jessicaā€™s topic branch.

Jessica quiere sincronizar con John, asĆ­ que busca:

# Jessica's Machine
$ git fetch origin
...
From jessica@githost:simplegit
   fbff5bc..72bbc59  master     -> origin/master

Eso reduce el trabajo que John ha impulsado mientras tanto. La historia de Jessica ahora se ve asĆ­:

Jessicaā€™s history after fetching Johnā€™s changes.
Figura 62. Jessicaā€™s history after fetching Johnā€™s changes.

Jessica cree que su rama temƔtica estƔ lista, pero quiere saber quƩ tiene que fusionar en su trabajo para poder impulsarla. Ella ejecuta git log para descubrir:

$ git log --no-merges issue54..origin/master
commit 738ee872852dfaa9d6634e0dea7a324040193016
Author: John Smith <jsmith@example.com>
Date:   Fri May 29 16:01:27 2009 -0700

   removed invalid default value

La sintaxis issue54..origin / master es un filtro de registro que le pide a Git que sĆ³lo muestre la lista de confirmaciones que estĆ”n en la Ćŗltima rama (en este caso` origen / maestro`) que no estĆ”n en la primera rama (en este case issue54). Repasaremos esta sintaxis en detalle en << _ commit_ranges >>.

Por ahora, podemos ver en el resultado que hay un compromiso Ćŗnico que John ha realizado en el que Jessica no se ha fusionado. Si fusiona origen / maestro, esa es la Ćŗnica confirmaciĆ³n que modificarĆ” su trabajo local.

Ahora, Jessica puede fusionar su trabajo temƔtico en su rama principal, fusionar el trabajo de John (origin / master) en su rama` master`, y luego volver al servidor nuevamente. Primero, vuelve a su rama principal para integrar todo este trabajo:

$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded.

Ella puede fusionar ya sea origin / master o` issue54` primero - ambos estĆ”n en sentido ascendente, por lo que el orden no importa. La instantĆ”nea final debe ser idĆ©ntica sin importar quĆ© orden ella elija; sĆ³lo la historia serĆ” ligeramente diferente. Ella elige fusionarse en issue54 primero:

$ git merge issue54
Updating fbff5bc..4af4298
Fast forward
 README           |    1 +
 lib/simplegit.rb |    6 +++++-
 2 files changed, 6 insertions(+), 1 deletions(-)

No hay problemas como pueden ver, fue un simple avance rƔpido. Ahora Jessica se fusiona en el trabajo de John (origin / master):

$ git merge origin/master
Auto-merging lib/simplegit.rb
Merge made by recursive.
 lib/simplegit.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Todo se funde limpiamente, y la historia de Jessica se ve asĆ­:

Jessicaā€™s history after merging Johnā€™s changes.
Figura 63. Jessicaā€™s history after merging Johnā€™s changes.

Ahora origin / master es accesible desde la rama` master` de Jessica, por lo que deberĆ­a poder presionar con Ć©xito (suponiendo que John no haya pulsado nuevamente mientras tanto):

$ git push origin master
...
To jessica@githost:simplegit.git
   72bbc59..8059c15  master -> master

Cada desarrollador se ha comprometido algunas veces y se ha fusionado el trabajo de cada uno con Ć©xito.

Jessicaā€™s history after pushing all changes back to the server.
Figura 64. Jessicaā€™s history after pushing all changes back to the server.

Ese es uno de los flujos de trabajo mƔs simples. Trabajas por un tiempo, generalmente en una rama temƔtica, y te unes a tu rama principal cuando estƔ lista para integrarse. Cuando desee compartir ese trabajo, hƔgalo en su propia rama principal, luego busque y combine origin / master si ha cambiado, y finalmente presione en la rama` master` del servidor. La secuencia general es algo como esto:

General sequence of events for a simple multiple-developer Git workflow.
Figura 65. General sequence of events for a simple multiple-developer Git workflow.

Equipo privado administrado

En este prĆ³ximo escenario, observarĆ” los roles de los contribuyentes en un grupo privado mĆ”s grande. AprenderĆ” cĆ³mo trabajar en un entorno en el que los grupos pequeƱos colaboran en las funciones y luego esas contribuciones en equipo estarĆ”n integradas por otra parte.

Digamos que John y Jessica estĆ”n trabajando juntos en una caracterĆ­stica, mientras que Jessica y Josie estĆ”n trabajando en una segunda. En este caso, la compaƱƭa estĆ” utilizando un tipo de flujo de trabajo de integraciĆ³n-gerente donde el trabajo de los grupos individuales estĆ” integrado sĆ³lo por ciertos ingenieros, y la rama maestra del repositorio principal sĆ³lo puede ser actualizada por esos ingenieros. En este escenario, todo el trabajo se realiza en ramas basadas en equipos y luego los integradores lo agrupan.

Sigamos el flujo de trabajo de Jessica mientras trabaja en sus dos funciones, colaborando en paralelo con dos desarrolladores diferentes en este entorno. Suponiendo que ya haya clonado su repositorio, ella decide trabajar primero en featureA. Ella crea una nueva rama para la caracterĆ­stica y hace algo de trabajo allĆ­:

# Jessica's Machine
$ git checkout -b featureA
Switched to a new branch 'featureA'
$ vim lib/simplegit.rb
$ git commit -am 'add limit to log function'
[featureA 3300904] add limit to log function
 1 files changed, 1 insertions(+), 1 deletions(-)

En este punto, ella necesita compartir su trabajo con John, por lo que empuja a su rama featureA a comprometerse con el servidor. Jessica no tiene acceso de inserciĆ³n a la rama maestra, solo los integradores lo hacen, por lo que debe enviar a otra rama para colaborar con John:

$ git push -u origin featureA
...
To jessica@githost:simplegit.git
 * [new branch]      featureA -> featureA

Jessica le envĆ­a un correo electrĆ³nico a John para decirle que ha enviado algo de trabajo a una rama llamada featureA y ahora puede verlo. Mientras espera los comentarios de John, Jessica decide comenzar a trabajar en featureB con Josie. Para comenzar, inicia una nueva rama de caracterĆ­sticas, basĆ”ndose en la rama master del servidor:

# Jessica's Machine
$ git fetch origin
$ git checkout -b featureB origin/master
Switched to a new branch 'featureB'

Ahora, Jessica hace un par de commits en la rama featureB:

$ vim lib/simplegit.rb
$ git commit -am 'made the ls-tree function recursive'
[featureB e5b0fdc] made the ls-tree function recursive
 1 files changed, 1 insertions(+), 1 deletions(-)
$ vim lib/simplegit.rb
$ git commit -am 'add ls-files'
[featureB 8512791] add ls-files
 1 files changed, 5 insertions(+), 0 deletions(-)

El repositorio de Jessica se ve asĆ­:

Jessicaā€™s initial commit history.
Figura 66. Jessicaā€™s initial commit history.

EstĆ” lista para impulsar su trabajo, pero recibe un correo electrĆ³nico de Josie que indica que una rama con algunos trabajos iniciales ya fue enviada al servidor como featureBee. Jessica primero necesita fusionar esos cambios con los suyos antes de poder presionar al servidor. Luego puede buscar los cambios de Josie con git fetch:

$ git fetch origin
...
From jessica@githost:simplegit
 * [new branch]      featureBee -> origin/featureBee

Jessica ahora puede fusionar esto en el trabajo que hizo con git merge:

$ git merge origin/featureBee
Auto-merging lib/simplegit.rb
Merge made by recursive.
 lib/simplegit.rb |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Existe un pequeƱo problema: necesita insertar el trabajo combinado su rama featureB con la rama` featureBee` del servidor. Ella puede hacerlo especificando la rama local seguida de dos puntos (:) seguido de la rama remota al comando git push:

$ git push -u origin featureB:featureBee
...
To jessica@githost:simplegit.git
   fba9af8..cd685d1  featureB -> featureBee

Esto se llama refspec. Ver << _ refspec >> para una discusiĆ³n mĆ”s detallada de las referencias de Git y diferentes cosas que puedes hacer con ellas. TambiĆ©n observe la bandera -u; esto es la abreviatura de --set-upstream, que configura las ramas para empujar y tirar mĆ”s fĆ”cilmente en el futuro.

Luego, John envĆ­a un correo electrĆ³nico a Jessica para decirle que ha enviado algunos cambios a la rama featureA y le pide que los verifique. Ella ejecuta un git fetch para bajar esos cambios:

$ git fetch origin
...
From jessica@githost:simplegit
   3300904..aad881d  featureA   -> origin/featureA

Luego, ella puede ver quƩ se ha cambiado con git log:

$ git log featureA..origin/featureA
commit aad881d154acdaeb2b6b18ea0e827ed8a6d671e6
Author: John Smith <jsmith@example.com>
Date:   Fri May 29 19:57:33 2009 -0700

    changed log output to 30 from 25

Finalmente, fusiona el trabajo de John en su propia rama featureA:

$ git checkout featureA
Switched to branch 'featureA'
$ git merge origin/featureA
Updating 3300904..aad881d
Fast forward
 lib/simplegit.rb |   10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)

Jessica quiere modificar algo, por lo que se compromete de nuevo y luego lo envĆ­a de vuelta al servidor:

$ git commit -am 'small tweak'
[featureA 774b3ed] small tweak
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git push
...
To jessica@githost:simplegit.git
   3300904..774b3ed  featureA -> featureA

El historial de compromiso de Jessica ahora se ve asĆ­:

Jessicaā€™s history after committing on a feature branch.
Figura 67. Jessicaā€™s history after committing on a feature branch.

Jessica, Josie y John informan a los integradores que las ramas featureA y` featureBee` en el servidor estĆ”n listas para su integraciĆ³n en la lĆ­nea principal. DespuĆ©s de que los integradores fusionen estas ramas en la lĆ­nea principal, una bĆŗsqueda reducirĆ” la nueva confirmaciĆ³n de fusiĆ³n, haciendo que el historial se vea asĆ­:

Jessicaā€™s history after merging both her topic branches.
Figura 68. Jessicaā€™s history after merging both her topic branches.

Muchos grupos cambian a Git debido a esta capacidad de tener varios equipos trabajando en paralelo, fusionando las diferentes lĆ­neas de trabajo al final del proceso. La capacidad de los subgrupos mĆ”s pequeƱos de un equipo para colaborar a travĆ©s de ramas remotas, sin necesariamente tener que involucrar o impedir a todo el equipo, es un gran beneficio de Git. La secuencia del flujo de trabajo que viĆ³ aquĆ­ es algo como esto:

Basic sequence of this managed-team workflow.
Figura 69. Basic sequence of this managed-team workflow.

Proyecto pĆŗblico bifurcado

Contribuir a proyectos pĆŗblicos es un poco diferente. Como no tiene los permisos para actualizar directamente las ramas en el proyecto, debe obtener el trabajo de otra manera. Este primer ejemplo describe la contribuciĆ³n mediante bifurcaciĆ³n en hosts Git que admiten bifurcaciĆ³n fĆ”cil. Muchos sitios de alojamiento admiten esto (incluidos GitHub, BitBucket, Google Code, repo.or.cz entre otros), y muchos mantenedores de proyectos esperan este estilo de contribuciĆ³n. La siguiente secciĆ³n trata de proyectos que prefieren aceptar parches contribuidos por correo electrĆ³nico.

En primer lugar, es probable que desee clonar el repositorio principal, crear una rama de tema para el parche o la serie de parches en que planea contribuir y hacer su trabajo allƭ. La secuencia se ve bƔsicamente asƭ:

$ git clone (url)
$ cd project
$ git checkout -b featureA
# (work)
$ git commit
# (work)
$ git commit
Nota

Puede usar rebase -i para reducir su trabajo a una Ćŗnica confirmaciĆ³n, o reorganizar el trabajo en las confirmaciones para que el desarrollador pueda revisar el parche mĆ”s fĆ”cilmente. Consulte << _ rewriting_history >> para obtener mĆ”s informaciĆ³n sobre el rebase interactivo.

Cuando finalice el trabajo en la rama y estĆ© listo para contribuir con los mantenedores, vaya a la pĆ”gina original del proyecto y haga clic en el botĆ³n ā€˜` Tenedor 'ā€™, creando su propio tenedor escribible del proyecto. Luego debe agregar esta nueva URL de repositorio como segundo control remoto, en este caso llamado myfork:

$ git remote add myfork (url)

Entonces necesitas impulsar tu trabajo hasta esa nua URL. Es mĆ”s fĆ”cil impulsar la rama de tema en la que estĆ” trabajando hasta su repositorio, en lugar de fusionarse con su rama principal y aumentarla. La razĆ³n es que si el trabajo no se acepta o se selecciona con una cereza, no es necesario rebobinar la rama maestra. Si los mantenedores se fusionan, redimensionan o seleccionan su trabajo, eventualmente lo recuperarĆ” a travĆ©s de su repositorio de todas maneras:

$ git push -u myfork featureA

Cuando su trabajo ha sido empujado hacia su tenedor, debe notificar al mantenedor. Esto a menudo se denomina solicitud de extracciĆ³n, y puede generarlo a travĆ©s del sitio web: GitHub tiene su propio mecanismo de solicitud de extracciĆ³n que veremos en << _ github >> o puede ejecutar el comando git request-pull y envĆ­ar por correo electrĆ³nico la salida al mantenedor del proyecto de forma manual.

El comando request-pull toma la rama base en la que desea que se saque su rama de tema y la URL del repositorio de Git de la que desea que extraigan, y genera un resumen de todos los cambios que estĆ” solicitando. Por ejemplo, si Jessica quiere enviar a John una solicitud de extracciĆ³n, y ella ha hecho dos commits en la rama de temas que acaba de subir, puede ejecutar esto:

$ git request-pull origin/master myfork
The following changes since commit 1edee6b1d61823a2de3b09c160d7080b8d1b3a40:
  John Smith (1):
        added a new function

are available in the git repository at:

  git://githost/simplegit.git featureA

Jessica Smith (2):
      add limit to log function
      change log output to 30 from 25

 lib/simplegit.rb |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

La salida se puede enviar al mantenedor, le dice de dĆ³nde se ramificĆ³ el trabajo, resume los compromisos y dice de dĆ³nde sacar este trabajo.

En un proyecto para el cual no eres el mantenedor, generalmente es mĆ”s fĆ”cil tener una rama como master siempre rastreando` origin / master` y hacer tu trabajo en ramas de tema que puedes descartar fĆ”cilmente si son rechazadas. Tener temas de trabajo aislados en las ramas temĆ”ticas tambiĆ©n facilita la tarea de volver a establecer una base de trabajo si la punta del repositorio principal se ha movido mientras tanto y sus confirmaciones ya no se aplican limpiamente. Por ejemplo, si desea enviar un segundo tema de trabajo al proyecto, no continĆŗe trabajando en la rama de tema que acaba de crear: vuelva a comenzar desde la rama master del repositorio principal:

$ git checkout -b featureB origin/master
# (work)
$ git commit
$ git push myfork featureB
# (email maintainer)
$ git fetch origin

Ahora, cada uno de sus temas estĆ” contenido dentro de un silo, similar a una fila de parches, que puede volver a escribir, volver a establecer y modificar sin que los temas interfieran o se interrelacionen entre sĆ­, de la siguiente manera:

Initial commit history with `featureB` work.
Figura 70. Initial commit history with featureB work.

Digamos que el mantenedor del proyecto ha sacado otros parches y ha probado su primera rama, pero ya no se fusiona de manera limpia. En este caso, puede tratar de volver a establecer la base de esa rama sobre origin / master, resolver los conflictos del mantenedor y luego volver a enviar los cambios:

$ git checkout featureA
$ git rebase origin/master
$ git push -f myfork featureA

Esto reescribe tu historial para que ahora parezca << psp_b >>.

Commit history after `featureA` work.
Figura 71. Commit history after featureA work.

Debido a que rebasaste la rama, debes especificar el -f en tu comando push para poder reemplazar la rama` featureA` en el servidor con una confirmaciĆ³n que no sea un descendiente de ella. Una alternativa serĆ­a llevar este nuevo trabajo a una rama diferente en el servidor (tal vez llamada featureAv2).

Veamos un escenario mĆ”s posible: el mantenedor ha observado el trabajo en su segunda rama y le gusta el concepto, pero le gustarĆ­a que cambie un detalle de implementaciĆ³n. TambiĆ©n aprovecharĆ” esta oportunidad para mover el trabajo basado en la rama maestra 'actual del proyecto. Usted inicia una nueva rama basada en la rama actual de 'origen / maestro', aplasta los cambios `featureB allĆ­, resuelve cualquier conflicto, hace que la implementaciĆ³n cambie, y luego lo empuja hacia arriba como una nueva rama:

$ git checkout -b featureBv2 origin/master
$ git merge --no-commit --squash featureB
# (change implementation)
$ git commit
$ git push myfork featureBv2

La opciĆ³n --squash toma todo el trabajo en la rama fusionada y lo aplasta en una confirmaciĆ³n sin fusiĆ³n en la parte superior de la rama en la que se encuentra. La opciĆ³n --no-commit le dice a Git que no registre automĆ”ticamente una confirmaciĆ³n. Esto le permite introducir todos los cambios desde otra rama y luego realizar mĆ”s cambios antes de registrar la nueva confirmaciĆ³n.

Ahora puede enviar al mantenedor un mensaje de que ha realizado los cambios solicitados y puede encontrar esos cambios en su rama featureBv2.

Commit history after `featureBv2` work.
Figura 72. Commit history after featureBv2 work.

Proyecto pĆŗblico a travĆ©s de correo electrĆ³nico

Muchos proyectos han establecido procedimientos para aceptar parches: deberĆ” verificar las reglas especĆ­ficas para cada proyecto, ya que serĆ”n diferentes. Dado que hay varios proyectos antiguos y mĆ”s grandes que aceptan parches a travĆ©s de una lista de correo electrĆ³nico para desarrolladores, veremos un ejemplo de eso ahora.

El flujo de trabajo es similar al caso de uso anterior: crea ramas de tema para cada serie de parches en las que trabaja. La diferencia es cĆ³mo los envĆ­a al proyecto. En lugar de bifurcar el proyecto y avanzar hacia su propia versiĆ³n de escritura, genera versiones de correo electrĆ³nico de cada serie de commit y las envĆ­a por correo electrĆ³nico a la lista de correo de desarrolladores:

$ git checkout -b topicA
# (work)
$ git commit
# (work)
$ git commit

Ahora tiene dos confirmaciones que desea enviar a la lista de correo. Utiliza git format-patch para generar los archivos con formato mbox que puedes enviar por correo electrĆ³nico a la lista: convierte cada confirmaciĆ³n en un mensaje de correo electrĆ³nico con la primera lĆ­nea del mensaje de confirmaciĆ³n como tema y el resto de el mensaje mĆ”s el parche que introduce el compromiso como el cuerpo. Lo bueno de esto es que la aplicaciĆ³n de un parche de un correo electrĆ³nico generado con format-patch conserva toda la informaciĆ³n de compromiso correctamente.

$ git format-patch -M origin/master
0001-add-limit-to-log-function.patch
0002-changed-log-output-to-30-from-25.patch

El comando format-patch imprime los nombres de los archivos de parche que crea. El modificador -M le dice a Git que busque cambios de nombre. Los archivos terminan pareciƩndose a esto:

$ cat 0001-add-limit-to-log-function.patch
From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] add limit to log function

Limit log functionality to the first 20

---
 lib/simplegit.rb |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lib/simplegit.rb b/lib/simplegit.rb
index 76f47bc..f9815f1 100644
--- a/lib/simplegit.rb
+++ b/lib/simplegit.rb
@@ -14,7 +14,7 @@ class SimpleGit
   end

   def log(treeish = 'master')
-    command("git log #{treeish}")
+    command("git log -n 20 #{treeish}")
   end

   def ls_tree(treeish = 'master')
--
2.1.0

TambiĆ©n puede editar estos archivos de parche para agregar mĆ”s informaciĆ³n para la lista de correo electrĆ³nico que no desea mostrar en el mensaje de confirmaciĆ³n. Si agrega texto entre la lĆ­nea --- y el comienzo del parche (la lĆ­nea diff - git), los desarrolladores pueden leerlo; pero aplicar el parche lo excluye.

Para enviarlo por correo electrĆ³nico a una lista de correo, puede pegar el archivo en su programa de correo electrĆ³nico o enviarlo a travĆ©s de un programa de lĆ­nea de comandos. Pegar el texto a menudo causa problemas de formateo, especialmente con clientes ā€˜` mĆ”s inteligentes 'ā€™ que no conservan lĆ­neas nuevas y otros espacios en blanco de manera apropiada. Afortunadamente, Git proporciona una herramienta para ayudarlo a enviar parches con formato correcto a travĆ©s de IMAP, que puede ser mĆ”s fĆ”cil para usted. Demostraremos cĆ³mo enviar un parche a travĆ©s de Gmail, que es el agente de correo electrĆ³nico que mejor conocemos; puede leer instrucciones detalladas para una cantidad de programas de correo al final del archivo Documentation / SubmittingPatches antes mencionado en el cĆ³digo fuente de Git.

Primero, necesitas configurar la secciĆ³n imap en tu archivo ~ / .gitconfig. Puede establecer cada valor por separado con una serie de comandos git config, o puede agregarlos manualmente, pero al final su archivo de configuraciĆ³n deberĆ­a verse mĆ”s o menos asĆ­:

[imap]
  folder = "[Gmail]/Drafts"
  host = imaps://imap.gmail.com
  user = user@gmail.com
  pass = p4ssw0rd
  port = 993
  sslverify = false

Si su servidor IMAP no usa SSL, las dos Ćŗltimas lĆ­neas probablemente no sean necesarias, y el valor del host serĆ” imap: // en lugar de imaps: //. Cuando estĆ© configurado, puede usar git send-email para colocar la serie de parches en la carpeta Borradores del servidor IMAP especificado:

$ git send-email *.patch
0001-added-limit-to-log-function.patch
0002-changed-log-output-to-30-from-25.patch
Who should the emails appear to be from? [Jessica Smith <jessica@example.com>]
Emails will be sent from: Jessica Smith <jessica@example.com>
Who should the emails be sent to? jessica@example.com
Message-ID to be used as In-Reply-To for the first email? y

Entonces, Git escupe un montĆ³n de informaciĆ³n de registro que se ve algo asĆ­ para cada parche que estĆ” enviando:

(mbox) Adding cc: Jessica Smith <jessica@example.com> from
  \line 'From: Jessica Smith <jessica@example.com>'
OK. Log says:
Sendmail: /usr/sbin/sendmail -i jessica@example.com
From: Jessica Smith <jessica@example.com>
To: jessica@example.com
Subject: [PATCH 1/2] added limit to log function
Date: Sat, 30 May 2009 13:29:15 -0700
Message-Id: <1243715356-61726-1-git-send-email-jessica@example.com>
X-Mailer: git-send-email 1.6.2.rc1.20.g8c5b.dirty
In-Reply-To: <y>
References: <y>

Result: OK

En este punto, debe poder ir a la carpeta Borradores, cambiar el campo ā€œAā€(To) a la lista de correo a la que le envĆ­a el parche, posiblemente CC al responsable de esa secciĆ³n y enviarlo.

Resumen

Esta secciĆ³n ha cubierto una cantidad de flujos de trabajo comunes para tratar con varios tipos muy diferentes de proyectos de Git que probablemente encuentre, e introdujo algunas herramientas nuevas para ayudarlo a administrar este proceso. A continuaciĆ³n, verĆ” cĆ³mo trabajar la otra cara de la moneda: mantener un proyecto de Git. AprenderĆ” cĆ³mo ser un dictador benevolente o un gerente de integraciĆ³n.

scroll-to-top