perlgit - Online en la nube

PROGRAMA:

NOMBRE

perlgit: información detallada sobre git y el repositorio de Perl

DESCRIPCIÓN

Este documento proporciona detalles sobre el uso de git para desarrollar Perl. Si solo esta interesado en
trabajando en un parche rápido, vea perlhack primero. Este documento está destinado a personas que
son colaboradores habituales de Perl, incluidos aquellos con acceso de escritura al repositorio de git.

CLONACIÓN EL REPOSITORIO

Todo el código fuente de Perl se mantiene de forma centralizada en un repositorio de Git en perl5.git.perl.org.

Puede hacer un clon de solo lectura del repositorio ejecutando:

% git clon git: //perl5.git.perl.org/perl.git perl

Esto usa el protocolo git (puerto 9418).

Si no puede usar el protocolo git por razones de firewall, también puede clonar a través de http,
aunque esto es mucho más lento:

% clon de git http://perl5.git.perl.org/perl.git perl

DE TRABAJO CON EL REPOSITORIO

Una vez que haya cambiado al directorio del repositorio, puede inspeccionarlo. Después de un clon
El repositorio contendrá una única rama local, que también será la rama actual,
como lo indica el asterisco.

% rama de git
* sangre

El uso del interruptor -a para "rama" también mostrará las ramas de seguimiento remoto en el
repositorio:

% rama git -a
* sangre
origen / CABEZA
origen / blead
...

Las ramas que comienzan con "origin" corresponden al "git remote" desde el que clonaste
(que se llama "origen"). Cada rama del control remoto será rastreada exactamente por estos
sucursales. NUNCA debe trabajar en estas ramas de seguimiento remoto. Tu solo lo haces
trabajar en una sucursal local. Las sucursales locales se pueden configurar para fusionar automáticamente (al extraer) desde un
sucursal designada de seguimiento remoto. Este es el caso de la rama predeterminada "blead" que
se configurará para fusionarse desde la rama de seguimiento remoto "origen / sangrado".

Puedes ver las confirmaciones recientes:

% registro de Git

Y extraiga nuevos cambios del repositorio y actualice su repositorio local (debe estar limpio
primero)

% extracción de git

Suponiendo que estamos en la rama "blead" inmediatamente después de un tirón, este comando sería más
o menos equivalente a:

% git obtener
% git merge origin / blead

De hecho, si desea actualizar su repositorio local sin tocar su trabajo
directorio que haces:

% git obtener

Y si desea actualizar sus sucursales de seguimiento remoto para todos los controles remotos definidos
simultáneamente puedes hacer

% git actualización remota

Ninguno de estos dos últimos comandos actualizará su directorio de trabajo, sin embargo, ambos
actualice las ramas de seguimiento remoto en su repositorio.

Para hacer una sucursal local de una sucursal remota:

% git checkout -b maint-5.10 origin / maint-5.10

Para volver a sangrar:

% git pago blead

Encontrar out Tu estado
El comando git más común que usará probablemente sea

% estado de git

Este comando producirá como salida una descripción del estado actual del repositorio,
incluyendo archivos modificados y archivos sin seguimiento no ignorados, y además mostrará
cosas como qué archivos se han preparado para la próxima confirmación y, por lo general, algunos útiles
información sobre cómo cambiar las cosas. Por ejemplo lo siguiente:

estado de $ git
# En rama blead
# Su rama está por delante de 'origin / blead' por 1 confirmación.
#
# Cambios a comprometer:
# (use "git reset HEAD ... "para quitar el escenario)
#
# modificado: pod / perlgit.pod
#
# Modificado pero no actualizado:
# (use "git add ... "para actualizar lo que se comprometerá)
#
# modificado: pod / perlgit.pod
#
# Archivos sin seguimiento:
# (use "git add ... "para incluir en lo que se va a comprometer)
#
# deliberado.sin seguimiento

Esto muestra que hubo cambios en este documento preparados para su confirmación, y que hubo
más cambios en el directorio de trabajo aún no se han realizado. También muestra que hubo un
archivo sin seguimiento en el directorio de trabajo, y como puede ver muestra cómo cambiar todos los
esta. También muestra que hay una confirmación en la rama de trabajo "blead" que no tiene
ha sido empujado al control remoto de "origen" todavía. NOTA: que esta salida es también lo que ve como un
template si no proporciona un mensaje a "git commit".

Patch flujo de trabajo
Primero, lea perlhack para obtener detalles sobre cómo piratear el núcleo de Perl. Ese documento cubre
muchos detalles sobre cómo crear un buen parche.

Si ya tiene un repositorio de Perl, debe asegurarse de estar en el sangrar rama,
y su repositorio está actualizado:

% git pago blead
% extracción de git

Es preferible aplicar el parche a la última versión de blead, ya que aquí es donde hay nuevas
el desarrollo ocurre para todos los cambios que no sean correcciones de errores críticos. Parches de corrección de errores críticos
debe hacerse contra las sucursales de maint relevantes, o debe enviarse con una nota
indicando todas las ramas donde se debe aplicar el arreglo.

Ahora que tenemos todo actualizado, necesitamos crear una nueva rama temporal para estos
cambia y cambia a él:

% git checkout -b naranja

que es la forma corta de

% git branch naranja
% git checkout naranja

La creación de una rama de tema facilita a los mantenedores volver a establecer una base o fusionarse en
el maestro sangró por una historia más lineal. Si no trabaja en una rama temática,
El mantenedor tiene que seleccionar manualmente los cambios en Blead antes de que se puedan aplicar.

Eso hará que te regañen con perl5-porters, así que no hagas eso. Ser impresionante.

Luego haz tus cambios. Por ejemplo, si Leon Brocard cambia su nombre a Orange Brocard,
debemos cambiar su nombre en el archivo AUTORES:

AUTORES de% perl -pi -e 's {Leon Brocard} {Orange Brocard}'

Puede ver qué archivos se han modificado:

% estado de git
# En rama naranja
# Cambios a comprometer:
# (use "git reset HEAD ... "para quitar el escenario)
#
# modificado: AUTORES
#

Y puedes ver los cambios:

% git diferencia
diff --git a / AUTORES b / AUTORES
index 293dd70..722c93e 100644
--- a / AUTORES
+++ b / AUTORES
@@ -541,7 +541,7 @@ Lars Hecking[email protected]>
Laszlo Molnar[email protected]>
Leif Huhn[email protected]>
Len Johnson[email protected]>
-Leon Brocard[email protected]>
+ Brocard naranja[email protected]>
Les Peters[email protected]>
Lesley Binks[email protected]>
Lincoln D. Stein[email protected]>

Ahora confirme su cambio localmente:

% git commit -a -m 'Cambiar el nombre de Leon Brocard a Orange Brocard'
Confirmación creada 6196c1d: Cambiar el nombre de Leon Brocard a Orange Brocard
1 archivos modificados, 1 inserciones (+), 1 eliminaciones (-)

La opción "-a" se usa para incluir todos los archivos que tienen pistas que ha cambiado. Estoy gordo
esta vez, solo desea confirmar algunos de los archivos en los que ha trabajado, puede omitir el
"-a" y usa el comando "git add ARCHIVO ... " antes de hacer el compromiso.
"git add --interactive" le permite incluso confirmar partes de archivos en lugar de todos
los cambios en ellos.

La opción "-m" se utiliza para especificar el mensaje de confirmación. Si lo omite, git abrirá un
editor de texto para que redacte el mensaje de forma interactiva. Esto es útil cuando los cambios
son más complejas que la muestra dada aquí y, dependiendo del editor, saber que
la primera línea del mensaje de confirmación no excede el máximo legal de 50 caracteres.

Una vez que haya terminado de escribir su mensaje de confirmación y haya salido de su editor, git escribirá
su cambio a disco y le dirá algo como esto:

Creado commit daf8e63: explica el estado de git y cosas sobre controles remotos
1 archivos modificados, 83 inserciones (+), 3 eliminaciones (-)

Si vuelve a ejecutar "git status", debería ver algo como esto:

% estado de git
# En rama blead
# Su rama está por delante de 'origin / blead' por 2 confirmaciones.
#
# Archivos sin seguimiento:
# (use "git add ... "para incluir en lo que se va a comprometer)
#
# deliberado.sin seguimiento
no se agregó nada para confirmar, pero los archivos sin seguimiento están presentes (use "git add" para realizar el seguimiento)

En caso de duda, antes de hacer cualquier otra cosa, compruebe su estado y léalo atentamente, muchos
Las preguntas son respondidas directamente por la salida de estado de git.

Puede examinar su última confirmación con:

% git muestra CABEZA

y si no está satisfecho con la descripción o el parche en sí, puede arreglarlo
editando los archivos una vez más y luego emitir:

% git commit -a --enmendar

Ahora debería crear un archivo de parche para todos sus cambios locales:

% git format-patch -M blead ..
0001-Renombrar-Leon-Brocard-to-Orange-Brocard.patch

O para muchos cambios, por ejemplo, de una rama de tema:

% git format-patch --stdout -M blead ..> topic-branch-changes.patch

Ahora debería enviar un correo electrónico a [email protected] <mailto:[email protected]> con un
descripción de sus cambios e incluya este archivo de parche como adjunto. Además de
siendo rastreado por RT, el correo a perlbug se reenviará automáticamente a perl5-porters
(con moderación manual, tenga paciencia). Solo debe enviar parches a
[email protected] <mailto:[email protected]> directamente si el parche no está listo
para ser aplicado, pero destinado a discusión.

Por favor, no use git-enviar-correo electrónico(1) para enviar su parche. Consulte Envío de correos electrónicos de parches para obtener más información.


Si desea eliminar su rama temporal, puede hacerlo con:

% git pago blead
% git branch -d naranja
error: la rama 'naranja' no es un antepasado de su HEAD actual.
Si está seguro de que desea eliminarlo, ejecute 'git branch -D orange'.
% git branch -D naranja
Naranja de rama eliminada.

Comprometidos Tu cambios
Suponiendo que desea confirmar todos los cambios que ha realizado como una sola unidad atómica,
ejecuta este comando:

% git compromiso -a

(Ese "-a" le dice a git que agregue todos los archivos que ha cambiado a esta confirmación. Los archivos nuevos no
agregado automáticamente a su compromiso cuando usa "commit -a" Si desea agregar archivos o para
confirme algunos, pero no todos los cambios, eche un vistazo a la documentación de "git add".)

Git iniciará su editor de texto favorito, para que pueda crear un mensaje de confirmación para
tu cambio. Consulte "Confirmar mensaje" en perlhack para obtener más información sobre lo que hace un buen
cometer mensaje.

Una vez que haya terminado de escribir su mensaje de confirmación y haya salido de su editor, git escribirá
su cambio a disco y le dirá algo como esto:

Creado commit daf8e63: explica el estado de git y cosas sobre controles remotos
1 archivos modificados, 83 inserciones (+), 3 eliminaciones (-)

Si vuelve a ejecutar "git status", debería ver algo como esto:

% estado de git
# En rama blead
# Su rama está por delante de 'origin / blead' por 2 confirmaciones.
#
# Archivos sin seguimiento:
# (use "git add ... "para incluir en lo que se va a comprometer)
#
# deliberado.sin seguimiento
no se agregó nada para confirmar, pero los archivos sin seguimiento están presentes (use "git add" para realizar el seguimiento)

En caso de duda, antes de hacer cualquier otra cosa, compruebe su estado y léalo atentamente, muchos
Las preguntas son respondidas directamente por la salida de estado de git.

Enviando parche correo
Una vez que haya generado su parche, debe enviarlo a [email protected] (como se discutió en
la sección anterior) con un cliente de correo normal como archivo adjunto, junto con una descripción
del parche.

Usted deben No use git-enviar-correo electrónico(1) para enviar parches generados con parche de formato git(1). los
RT sistema de ticketing que vive detrás [email protected] no respeta el contenido en línea de
Correos electrónicos, enviar un parche en línea a RT garantiza que su parche será destruido.

Alguien puede descargar su parche de RT, lo que resultará en el asunto (la primera línea
del mensaje de confirmación) se omite. Vea RT # 74192 y confirme a4583001 para ver un ejemplo.
Alternativamente, alguien puede aplicar su parche de RT después de que llegue a su buzón, por
tiempo en el que RT habrá modificado el contenido en línea del mensaje. Ver RT # 74532 y
confirme f9bcfeac para un mal ejemplo de este modo de falla.

A nota on derivado archivos
Tenga en cuenta que muchos archivos de la distribución son derivados; evite parchearlos, porque
git no verá los cambios en ellos, y el proceso de compilación los sobrescribirá. Parche el
originales en su lugar. La mayoría de las utilidades (como perldoc) están en esta categoría, es decir, parche
utils / perldoc.PL más bien que utils / perldoc. Del mismo modo, no cree parches para archivos
bajo $ src_root / ext de sus copias que se encuentran en $ install_root / lib. Si no está seguro de
la ubicación correcta de un archivo que puede haber sido copiado durante la construcción de la fuente
distribución, consultar el "MANIFIESTO".

Limpieza a trabajando directorio
El comando "git clean" puede usarse con diferentes argumentos como reemplazo de "make
limpio".

Para restablecer su directorio de trabajo a una condición prístina, puede hacer:

% git limpio -dxf

Sin embargo, tenga en cuenta que esto eliminará TODO el contenido sin seguimiento. Puedes usar

% git limpio -Xf

para eliminar todos los archivos ignorados sin seguimiento, como el subproducto de compilación y prueba, pero deje cualquier
archivos creados manualmente solo.

Si solo desea cancelar algunas ediciones no confirmadas, puede usar "git checkout" y darle
una lista de archivos a revertir, o "git checkout -f" para revertirlos todos.

Si desea cancelar una o varias confirmaciones, puede usar "git reset".

Bisector
"git" proporciona una forma integrada de determinar a qué confirmación se debe culpar por introducir un
dado error. "git bisect" realiza una búsqueda binaria del historial para localizar el primer error
cometer. Es rápido, potente y flexible, pero requiere cierta configuración y automatizar el
proceso se necesita un script de shell auxiliar.

El núcleo proporciona un programa de envoltura, Portabilidad / bisect.pl, que intenta simplificar tanto
como sea posible, haciendo que la bisección sea tan simple como ejecutar un resumen de Perl. Por ejemplo, si tu
quiero saber cuando esto se convirtió en un error:

perl -e 'mi $ a: = 2'

simplemente ejecuta esto:

... / Porting / bisect.pl -e 'my $ a: = 2;'

Usando "bisect.pl", con un comando (y ningún otro archivo) es fácil de averiguar

· ¿Qué confirmación provocó la rotura de este código de ejemplo?

· ¿Qué confirmación hizo que este código de ejemplo comenzara a funcionar?

· ¿Qué confirmación agregó el primer archivo para que coincida con esta expresión regular?

· ¿Qué confirmación eliminó el último archivo para que coincida con esta expresión regular?

normalmente sin necesidad de saber qué versiones de perl utilizar como revisiones iniciales y finales,
as bisect.pl busca automáticamente para encontrar la versión estable más antigua para la que la prueba
caso pasa. Ejecute "Porting / bisect.pl --help" para obtener la documentación completa, incluido cómo
establezca las opciones de "Configurar" y tiempo de construcción.

Si necesita más flexibilidad que Portabilidad / bisect.pl tiene que ofrecer, tendrás que correr
"git bisect" usted mismo. Es más útil usar "git bisect run" para automatizar la construcción
y prueba de revisiones de perl. Para esto, necesitará un script de shell para que "git" llame a
probar una revisión en particular. Un ejemplo de secuencia de comandos es Portabilidad / bisect-example.sh, que tu
debería copiar outside del repositorio, ya que el proceso de bisección restablecerá el estado a un
pago limpio mientras se ejecuta. Las instrucciones a continuación asumen que lo copió como ~ / ejecutar y
luego edítelo según corresponda.

Primero ingresa en modo bisecto con:

% git bisect inicio

Por ejemplo, si el error está presente en "HEAD" pero no en 5.10.0, "git" aprenderá sobre
esto cuando entras:

% git bisect mal
% git bisect bueno perl-5.10.0
Bisección: quedan 853 revisiones para probar después de esto

Esto da como resultado la comprobación del compromiso medio entre "HEAD" y "perl-5.10.0". Usted puede
luego ejecute el proceso de bisección con:

% git bisect ejecutar ~ / ejecutar

Cuando se aísla la primera confirmación incorrecta, "git bisect" te lo dirá:

ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5 is first bad commit
commit ca4cfd28534303b82a216cfe83a1c80cbc3b9dc5
Autor: Dave Mitchell[email protected]>
Fecha: Sábado 9 de febrero 14:56:23 2008 +0000

[perl # 49472] Atributos + Error desconocido
...

bisect run éxito

Puede echar un vistazo al proceso de bisección con "git bisect log" y "git bisect visualize".
"git bisect reset" lo sacará del modo bisect.

Tenga en cuenta que el primer estado "bueno" debe ser un antepasado del primer estado "malo". Si
quieres buscar el compromiso que resuelto algún error, tienes que negar tu caso de prueba
(es decir, salga con 1 si está bien y 0 si no) y aún marque el límite inferior como "bueno" y el
superior como "malo". El "primer compromiso incorrecto" debe entenderse como el "primer compromiso
donde se soluciona el error ".

"git help bisect" tiene mucha más información sobre cómo puedes modificar tus búsquedas binarias.

Tema sucursales y reescritura historia
Los confirmadores individuales deben crear ramas temáticas en yourname/algún_nombre_descriptivo.
Otros confirmadores deben consultar con el creador de una rama de tema antes de realizar cualquier cambio en
él.

La forma más sencilla de crear una rama de tema remota que funcione en todas las versiones de git es
Empuje el cabezal actual como una nueva rama en el control remoto, luego compruébelo localmente:

$ branch = "$ yourname / $ some_descriptive_name"
$ git push origin HEAD: $ branch
$ git checkout -b $ origen de la rama / $ rama

Los usuarios de git 1.7 o posterior pueden hacerlo de una manera más obvia:

$ branch = "$ yourname / $ some_descriptive_name"
$ git checkout -b $ branch
$ git push origin -u $ branch

Si no eres el creador de yourname/algún_nombre_descriptivo, a veces puedes encontrar
que el autor original ha editado el historial de la rama. Hay muchas buenas razones
para esto. A veces, un autor puede simplemente estar reorganizando la rama en una fuente más nueva.
punto. A veces, un autor puede haber encontrado un error en una confirmación temprana que
quería arreglar antes de fusionar la rama para sangrar.

Actualmente, el repositorio principal está configurado para prohibir fusiones que no sean de avance rápido. Esta
significa que las ramas internas no se pueden rebasar y empujar como un solo paso.

La única forma en que se le permitirá volver a establecer una base o modificar el historial de una rama enviada
es eliminarlo y enviarlo como una nueva rama con el mismo nombre. Por favor piensa con cuidado
sobre hacer esto. Puede ser mejor cambiar el nombre de las ramas secuencialmente para que sea
para los que trabajan con usted, es más fácil seleccionar sus cambios locales en el nuevo
versión. (XXX: necesita explicación).

Si desea volver a basar una rama de tema personal, tendrá que eliminar su tema existente
branch y push como una nueva versión del mismo. Puede hacerlo mediante la siguiente fórmula (consulte la
explicación sobre "refspec" en la documentación de git push para obtener más detalles) después de haber
reabasteció su rama:

# primer rebase
$ git checkout $ usuario / $ tema
$ git buscar
$ git rebase origin / blead

# luego "eliminar y presionar"
$ git push origin: $ usuario / $ tema
$ git push origin $ usuario / $ tema

NOTA: Está prohibido a nivel de repositorio eliminar cualquiera de las ramas "primarias".
Esa es cualquier rama que coincida con "m! ^ (Blead | maint | perl)!". Cualquier intento de hacerlo resultará en
git produciendo un error como este:

$ git push origin: blead
*** Está prohibido eliminar las ramas blead / maint en este repositorio
error: ganchos / actualización salió con el código de error 1
error: el gancho se negó a actualizar refs / heads / blead
Para ssh: //perl5.git.perl.org/perl
! [remoto rechazado] blead (gancho rechazado)
error: no se pudieron enviar algunas referencias a 'ssh: //perl5.git.perl.org/perl'

Como una cuestión de política lo hacemos No editar el historial de las ramas blead y maint- *. Si un
typo (o peor) se cuela en un commit para blead o maint- *, lo arreglaremos en otro commit.
Los únicos tipos de actualizaciones permitidas en estas ramas son las de "avance rápido", donde todas
se conserva la historia.

Las etiquetas anotadas en el repositorio canónico de perl.git nunca serán eliminadas ni modificadas.
Piense detenidamente si desea enviar una etiqueta local a perl.git antes de hacerlo.
entonces. (No se permite insertar etiquetas sin anotar).

Injertos
El historial de Perl contiene un error que no se detectó en la conversión: se produjo una fusión.
registrado en el historial entre blead y maint-5.10 donde no se produjo ninguna fusión. Vencer
a la naturaleza de git, esto ahora es imposible de arreglar en el repositorio público. Usted puede
elimine esta combinación errónea localmente agregando la siguiente línea a su ".git / info / grafts"
archivo:

296f12bbbbaa06de9be9d09d3dcf8f4528898a49 434946e0cb7a32589ed92d18008aaa1d88515930

Es particularmente importante tener esta línea de injerto si se realiza alguna bisección en el área
de la "fusión" en cuestión.

ESCRIBIR ACCESO A EL GIT REPOSITORIO

Una vez que tenga acceso de escritura, deberá modificar la URL del control remoto de origen para
habilitar empujar. Editar .git / config con el git-config(1) comando:

% git config remote.origin.url ssh: //perl5.git.perl.org/perl.git

También puede configurar su nombre de usuario y dirección de correo electrónico. La mayoría de la gente hace esto una vez a nivel mundial
en su ~ / .gitconfig haciendo algo como:

% git config --global user.name "AEvar Arnfjoer` Bjarmason"
% git config --usuario global.email [email protected]

Sin embargo, si desea anular eso solo para perl, ejecute algo como el
siguiendo en perl:

% git config usuario.email [email protected]

También es posible mantener "origin" como un control remoto de git y agregar un nuevo control remoto para el acceso ssh:

% git remoto agrega camel perl5.git.perl.org:/perl.git

Esto le permite actualizar su repositorio local extrayendo de "origen", que es más rápido
y no requiere que se autentique y que retroceda los cambios con el "camel"
remoto:

% git ir a buscar camello
% git empuja camello

El comando "buscar" solo actualiza las referencias "camello", ya que los propios objetos deberían tener
se ha obtenido al extraer desde "origen".

Aceptando a parche
Si ha recibido un archivo de parche generado utilizando la sección anterior, debería probar
el parche.

Primero necesitamos crear una nueva rama temporal para estos cambios y cambiar a ella:

% git pago -b experimental

Los parches formateados por "git format-patch" se aplican con "git am":

% git am 0001-Renombrar-Leon-Brocard-a-Orange-Brocard.patch
Aplicación de Rename Leon Brocard a Orange Brocard

Si solo se proporciona una diferencia sin formato, también es posible utilizar este proceso de dos pasos:

% git aplica bugfix.diff
% git commit -a -m "Algunos arreglos" --author = "Ese tipo[email protected]>"

Ahora podemos inspeccionar el cambio:

% git muestra CABEZA
commit b1b3dab48344cff6de4087efca3dbd63548ab5e2
Autor: Leon Brocard[email protected]>
Fecha: viernes 19 de diciembre 17:02:59 2008 +0000

Cambiar el nombre de Leon Brocard a Orange Brocard

diff --git a / AUTORES b / AUTORES
index 293dd70..722c93e 100644
--- a / AUTORES
+++ b / AUTORES
@@ -541,7 +541,7 @@ Lars Hecking[email protected]>
Laszlo Molnar[email protected]>
Leif Huhn[email protected]>
Len Johnson[email protected]>
-Leon Brocard[email protected]>
+ Brocard naranja[email protected]>
Les Peters[email protected]>
Lesley Binks[email protected]>
Lincoln D. Stein[email protected]>

Si se ha comprometido con Perl y cree que el parche es bueno, puede fusionarlo en
blead y luego envíalo al repositorio principal:

% git pago blead
% git fusionar experimental
% git empujar fuente de origen

Si desea eliminar su rama temporal, puede hacerlo con:

% git pago blead
% rama git -d experimental
error: La rama 'experimental' no es un antepasado de su HEAD actual.
Si está seguro de que desea eliminarlo, ejecute 'git branch -D experimental'.
% rama git -D experimental
Rama experimental eliminada.

Comprometidos a sangrar
La rama 'blead' se convertirá en la próxima versión de producción de Perl.

Antes de empujar cualquier cambio local para sangrar, es increíblemente importante que haga algunas
cosas, no sea que otros cometer vengan detrás de ti con horquillas y antorchas:

· Asegúrese de tener un buen mensaje de confirmación. Consulte "Confirmar mensaje" en perlhack para
Detalles.

· Ejecute el conjunto de pruebas. Es posible que no piense que una corrección de errores tipográficos rompería un archivo de prueba.
Estarías equivocado. A continuación, se muestra un ejemplo de los problemas causados ​​por no ejecutar la suite. A
Se envió un parche que agregó un par de pruebas a un .t existente. No pudo
posiblemente afecte a cualquier otra cosa, por lo que no es necesario realizar pruebas más allá del .t único afectado,
¿derecho? Pero, la dirección de correo electrónico del remitente había cambiado desde el último de sus
presentaciones, y esto provocó que otras pruebas fallaran. Ejecutando el objetivo de prueba dado en el
el siguiente elemento habría detectado este problema.

· Si no ejecuta el conjunto de pruebas completo, al menos "haga test_porting". Esto se ejecutará
controles básicos de cordura. Para ver qué controles de cordura, eche un vistazo a t / portando.

· Si realiza algún cambio que afecte a miniperl o rutinas centrales que tengan código diferente
rutas para miniperl, asegúrese de ejecutar "make minitest". Esto detectará problemas que
incluso el conjunto de pruebas completo no se detectará porque ejecuta un subconjunto de pruebas bajo
miniperl en lugar de perl.

On la fusión de y rebase
Las confirmaciones simples y únicas enviadas a la rama 'blead' deberían ser confirmaciones simples que se apliquen
limpiamente. En otras palabras, debe asegurarse de que su trabajo esté comprometido contra la corriente
posición de blead, para que pueda retroceder al repositorio principal sin fusionar.

A veces, el blead se moverá mientras construye o prueba sus cambios. Cuando esto
sucede, su envío será rechazado con un mensaje como este:

Para ssh: //perl5.git.perl.org/perl.git
! [rechazado] blead -> blead (sin avance rápido)
error: no se pudieron enviar algunas referencias a 'ssh: //perl5.git.perl.org/perl.git'
Para evitar que pierda el historial, se rechazaron las actualizaciones que no son de avance rápido
Fusionar los cambios remotos (por ejemplo, 'git pull') antes de presionar nuevamente. Ver el
'Nota sobre la sección de avance rápido' de 'git push --help' para obtener más detalles.

Cuando esto sucede, puedes simplemente rebase tu trabajo contra la nueva posición de blead, como
esto (asumiendo que su control remoto para el repositorio maestro es "p5p"):

$ git buscar p5p
$ git rebase p5p / blead

Verá que se vuelven a aplicar sus confirmaciones y, a continuación, podrá presionar de forma segura.
Puede encontrar más información sobre el rebase en la documentación de la git-rebase(1)
mando.

Para conjuntos más grandes de confirmaciones que solo tienen sentido en conjunto, o que se beneficiarían de una
resumen del propósito del conjunto, debe usar un compromiso de fusión. Deberías realizar tu trabajo
en una rama de tema, que debe rebasar regularmente contra blead para asegurarse de que su
el código no se rompe por el movimiento de la sangría. Cuando haya terminado su trabajo, realice una
rebase final y prueba. El historial lineal es algo que se pierde con cada compromiso en
blead, pero una rebase final hace que el historial vuelva a ser lineal, lo que facilita el futuro
mantenedores para ver qué ha sucedido. Rebase de la siguiente manera (asumiendo que su trabajo fue en el
rama "committer / somework"):

$ git checkout committer / somework
$ git rebase blead

Entonces puedes fusionarlo en maestro de esta manera:

$ git pago blead
$ git merge --no-ff --no-commit committer / somework
$ git confirmar -a

Los interruptores anteriores merecen una explicación. "--no-ff" indica que incluso si todo su trabajo
se puede aplicar linealmente contra blead, aún se debe preparar un compromiso de fusión. Esta
asegura que todo su trabajo se mostrará como una rama lateral, con todas sus confirmaciones fusionadas
en la corriente principal blead mediante el compromiso de fusión.

"--no-commit" significa que la confirmación de fusión será preparado pero no comprometido. El compromiso
luego se realiza cuando ejecuta el siguiente comando, que abrirá su editor
para describir el compromiso. Sin "--no-commit", la confirmación se realizaría casi sin
mensaje útil, que disminuiría en gran medida el valor de la combinación de confirmación como un
marcador de posición para la descripción del trabajo.

Al describir la confirmación de fusión, explique el propósito de la rama y tenga en cuenta que
esta descripción probablemente será utilizada por el ingeniero de lanzamiento eventual al revisar el
siguiente documento perldelta.

Comprometidos a mantenimiento versiones
Las versiones de mantenimiento solo deben modificarse para agregar correcciones de errores críticos, consulte perlpolicy.

Para comprometerse con una versión de mantenimiento de perl, debe crear una rama de seguimiento local:

% git checkout --track -b maint-5.005 origin / maint-5.005

Esto crea una sucursal local llamada "maint-5.005", que rastrea la sucursal remota
"origen / mantenimiento-5.005". Luego, puede tirar, comprometer, fusionar y empujar como antes.

También puede seleccionar confirmaciones de blead y otra rama, utilizando el comando "git
comando cherry-pick ". Se recomienda utilizar el -x opción de "git cherry-pick" en orden
para registrar el SHA1 de la confirmación original en el nuevo mensaje de confirmación.

Antes de presionar cualquier cambio a una versión de mantenimiento, asegúrese de haber cumplido con los pasos en
"Comprometerse a sangrar" arriba.

La fusión de Desde a biblioteca vía GitHub
Si bien no alentamos el envío de parches a través de GitHub, eso seguirá sucediendo.
Aquí hay una guía para fusionar parches de un repositorio de GitHub.

% git remote agrega avar git: //github.com/avar/perl.git
% git obtener avar

Ahora puede ver las diferencias entre la rama y el blead:

% git diff avar / naranja

Y puedes ver las confirmaciones:

% git log avar / naranja

Si aprueba una confirmación específica, puede elegirla:

% git cherry-pick 0c24b290ae02b2ab3304f51d5e11e85eb3659eae

O simplemente puede fusionar toda la rama si le gusta todo:

% git fusionar avar / naranja

Y luego regrese al repositorio:

% git empujar fuente de origen

Usando a fumarme biblioteca a compruébalo cambios
A veces, un cambio afecta las rutas de código que no puede probar en los sistemas operativos que están directamente
disponible para usted y sería prudente que los usuarios de otros sistemas operativos prueben el cambio antes
lo comprometes a sangrar.

Afortunadamente, hay una manera de hacer que su cambio sea probado en varios sistemas operativos: empújelo a un
rama "fumeme" y espere a que ciertos probadores de humo automáticos informen los resultados de
sus sistemas operativos.

El procedimiento para hacer esto es aproximadamente el siguiente (usando el ejemplo de la técnica de humo de Tonyc).
mi rama llamada win32stat):

Primero, cree una sucursal local y cámbiese a ella:

% git pago -b win32stat

Realice algunos cambios, compile perl y pruebe sus cambios, luego confíelos a su
rama. Luego empuje su sucursal local a una sucursal remota de fumarme:

% git push origin win32stat: smoke-me / tonyc / win32stat

Ahora puede volver a blead localmente:

% git pago blead

y continúe trabajando en otras cosas mientras espera uno o dos días, vigilando la
resultados reportados para su sucursal de smoke-me en
<http://perl.develop-help.com/? b = fumeme / tonyc / win32state>.

Si todo está bien, actualice su rama blead:

% extracción de git

luego revisa tu rama de fumarme una vez más y vuelve a basarla en blead:

% git rebase blead win32stat

Ahora vuelve a blead y fusiona tu rama de fumarme en ella:

% git pago blead
% git fusionar win32stat

Como se describió anteriormente, si hay muchos cambios en su rama fumeme, entonces debe
preparar un compromiso de fusión en el que dar una descripción general de esos cambios mediante el uso de la
siguiente comando en lugar del último comando anterior:

% git merge win32stat --no-ff --sin compromiso

Ahora debe compilar perl y probar sus cambios (combinados) una última vez (lo ideal es ejecutar el
todo el conjunto de pruebas, pero en su defecto, al menos ejecute el t / porting / *. t pruebas) antes de empujar
sus cambios como de costumbre:

% git empujar fuente de origen

Finalmente, debe eliminar la rama remota de smoke-me:

% git push origen: smoke-me / tonyc / win32stat

(que probablemente produzca una advertencia como esta, que puede ignorarse:

remoto: fatal: argumento ambiguo 'refs / heads / smoke-me / tonyc / win32stat':
revisión desconocida o ruta que no está en el árbol de trabajo.
remoto: use '-' para separar las rutas de las revisiones

) y luego elimine su sucursal local:

% rama git -d win32stat

A nota on camello y dromedario
Los confirmadores tienen acceso SSH a los dos servidores que sirven a "perl5.git.perl.org". Uno es
"perl5.git.perl.org" en sí (camello), que es el repositorio 'maestro'. El segundo es
"users.perl5.git.perl.org" (dromedario), que se puede utilizar para pruebas generales y
desarrollo. Dromedary sincroniza el árbol git de camel cada pocos minutos, no deberías
empujar allí. Ambas máquinas también tienen un espejo CPAN completo en / srv / CPAN, por favor use esto. A
compartir archivos con el público en general, dromedario sirve a su ~ / public_html / as
"http://users.perl5.git.perl.org/~yourlogin/"

Estos hosts tienen cortafuegos bastante estrictos hacia el exterior. Saliente, solo rsync, ssh y git
están permitidos. Para http y ftp, puede usar http://webproxy: 3128 como proxy. Entrante, el
El firewall intenta detectar ataques y bloquea las direcciones IP con actividad sospechosa. Esta
a veces (pero muy raramente) tiene falsos positivos y es posible que se bloquee. Lo más rápido
La forma de desbloquearse es notificar a los administradores.

Estas dos cajas son propiedad, están alojadas y operadas por booking.com. Puedes llegar al
administradores de sistemas en # p5p en irc.perl.org o por correo a "[email protected]".

Use perlgit en línea usando los servicios de onworks.net