git: 8d76cf92e8 - main - [doc-es][articles/committers-guide] Translate.

The branch main has been updated by fernape:

URL: https://cgit.FreeBSD.org/doc/commit/?id=8d76cf92e8ebf82f8f7557216638eae41d183183

commit 8d76cf92e8ebf82f8f7557216638eae41d183183
Author:     Fernando Apesteguía <fernape@FreeBSD.org>
AuthorDate: 2022-10-03 11:10:33 +0000
Commit:     Fernando Apesteguía <fernape@FreeBSD.org>
CommitDate: 2022-10-03 16:45:43 +0000

    [doc-es][articles/committers-guide] Translate.
    
    Translate Committer's Guide.
---
 .../es/articles/committers-guide/_index.adoc       |  3433 +++++
 .../content/es/articles/committers-guide/_index.po | 13270 +++++++++++++++++++
 2 files changed, 16703 insertions(+)

diff --git a/documentation/content/es/articles/committers-guide/_index.adoc b/documentation/content/es/articles/committers-guide/_index.adoc
new file mode 100644
index 0000000000..11e2c32991
--- /dev/null
+++ b/documentation/content/es/articles/committers-guide/_index.adoc
@@ -0,0 +1,3433 @@
+---
+authors:
+  - 
+    author: 'The FreeBSD Documentation Project'
+copyright: '1999-2021 The FreeBSD Documentation Project'
+description: 'Información de introducción para los committers de FreeBSD'
+tags: ["FreeBSD Committer's Guide", "Guide", "Community"]
+title: 'Guía para los Committers'
+trademarks: ["freebsd", "coverity", "ibm", "intel", "general"]
+weight: 25
+---
+
+= Guía para los Committers
+:doctype: article
+:toc: macro
+:toclevels: 1
+:icons: font
+:sectnums:
+:sectnumlevels: 6
+:source-highlighter: rouge
+:experimental:
+:images-path: articles/committers-guide/
+
+ifdef::env-beastie[]
+ifdef::backend-html5[]
+include::shared/authors.adoc[]
+include::shared/mirrors.adoc[]
+include::shared/releases.adoc[]
+include::shared/attributes/attributes-{{% lang %}}.adoc[]
+include::shared/{{% lang %}}/teams.adoc[]
+include::shared/{{% lang %}}/mailing-lists.adoc[]
+include::shared/{{% lang %}}/urls.adoc[]
+:imagesdir: ../../../images/{images-path}
+endif::[]
+ifdef::backend-pdf,backend-epub3[]
+include::../../../../shared/asciidoctor.adoc[]
+endif::[]
+endif::[]
+
+ifndef::env-beastie[]
+include::../../../../../shared/asciidoctor.adoc[]
+endif::[]
+
+[.abstract-title]
+Resumen
+
+Este documento proporciona información para la comunidad de committers de FreeBSD. Todos los committers nuevos deben leer este documento antes de empezar, y se recomienda encarecidamente a los committers actuales que lo revisen de vez en cuando.
+
+Casi todos los desarrolladores de FreeBSD tienen derecho de acceso a uno o más repositorios. Sin embargo, algunos desarrolladores no lo tienen, y cierta información aquí expuesta también les afecta. (Por ejemplo, algunas personas sólo tienen derecho a trabajar con la base de datos de reporte de problemas). Por favor lea <<non-committers>> para más información.
+
+Este documento también puede ser de interés para los miembros de la comunidad de FreeBSD que quieran saber más sobre el funcionamiento del proyecto.
+
+'''
+
+toc::[]
+
+[[admin]]
+== Detalles administrativos
+
+[.informaltable]
+[cols="1,1", frame="none"]
+|===
+
+|_Métodos de inicio de sesión_
+|man:ssh[1], sólo protocolo 2
+
+|_Host Shell Principal_
+|`freefall.FreeBSD.org`
+
+|_Máquinas de Referencia_
+|`ref*.FreeBSD.org`, `universe*.freeBSD.org` (consulta también link:https://www.FreeBSD.org/internal/machines/[Máquinas del Proyecto FreeBSD])
+
+|_SMTP Host_
+|`smtp.FreeBSD.org:587` (consulta también <<smtp-setup>>).
+
+|`_src/_` Repositorio Git
+|`ssh://git@gitrepo.FreeBSD.org/src.git` (consulta también <<git-getting-started-base-layout>>).
+
+|`_doc/_` Repositorio Git
+|`ssh://git@gitrepo.FreeBSD.org/doc.git` (consulta también <<git-getting-started-doc-layout>>).
+
+|`_ports/_` Repositorio Git
+|`ssh://git@gitrepo.FreeBSD.org/ports.git` (consulta también <<git-getting-started-ports-layout>>).
+
+|_Listas de Correo Internas_
+|developers (técnicamente llamada all-developers) doc-developers, doc-committers, ports-developers, ports-committers, src-developers, src-committers. (Cada repositorio del proyecto tiene su propia lista de correo terminada en -developers y -committers. Se pueden encontrar archivos para estas listas en los ficheros [.filename]#/local/mail/repository-name-developers-archive# y [.filename]#/local/mail/repository-name-committers-archive# en el cluster `FreeBSD.org`.)
+
+|_Informes mensuales del Core Team_
+|[.filename]#/home/core/public/monthly-reports# en el clúster `FreeBSD.org`.
+
+|_Informes mensuales del Ports Management Team_
+|[.filename]#/home/portmgr/public/monthly-reports# en el clúster `FreeBSD.org`.
+
+|_Notablemente Ramas de Git de `src/`:_
+|`stable/n` (`n`-STABLE), `main` (-CURRENT)
+|===
+
+Se requiere man:ssh[1] para conectarse a los servidores del proyecto. Para más información, lea <<ssh.guide>>.
+
+Enlaces de interés:
+
+* link:https://www.FreeBSD.org/internal/[Páginas Internas del Proyecto FreeBSD]
+* link:https://www.FreeBSD.org/internal/machines/[Servidores del Proyecto FreeBSD]
+* link:https://www.FreeBSD.org/administration/[Grupos Administrativos del Proyecto FreeBSD]
+
+[[pgpkeys]]
+== Claves OpenPGP de FreeBSD
+
+Claves criptográficas que siguen al estándar OpenPGP (__Pretty Good Privacy__) son utilizadas por el Proyecto FreeBSD para autentificar a los colaboradores. Mensajes que contengan información importante como claves SSH públicas pueden ser firmadas con una clave OpenPGP para demostrar que provienen realmente del colaborador. Véase https://nostarch.com/releases/pgp_release.pdf[PGP & GPG: Email for the Practical Paranoid by Michael Lucas] y http://en.wikipedia.org/wiki/Pretty_Good_Privacy[] para más información.
+
+[[pgpkeys-creating]]
+=== Creando una clave
+
+Se pueden utilizar claves ya existentes, pero primero deberían ser comprobadas primero con [.filename]#documentation/tools/checkkey.sh#. En este caso, comprueba que la clave tiene un identificador de usuario de FreeBSD.
+
+Para aquellos que todavía no tengan una clave OpenPGP, o necesiten una nueva para reunir los requerimientos de seguridad de FreeBSD, se mostrará a continuación como generarla.
+
+[[pgpkeys-create-steps]]
+[.procedure]
+====
+. Instala [.filename]#security/gnupg#. Inserta las siguientes líneas en [.filename]#~/.gnupg/gpg.conf# para establecer valores aceptables por defecto:
++
+[.programlisting]
+....
+fixed-list-mode
+keyid-format 0xlong
+personal-digest-preferences SHA512 SHA384 SHA256 SHA224
+default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed
+verify-options show-uid-validity
+list-options show-uid-validity
+sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
+cert-digest-algo SHA512
+....
+. Genera una clave:
++
+[source, shell]
+....
+% gpg --full-gen-key
+gpg (GnuPG) 2.1.8; Copyright (C) 2015 Free Software Foundation, Inc.
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.
+
+Warning: using insecure memory!
+Please select what kind of key you want:
+   (1) RSA and RSA (default)
+   (2) DSA and Elgamal
+   (3) DSA (sign only)
+   (4) RSA (sign only)
+Your selection? 1
+RSA keys may be between 1024 and 4096 bits long.
+What keysize do you want? (2048) 2048 <.>
+Requested keysize is 2048 bits
+Please specify how long the key should be valid.
+	 0 = key does not expire
+      <n>  = key expires in n days
+      <n>w = key expires in n weeks
+      <n>m = key expires in n months
+      <n>y = key expires in n years
+Key is valid for? (0) 3y <.>
+Key expires at Wed Nov  4 17:20:20 2015 MST
+Is this correct? (y/N) y
+GnuPG needs to construct a user ID to identify your key.
+
+Real name: Chucky Daemon <.>
+Email address: notreal@example.com
+Comment:
+You selected this USER-ID:
+"Chucky Daemon <notreal@example.com>"
+
+Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
+You need a Passphrase to protect your secret key.
+....
+
+<.> Claves de 2048 bits con una expiración de tres años proporcionan una protección adecuada actualmente (2013-12). http://danielpocock.com/rsa-key-sizes-2048-or-4096-bits[] describe la situación en más detalle.
+
+<.> Tres años de vida útil para una clave hacen que sea lo suficientemente corta como para hacer que quede obsoleta por el avance de la potencia de los ordenadores, pero lo suficientemente larga como para reducir los problemas de administración de claves.
+
+<.> Utiliza tu nombre real aquí, preferiblemente coincidente con el nombre de tu documento de identificación oficial para ayudar a otros a verificar tu identidad. En la sección `Comment` se puede introducir texto que ayude a otros a identificarte.
++
+Después de introducir la dirección de correo electrónico, se solicita una contraseña. Los métodos para crear una contraseña segura son bastante polémicos. En lugar de sugerir una única forma, aquí hay algunos enlaces a sitios que describen varios métodos: http://world.std.com/~reinhold/diceware.html[], http://www.iusmentis.com/security/passphrasefaq/[], http://xkcd.com/936/[], http://en.wikipedia.org/wiki/Passphrase[].
+====
+
+Protege la clave privada y la contraseña. Si la clave privada o la contraseña fueran comprometidas o reveladas, notifícalo de forma inmediata a mailto:accounts@FreeBSD.org[accounts@FreeBSD.org] y revoca la clave.
+
+Los pasos para enviar la nueva clave se muestran en <<commit-steps, Pasos para los Nuevos Committers>>.
+
+[[kerberos-ldap]]
+== Kerberos y contraseña web LDAP para el clúster de FreeBSD
+
+El clúster de FreeBSD requiere una contraseña de Kerberos para acceder a ciertos servicios. La contraseña de Kerberos también sirve como contraseña web LDAP, ya que LDAP hace de proxy a Kerberos en el clúster. Algunos de los servicios que requieren esto incluyen:
+
+* https://bugs.freebsd.org/bugzilla[Bugzilla]
+* https://ci.freebsd.org[Jenkins]
+
+Para crear una nueva cuenta de Kerberos en el clúster de FreeBSD, o para restablecer una contraseña de Kerberos para una cuenta existente utilizando un generador de contraseñas aleatorias:
+
+[source, shell]
+....
+% ssh kpasswd.freebsd.org
+....
+
+[NOTE]
+====
+Esto debe hacerse desde una máquina fuera del clúster de FreeBSD.org.
+====
+
+Una contraseña de Kerberos también puede ser establecida manualmente iniciando sesión en `freefall.FreeBSD.org` y ejecutando:
+
+[source, shell]
+....
+% kpasswd
+....
+
+[NOTE]
+====
+A menos que los servicios autentificados con Kerberos del clúster de FreeBSD.org hayan sido usados previamente, se mostrará `Client unknown`. Este error significa que el método de `ssh kpasswd.freebsd.org` mostrado previamente tendrá que ser usado para inicializar la cuenta de Kerberos.
+====
+
+[[committer.types]]
+== Tipos de Commit Bits
+
+El repositorio de FreeBSD tiene una serie de componentes que, cuando se combinan, integran el código fuente del sistema base del sistema operativo, la documentación, la infraestructura de ports de las aplicaciones de terceros y varias utilidades mantenidas. Cuando se asignan los commit bits, se especifican las áreas del árbol donde se tiene permiso. Generalmente, las áreas asociadas con un commit bit reflejan quién autorizó la asignación del commit bit. Se pueden agregar más áreas de autoridad posteriormente: cuando esto ocurre, el committer debe seguir los procedimientos normales de asignación de commit bit para esa área del árbol, buscar la aprobación de la entidad apropiada y posiblemente obtener un mentor para esa área durante un cierto periodo de tiempo.
+
+[.informaltable]
+[cols="1,1,1", frame="none"]
+|===
+
+|Tipos de Commiters
+|__Responsable__
+|__Componentes del Árbol__
+
+|src
+|core@
+|src/
+
+|doc
+|doceng@
+|doc/, ports/, src/ documentación
+
+|ports
+|portmgr@
+|ports/
+|===
+
+Los commit bits asignados antes de que se desarrollara la idea de áreas de autoridad, pueden ser apropiados para su uso en muchas partes del árbol. Sin embargo, el sentido común dicta que un committer que no haya trabajado previamente en esa área del árbol busque una revisión antes de realizar el commit, busque la aprobación del equipo responsable, y/o trabaje con un mentor. Dado que las reglas con respecto al mantenimiento del código difieren según el área del árbol, esto beneficiará tanto a quién trabaja en un área del árbol con la que no está muy familiarizado como a quienes trabajan en el árbol.
+
+Se anima a los committers a buscar la revisión de su trabajo como parte del proceso natural del desarrollo, independientemente del área del árbol en la cual se esté realizando el trabajo.
+
+=== Política para la actividad de los Committers en otros árboles
+
+* Todos los committers pueden modificar [.filename]#src/share/misc/committers-*.dot#, [.filename]#src/usr.bin/calendar/calendars/calendar.freebsd#, y [.filename]#ports/astro/xearth/files#.
+* Los committers de documentación pueden realizar commits en la documentación de [.filename]#src#, como las páginas man, READMEs, bases de datos de fortune, archivos de calendario y correcciones de comentarios sin la aprobación de un src committer, teniendo en cuenta las normas requeridas para la correcta realización de los commits.
+* Cualquier committer puede realizar cambios en cualquier otro árbol con un "Approved by" de un committer que no esté tutelado y dispone del commit bit apropiado. Los committers con mentor pueden proporcionar un comentario "Reviewed by" pero no un "Approved by".
+* Los committers pueden adquirir commit bit adicionales mediante el proceso habitual de encontrar a un mentor que lo proponga a core, doceng o portmgr, según sea el caso. Una vez aprobados, se añadirán al "acceso" y se producirá el periodo normal de tutoría, que implicará una continuación de "Approved by" durante algún tiempo.
+
+[[doc-blanket-approval]]
+==== Aprobación Implícita (Blanket) de Documentación
+
+Algunos arreglos tienen "blanket approval" por parte de {doceng}, permitiendo a cualquier committer arreglar ese tipo de problemas en cualquier parte del árbol de documentación. Estos arreglos no necesitan aprobación o revisión por parte de un committer de documentación si el autor no tiene un commit bit de documentación.
+
+El blanket approval aplica en estos tipos de arreglos:
+
+* Faltas de ortografía
+* Arreglos triviales
++
+Puntuación, URLs, fechas, rutas y nombres de fichero con información desactualizada o incorrecta, y otros errores comunes que puedan confundir a los lectores.
+
+A lo largo de los años, se han concedido algunas aprobaciones implícitas en el árbol de documentación. Esta lista muestra los casos más comunes:
+
+* Cambios en [.filename]#documentation/content/en/books/porters-handbook/versions/_index.adoc#
++
+extref:{porters-handbook}versions/[__FreeBSD_version Values (Porter's Handbook)], utilizado principalmente por committers de src.
+* Cambios en [.filename]#doc/shared/contrib-additional.adoc#
++
+Mantenimiento de extref:{contributors}[Colaboradores Adicionales de FreeBSD, contrib-additional].
+* Todo link:#commit-steps[Pasos para los Nuevos Committers], relacionado con documentación
+* Avisos de seguridad; Notas de Errata; Releases;
++
+Utilizado por {security-officer} y {re}.
+* Cambios en [.filename]#website/content/en/donations/donors.adoc#
++
+Utilizado por el {donations}.
+
+Antes de un commit, es necesario comprobar la compilación; consulta las secciones de 'Overview' y 'The FreeBSD Documentation Build Process' de extref:{fdp-primer}[Introducción al Proyecto de Documentación de FreeBSD para Nuevos Voluntarios] para más detalles.
+
+[[git-primer]]
+== Introducción a Git
+
+[[git-basics]]
+=== Git básico
+
+Cuando uno busca "Introducción a Git" aparecen unos cuantos buenos las introducciones de Daniel Miessler link:https://danielmiessler.com/study/git/[A git primer] y de Willie Willus link:https://gist.github.com/williewillus/068e9a8543de3a7ef80adb2938657b6b[Git - Quick Primer] son ambas buenas. El libro de Git también es completo, pero mucho más largo https://git-scm.com/book/en/v2. También hay un sitio web https://dangitgit.com/ para errores comunes y problemas de Git, en caso de que necesites ayuda para arreglar algo. Por último una introducción link:https://eagain.net/articles/git-for-computer-scientists/[dirigida a científicos computacionales] ha demostrado ser útil para algunos a la hora de explicar cómo Git ve el mundo.
+
+Este documento asumirá que lo has leído y tratará de no insistir en lo básico (aunque lo cubrirá brevemente).
+
+[[git-mini-primer]]
+=== Mini Introducción a Git
+
+Esta introducción tiene un ámbito menos ambicioso que la antigua Introducción a Subversion, pero debería cubrir lo básico.
+
+==== Ámbito
+
+Si quieres descargar FreeBSD, compilarlo desde las fuentes, y en general mantenerte actualizado de ese modo, esta introducción es para ti. Cubre cómo obtener las fuentes, actualizarlas, hacer bisección y trata brevemente cómo lidiar con unos pocos cambios locales. Cubre lo básico y trata de dar buenos consejos para un tratamiento más en profundidad para cuando el lector encuentre lo básico insuficiente. Otras secciones de esta guía cubren temas más avanzados relacionados con cómo contribuir al proyecto.
+
+El objetivo de esta sección es resaltar aquellas partes de Git que se necesitan para seguir la pista a las fuentes. Asumen un conocimiento básico de Git. Hay muchas introducciones de Git en la web, pero el https://git-scm.com/book/en/v2[Git Book] proporciona una de las mejores.
+
+[[git-mini-primer-getting-started]]
+==== Primeros Pasos Para Desarrolladores
+
+Esta sección describe el acceso de lectura-escritura para que los committers hagan push de los commits de los desarrolladores o colaboradores.
+
+===== Uso diario
+
+* Clona el repositorio:
++
+[source, shell]
+....
+% git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://git.freebsd.org/${repo}.git
+....
++
+Después deberías tener tu remote apuntando a los mirrors oficiales:
++
+[source, shell]
+....
+% git remote -v
+freebsd  https://git.freebsd.org/${repo}.git (fetch)
+freebsd  https://git.freebsd.org/${repo}.git (push)
+....
+
+* Configura los datos del committer de FreeBSD:
++
+El commit hook en repo.freebsd.org comprueba que el campo "Commit" coincide con la información del committer en FreeBSD.org. La forma más fácil de conseguir la configuración sugerida es ejecutar el script `/usr/local/bin/gen-gitconfig.sh` en freefall:
++
+[source, shell]
+....
+% gen-gitconfig.sh
+[...]
+% git config user.name (your name in gecos)
+% git config user.email (your login)@FreeBSD.org
+....
+
+* Establece la URL para hacer push:
++
+[source, shell]
+....
+% git remote set-url --push freebsd git@gitrepo.freebsd.org:${repo}.git
+....
++
+Después deberías tener URLs separadas para fetch y push que es la configuración más eficiente:
++
+[source, shell]
+....
+% git remote -v
+freebsd  https://git.freebsd.org/${repo}.git (fetch)
+freebsd  git@gitrepo.freebsd.org:${repo}.git (push)
+....
++
+De nuevo, date cuenta de que `gitrepo.freebsd.org` cambiará a la forma canónica `repo.freebsd.org` en el futuro.
+
+* Instala el hook para la plantilla del mensaje de commit:
++
+[source, shell]
+....
+% fetch https://cgit.freebsd.org/src/plain/tools/tools/git/hooks/prepare-commit-msg -o .git/hooks
+% chmod 755 .git/hooks/prepare-commit-msg
+....
+
+[[admin-branch]]
+===== rama "admin"
+
+Los ficheros `access` y `metors` se almacenan en una rama huérfana, `internal/admin`, en cada repositorio.
+
+El siguiente ejemplo muestra cómo obtener la rama `internal/admin` en una rama local `admin`:
+
+[source, shell]
+....
+% git config --add remote.freebsd.fetch '+refs/internal/*:refs/internal/*'
+% git fetch
+% git checkout -b admin internal/admin
+....
+De forma alternativa, puedes añadir un árbol de trabajo (worktree) para la rama `admin`:
+
+[source, shell]
+....
+git worktree add -b admin ../${repo}-admin internal/admin
+....
+
+Para visualizar la rama `internal/admin` en la web: https://cgit.freebsd.org/${repo}/log/?h=internal/admin
+
+Para hacer push, especifica el refspec completo:
+
+[source, shell]
+....
+git push freebsd HEAD:refs/internal/admin
+....
+
+O establece `push.default` a `freebsd` que hará que `git push` empuje la rama actual de vuelta a su upstream por defecto, lo que es más conveniente para nuestro flujo de trabajo:
+
+[source, shell]
+....
+git config push.default freebsd
+....
+
+==== Mantenerse Actualizado Con el Árbol src de FreeBSD
+[[keeping_current]]
+Primer paso: clonar un árbol. Esto descarga el árbol completo. Hay dos formas de hacerlo. La mayoría de la gente quiere hacer un clonado profundo del repositorio. Sin embargo, hay momentos en los que quieres hacer un clonado superficial.
+
+===== Nombres de las ramas
+Los nombres de las ramas en el nuevo repositorio Git son similares a los nombres antiguos. Para las ramas estables, existe stable/X donde X es el número mayor de release (como 11 o 12). La rama principal en el nuevo repositorio es 'main'. La rama principal en el antiguo mirror de GitHub era 'master', pero ahora es 'main'. Ambas reflejan los valores por defecto de Git en el momento en que fueron creadas. La rama 'main' es la rama por defecto si omites las opciones '-b branch' o '--branch branch' abajo.
+
+===== Repositorios
+Por favor consulta <<admin,Detalles Administrativos>> para la última información sobre dónde obtener las fuentes de FreeBSD. El $URL que se muestra abajo se puede obtener en esa página.
+
+Nota: El proyecto no utiliza submódulos ya que no encajan en nuestro flujo de trabajo y modelo de desarrollo. Cómo seguimos la pista a los cambios en las aplicaciones de terceros se discute en otro sitio y en general no es de interés para un usuario casual.
+
+===== Clonado Profundo
+Un clonado profundo se trae el árbol entero, así como las ramas y toda la historia. Es lo más fácil de hacer. También te permite usar la característica de los árboles de trabajo para tener todas tus ramas activas en directorios separados pero con una sola copia del repositorio.
+[source, shell]
+....
+% git clone -o freebsd $URL -b branch [dir]
+....
+es como haces un clonado profundo. 'branch' debería ser una de las ramas listadas en la sección anterior. Es opcional si es la rama principal. 'dir' es un directorio opcional donde dejar el clon (por defecto será el nombre del repo que estás clonando (src, doc, etc)).
+
+Querrás un clonado profundo si estás interesado en el histórico, planeas hacer cambios locales, o planeas trabajar en más de una rama. Es la forma más fácil también de mantenerse actualizado. Si estás interesado en el histórico pero vas a trabajar sólo con una rama y andas corto de espacio, también puedes usar --single-branch para descargar la rama (aunque algunos commits de merge no referenciarán la rama desde la que se mergearon lo que podría ser importante para algunos usuarios interesados en versiones detalladas del histórico).
+
+===== Clonado Superficial
+
+Un clonado superficial sólo copia el código más actual, pero nada o poco del histórico. Esto puede ser útil cuando necesitas construir una revisión específica de FreeBSD o cuando simplemente estás empezando y planeas seguir la pista al árbol de forma más completa. También puedes usarlo para limitar el histórico a un número determinado de revisiones. Sin embargo, lee más abajo para una limitación importante a esta aproximación.
+
+[source, shell]
+....
+% git clone -o freebsd -b branch --depth 1 $URL [dir]
+....
+
+Esto clona el repositorio, pero sólo la versión más reciente. El resto del histórico no se descarga. Si cambiaras de opinión más tarde, puedes hacer 'git fetch --unshallow' para obtener el histórico antiguo.
+
+[WARNING]
+====
+Cuando haces un clonado superficial, pierdes el contador de commits en la salida de uname. Esto puede hacer más difícil determinar si tu sistema necesita ser actualizado cuando se notifica un aviso de seguridad.
+====
+
+===== Compilando
+
+Una vez que has descargado, la compilación se hace como se describe en el manual, por ejemplo.:
+[source, shell]
+....
+% cd src
+% make buildworld
+% make buildkernel
+% make installkernel
+% make installworld
+....
+de forma que no lo cubriremos en profundidad.
+
+Si quieres construir un kernel personalizado, extref:{handbook}[la sección de configuración del kernel, kernelconfig] del FreeBSD Handbook recomienda crear un fichero MYKERNEL bajo sys/${ARCH}/conf con tus cambios contra GENERIC. Para que Git ignore MYKERNEL, se puede añadir a .git/info/exclude.
+
+===== Actualización
+
+Para actualizar ambos tipos de árbol utilizan los mismos comandos. Esto se trae todas las revisiones desde tu última actualización.
+[source, shell]
+....
+% git pull --ff-only
+....
+actualizará el árbol. En Git, un merge tipo 'fast forward' es aquel que sólo necesita establecer el puntero a una rama nueva y no necesita recrear los commits. Haciendo siempre un merge/pull de tipo 'fast forward', te asegurarás de que tienes una copia exacta del árbol de FreeBSD. Esto será importante si quieres mantener parches locales.
+
+Lee más abajo para saber cómo gestionar cambios locales. Lo más sencillo es utilizar --autostash con el comando 'git pull', pero hay disponibles opciones más sofisticadas.
+
+==== Seleccionando una Versión Específica
+
+En Git, 'git checkout' se trae tanto ramas como versiones específicas. Las versiones de Git son hashes largos en lugar de números secuenciales.
+
+Cuando te traes una versión específica, simplemente especifica en la línea de comando el hash que quieres (el comando git log te ayudará a decidir cuál es el hash que quieres):
+[source, shell]
+....
+% git checkout 08b8197a74
+....
+y ya te lo has traído. Se te saludará con un mensaje como el siguiente:
+[source, shell]
+....
+Note: checking out '08b8197a742a96964d2924391bf9fdfeb788865d'.
+
+You are in a 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -b with the checkout command again. Example:
+
+  git checkout -b <new-branch-name>
+
+HEAD is now at 08b8197a742a hook gpiokeys.4 to the build
+....
+donde la última línea es generada a partir del hash que te has traído y la primera línea del mensaje de commit de esa revisión. El hash se puede abreviar a la longitud única más corta que exista. Git es inconsistente acerca de cuántos dígitos muestra.
+
+==== Bisección
+A veces, algo va mal. La última versión funcionó pero la última a la que te has actualizado no. Un desarrollador podría pedirte que bisecciones el problema para localizar qué commit causó la regresión.
+
+Git hacer fácil biseccionar cambios con un potente comando 'git bisect'. Aquí hay una breve introducción a cómo usarlo. Para más información, puedes ver https://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination o https://git-scm.com/docs/git-bisect para más detalles. La página de manual de git-bisect es buena describiendo lo que puede salir mal, qué hacer cuando las versiones no compilan, cuándo quieres usar otros términos diferentes de 'bueno' y 'malo', etc, nada de lo cual se cubrirá aquí.
+
+`git bisect start --first-parent` comenzará el proceso de bisección. Después necesitarás decirle un rango para que trabaje. 'git bisect good XXXXXX' le dirá la revisión que funciona y 'git bisect bad XXXXX' le dirá la revisión mala. La revisión mala casi siempre será HEAD (un tag especial para lo que te has traído). La versión buena será la última que te trajiste. El argumento `--first-parent` es necesario para que llamadas siguientes a `git bisect` no intenten traerse una rama externa que carece de las fuentes completas de FreeBSD.
+
+[TIP]
+====
+Si quieres saber la última versión que te trajiste, deberías usar 'git reflog':
+[source, shell]
+....
+5ef0bd68b515 (HEAD -> main, freebsd/main, freebsd/HEAD) HEAD@{0}: pull --ff-only: Fast-forward
+a8163e165c5b (upstream/main) HEAD@{1}: checkout: moving from b6fb97efb682994f59b21fe4efb3fcfc0e5b9eeb to main
+...
+....
+me muestra moviendo el directorio de trabajo a la rama principal (a816...) y después actualizando desde el origen (a 5ef0...). En esta caso, malo sería HEAD (o 5rf0bd68) y bueno sería a8163e165. Como puedes ver en la salida, HEAD@{1} también funciona, pero no es a prueba de fallos si has hecho otras cosas en tu árbol después de actualizar, pero antes de que descubrieras que tenías que hacer bisección.
+====
+
+Primero establece la versión 'good', luego la mala (aunque el orden no importa). Cuando establezcas la versión mala, te dará algunas estadísticas sobre el proceso:
+[source, shell]
+....
+% git bisect start --first-parent
+% git bisect good a8163e165c5b
+% git bisect bad HEAD
+Bisecting: 1722 revisions left to test after this (roughly 11 steps)
+[c427b3158fd8225f6afc09e7e6f62326f9e4de7e] Fixup r361997 by balancing parens.  Duh.
+....
+
+Después deberías compilar/instalar esa versión. Si es buena, teclearías 'git bisect good' si no 'git bisect bad'. Si la versión no compila, teclea 'git bisect skip'. Recibirás un mensaje similar al de arriba para cada paso. Una vez que hayas terminado, informa al desarrollador de la versión mala (o arregla el fallo tú mismo y envía un parche). 'git bisect reset' terminará el proceso y te devolverá a donde empezaste (normalmente a la punta de main). De nuevo, el manual de git-bisect (enlazado arriba) es un buen recurso para cuando las cosas van mal o en casos inusuales.
+
+[[git-gpg-signing]]
+==== Firmando los commits, tags, y pushes, con GnuPG
+
+Git sabe cómo firmar commits, tags y pushes. Cuando firmas un commit o tag de Git, puedes probar que el código que enviaste vino de ti y que no fue alterado mientras lo transferías. También puedes probar que tú enviaste el código y no otra persona.
+
+Se puede encontrar documentación más en profundidad sobre cómo firmar commits y tags en el capítulo https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work[Git Tools - Signing Your Work] del libro de Git.
+
+El motivo tras la firma de pushes se puede encontrar en el https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320cc33b051cbed04[commit que introdujo esta característica].
+
+La mejor forma es simplemente decirle a Git que siempre quieres firmar commits, tags y pushes. Puedes hacerlo estableciendo unas pocas variables de configuración:
+
+[source, shell]
+....
+% git config --add user.signingKey LONG-KEY-ID
+% git config --add commit.gpgSign true
+% git config --add tag.gpgSign true
+% git config --add push.gpgSign if-asked
+....
+
+// push.gpgSign should probably be set to `yes` once we enable it, or be set with --global, so that it is enabled for all repositories.
+
+[NOTE]
+======
+Para evitar posibles colisiones, asegúrate de darle a Git una id de clave que sea largo. Puedes obtenerlo con: `gpg --list-secret-keys --keyid-format LONG`.
+======
+
+[TIP]
+======
+Para utilizar subclaves específicas y no hacer que GnuPG resuelva la subclave a una clave primaria, añade `!` a la clave. Por ejemplo, para encriptar la subclave `DEADBEEF`, usa `DEADBEEF!`.
+======
+
+===== Verificando firmas
+
+Las firmas de los commits se pueden verificar ejecutando `git verify-commit <commit hash>`, o `git log --show-signature`.
+
+Las firmas de los tags se pueden verificar con `git verity-tag <tag name>`, o `git tag -v <tag name>`.
+
+////
+Commented out for now until we decide what to do.
+
+Git pushes are a bit different, they live in a special ref in the repository.
+TODO: write how to verify them
+
+////
+
+==== Consideraciones para Ports
+El árbol de ports funciona de la misma forma. Los nombres de las ramas son diferentes y los repositorios están en diferentes lugares.
+
+La interfaz web cgit del repositorio para ser usada desde navegadores web está en https://cgit.FreeBSD.org/ports/. El repositorio Git de producción está en https://git.FreeBSD.org/ports.git y en ssh://anongit@git.FreeBSD.org/ports.git (o anongit@git.FreeBSD.org:ports.git).
+
+También hay un mirror en GitHub, lee extref:{handbook}/mirrors[Mirrors externos, mirrors] para un resumen. La rama 'current' es 'main'. Las ramas trimestrales se llaman 'yyyyQn' para el año 'yyyy' y el trimestre 'n'.
+
+[[port-commit-message-formats]]
+===== Formatos de mensaje de commits
+
+El repositorio de ports tiene disponible en https://cgit.freebsd.org/ports/tree/.hooks/prepare-commit-msg[.hooks/prepare-commit-message] un hook para ayudarte a escribir tus mensajes de commit. Se puede activar ejecutando ``git config --add core.hooksPath .hooks``.
+
+La razón principal es que un mensaje de commit se debería formatear de la siguiente forma:
+
+....
+category/port: Summary.
+
+Descripción de por qué se han hecho los cambios.
+
+PR:	    12345
+....
+
+[IMPORTANT]
+====
+La primera línea es el título del commit, contiene por qué el port ha cambiado, y un resumen del commit. Debería ser de no más de 50 caracteres.
+
+Se debería utilizar una línea en blanco para separarlo del resto del mensaje de commit.
+
+El resto del mensaje se debería limitar a no más de 72 caracteres por línea.
+
+Si hay campos de metadatos se debería utilizar otra línea en blanco, de forma que se distingan fácilmente del mensaje de commit.
+====
+
+==== Gestionando Cambios Locales
+Esta sección trata de controlar cambios locales. Si no tienes cambios locales, puedes dejar de leer (es la última sección y está bien saltársela).
+
+Un punto que es importante para todos ellos: todos los cambios son locales hasta que se hace push. A diferencia de Subversion, Git utiliza un modelo distribuido. Para la mayoría de los usuarios y los casos, hay poca diferencia. Sin embargo, si tienes cambios locales, puedes usar la misma herramienta para gestionarlos que la que usara para traerte los cambios de FreeBSD. Todos los cambios para los que no has hecho push son locales y se pueden cambiar fácilmente (git rebase, discutido más abajo hace esto).
+
+===== Manteniendo cambios locales
+La forma más sencilla de mantener cambios locales (especialmente si son triviales) es usar 'git stash'. En su forma más simple, utilizas 'git stash' para grabar los cambios (lo que los empuja a la pila del stash). La mayoría de la gente utiliza esto para guardar cambios antes de actualizar un árbol como se describe arriba. Después utilizan 'git stash apply' para reaplicarlos al árbol. El stash es una pila de cambios que se puede examinar con 'git stash list'. La página del manual de git-stash (https://git-scm.com/docs/git-stash) tiene todos los detalles.
+
+Este método va bien cuando tienes pequeños cambios en el árbol. Cuando tienes algo no trivial, probablemente sea mejor mantener una rama local y rebasarla. Guardar los cambios (stashing) también es algo integrado en el comando 'git pull': simplemente añade '--autostash' en la línea de comando.
+
+===== Manteniendo una rama local
+[[keeping_a_local_branch]]
+Es mucho más fácil mantener una rama local con Git que con Subversion. En Subversion necesitas mergear el commit, y resolver los conflictos. Esto es manejable, pero puede llevar a un histórico complicado que es difícil de mover al origen (upstream) si fuera necesario, o difícil de replicar si lo necesitas. Git también permite mergear, con los mismos problemas. Esa es una forma de gestionar la rama, pero es la menos flexible.
+
+Además de hacer merging, Git soporta el concepto de rebase que evita estos problemas. El comando 'git rebase' rehace todos los commits de una rama en un lugar nuevo de la rama padre. Cubriremos los casos más comunes que surgen al usarlo.
+
+====== Crear una rama
+
+Digamos que quieres hacer un cambio en el comando ls de FreeBSD para que nunca use colores. Hay muchas razones para hacer esto, pero en este ejemplo usaremos esto como punto de partida. El comando ls de FreeBSD cambia de cuándo en cuándo y necesitarás lidiar con esos cambios. Afortunadamente, con Git rebase esto es algo normalmente automático.
+[source, shell]
+....
+% cd src
+% git checkout main
+% git checkout -b no-color-ls
+% cd bin/ls
+% vi ls.c     # hack the changes in
+% git diff    # check the changes
+diff --git a/bin/ls/ls.c b/bin/ls/ls.c
+index 7378268867ef..cfc3f4342531 100644
+--- a/bin/ls/ls.c
++++ b/bin/ls/ls.c
+@@ -66,6 +66,7 @@ __FBSDID("$FreeBSD$");
+ #include <stdlib.h>
+ #include <string.h>
+ #include <unistd.h>
++#undef COLORLS
+ #ifdef COLORLS
+ #include <termcap.h>
+ #include <signal.h>
+% # these look good, make the commit...
+% git commit ls.c
+....
+
+El commit te llevará a un editor para que describas lo que has hecho. Una vez hecho esto, tienes tu propia rama **local** en el repo de Git. Compila e instala como harías normalmente, siguiendo las instrucciones del manual. Git es diferente a otros sistemas de control de versiones en cuanto que tienes que decirle explícitamente qué ficheros quieres incluir en el commit. He optado por hacerlo en la linea de comando pero también puedes hacerlo con 'git add' que se cubre en muchos de los tutoriales más detallados.
+
+====== Momento de actualizar
+
+Cuando es momento de sacar una nueva versión, es casi lo mismo que sin ramas. Actualizarías como se ha hecho arriba, pero hay un comando extra antes de que actualices y uno después. Lo que sigue asume que empiezas con un árbol sin modificar. Es importante empezar las operaciones de rebase con un árbol limpio (es un requisito en Git).
+
+[source, shell]
+....
+% git checkout main
+% git pull --ff-only
+% git rebase -i main no-color-ls
+....
+
+Eso arrancará un editor que lista todos los commits. Para este ejemplo, no lo cambies. Esto es típicamente lo que haces mientras actualizas la base (aunque también puedes utilizar el comando rebase de Git para filtrar los commits que quieres en la rama).
+
+Una vez que has terminado con lo de arriba, tienes que avanzar los commits de ls.c desde la versión vieja de FreeBSD a la nueva.
+
+A veces hay conflictos al fusionar. Está bien. No te asustes. En lugar de eso, trátalos como cualquier otro conflicto de merge. Para hacerlo sencillo, simplemente describiré un problema común que puede aparecer. Se puede encontrar un enlace a un tratamiento más completo al final de esta sección.
+
+Digamos que los includes cambian en el proyecto origen de una forma radical para terminfo así como también un cambio de nombre para la opción. Cuando te actualizaste, podrías haber visto algo como esto:
+[source, shell]
+....
+Auto-merging bin/ls/ls.c
+CONFLICT (content): Merge conflict in bin/ls/ls.c
+error: could not apply 646e0f9cda11... no color ls
+Resolve all conflicts manually, mark them as resolved with
+"git add/rm <conflicted_files>", then run "git rebase --continue".
+You can instead skip this commit: run "git rebase --skip".
+To abort and get back to the state before "git rebase", run "git rebase --abort".
+Could not apply 646e0f9cda11... no color ls
+....
+que da miedo. Si abres un editor, verás que es una resolución de conflicto típica de 3 vías con la que podrías estar familiarizado de otros sistemas de control de código (el resto de ls.c se ha omitido):
+[source, shell]
+....
+<<<<<<< HEAD
+#ifdef COLORLS_NEW
+#include <terminfo.h>
+=======
+#undef COLORLS
+#ifdef COLORLS
+#include <termcap.h>
+>>>>>>> 646e0f9cda11... no color ls
+....
+El código nuevo está primero, y tu código segundo. El arreglo correcto aquí es añadir simplemente #undef COLORLS_NEW ante de @ifdef y después borrar los cambios antiguos:
+[source, shell]
+....
+#undef COLORLS_NEW
+#ifdef COLORLS_NEW
+#include <terminfo.h>
+....
+guarda el fichero. El rebase fue interrumpido, así que tienes que completarlo:
+[source, shell]
+....
+% git add ls.c
+% git rebase --continue
+....
+
+que le dice a Git que ls.c ha sido arreglado y que puede continuar con el rebase. Puesto que hubo un conflicto, se te dirigirá al editor para actualizar el mensaje de commit si es necesario. Si el mensaje sigue siendo preciso, simplemente sal del editor.
+
+Si te atascas durante el rebase, no te asustes. git rebase --abort te llevará de nuevo a un estado limpio. Sin embargo, es importante empezar con un árbol sin modificar. Una nota: el 'git reflog' mencionado arriba es útil aquí ya que tendrá una lista de todos los commits (intermedios) que puedes ver, inspeccionar o seleccionar con cherry-pick.
+
+Para saber más sobre esto, https://www.freecodecamp.org/news/the-ultimate-guide-to-git-merge-and-git-rebase/ proporciona un tratamiento bastante amplio. Es un buen recursos para problemas que puedan surgir de forma ocasional pero que son muy oscuros para esta guía.
+
+===== Cambiando a una Rama Diferente de FreeBSD
+Si quieres cambiar de stable/12 a la rama current. Si tienes un clonado profundo, lo siguiente es suficiente:
+[source, shell]
+....
+% git checkout main
+% # build and install here...
+....
+Sin embargo, si tienes una rama local, hay algún problema. Primero, rebase sobreescribirá el histórico de forma que querrás hacer algo para salvarlo. Segundo, saltar entre ramas suele causar más conflictos. Si imaginamos que el ejemplo anterior era relativo a stable/12, entonces para moverlo a main, sugeriría lo siguiente:
+[source, shell]
+....
+% git checkout no-color-ls
+% git checkout -b no-color-ls-stable-12   # create another name for this branch
+% git rebase -i stable/12 no-color-ls --onto main
+....
+
+Lo anterior se trae no-color-ls. Luego le da un nombre nuevo (no-color-ls-stable-12) en caso de que necesites volver a ella. Después rebase sobre la rama main. Esto encontrará todos los commits de la rama no-color-ls actual (hacia atrás hasta donde se encuentra con la rama stable/12) y después los aplicará de nuevo sobre la rama main creando una nueva rama no-color-ls allí (para lo cual te hice crear un nombre tipo place holder).
+
+===== Migrando desde un clon de Git existente
+Si tienes trabajo basado en una conversión previa de Git o una conversión local git-svn, migrar al nuevo repositorio puede suponer algunos problemas porque Git no tiene conocimiento acerca de la conexión entre ambos.
+
+Cuando sólo tienes unos pocos cambios locales, la forma más fácil sería escoger esos cambios y llevarlos a la nueva base:
+[source, shell]
+....
+% git checkout main
+% git cherry-pick old_branch..your_branch
+....
+O alternativamente, haz lo mismo con un rebase:
+[source, shell]
+....
+% git rebase --onto main master your_branch
+....
+
+Si haces muchos cambios, probablemente quieras hacer un merge. La idea es crear un punto de merge que consolida el histórico de old_branch, y el nuevo repositorio de FreeBSD (main).
+
+Puedes averiguarlo buscando un mismo commit que se encuentre en ambos padres:
+[source, shell]
+....
+% git show old_branch
+....
+Verás un mensaje de commit, ahora búscalo en la rama nueva:
+[source, shell]
+....
+% git log --grep="commit message on old_branch" freebsd/main
+....
+ayudaría a localizar el commit hash en la rama nueva, crea una rama de ayuda (en el ejemplo lo llamamos 'stage') a partir del hash:
+[source, shell]
+....
+% git checkout -b stage _hash_found_from_git_log_
+....
+Luego realiza un merge de la rama vieja:
+[source, shell]
+....
+% git merge -s ours -m "Mark old branch as merged" old_branch
+....
+Con esto, es posible mergear tu rama de trabajo o la rama principal en cualquier orden sin problema. Eventualmente, cuando estés listo para hacer commit de tu trabajo de vuelta a main, puedes hacer un rebase a main, o hacer un commit tipo squash combinando todo en un solo commit.
+
+[[mfc-with-git]]
+=== Procedimientos MFC (Merge From Current)
+==== Resumen
+
+El flujo de trabajo de MFC se puede resumir como `git cherry-pick -x` más `git commit --amend` para ajustar el mensaje de commit. Para múltiples commits, usa `git rebase -i` para refundirlos juntos y editar el mensaje de commit.
+
+==== MFC de un sólo commit
+
+[source, shell]
+....
+% git checkout stable/X
+% git cherry-pick -x $HASH --edit
+....
+
+Para commits MFC, por ejemplo una importación externa, necesitarías especificar un padre para cherry-pick. Normalmente, sería el "primer padre" de la rama de la que estás haciendo cherry-pick, así que:
+
+[source, shell]
+....
+% git checkout stable/X
+% git cherry-pick -x $HASH -m 1 --edit
+....
+
+Si algo va mal, necesitarás abortar el cherry-pick con `git cherry-pick --abort` o arreglarlo y hacer un `git cherry-pick --continue`.
+
+Una vez terminado el cherry-pick, empuja con `git push`. Si recibes un error por haber perdido una carrera por el commit, utiliza `git pull --rebase` y prueba a empujarlo de nuevo.
+
+==== MFC a una rama RELENG
+
+Se necesita más cuidado para hacer MFCs a ramas para las cuales se necesita aprobación. El proceso es el mismo tanto para un merge típico como para un commit directo excepcional.
+
+* Haz merge o un commit directo a la rama `stable/X` apropiada antes de mergear a la rama `releng/X.Y`.
+* Utiliza el hash de la rama `stable/X` para el MFC a la rama `releng/X.Y`.
+* Deja ambas lineas "cherry picked from" en el mensaje de commit.
+* Asegúrate de añadir la línea `Approved by:` cuando estés en el editor.
+
+[source, shell]
+....
+% git checkout releng/13.0
+% git cherry-pick -x $HASH --edit
+....
+
+Si se te olvida añadir la línea `Approved by:`, puedes hacer un `git commit --amend` para editar el mensaje de commit antes de empujar los cambios.
+
+==== MFC de varios commits
+
+[source, shell]
+....
+% git checkout -b tmp-branch stable/X
+% for h in $HASH_LIST; do git cherry-pick -x $h; done
+% git rebase -i stable/X
+# mark each of the commits after the first as 'squash'
+# Update the commit message to reflect all elements of commit, if necessary.
+# Be sure to retain the "cherry picked from" lines.
+% git push freebsd HEAD:stable/X
+....
+
+Si el push falla por perder la carrera del commit, haz rebase y prueba de nuevo:
+
+[source, shell]
+....
+% git checkout stable/X
+% git pull
+% git checkout tmp-branch
+% git rebase stable/X
+% git push freebsd HEAD:stable/X
+....
+
+Una vez que el MFC se ha completado, puedes borrar la rama temporal:
+
+[source, shell]
+....
+% git checkout stable/X
+% git branch -d tmp-branch
+....
+
+==== Haciendo MFC de una importación externa
+
+Las importaciones externas son lo único en el árbol que crean un commit tipo merge en la línea principal. Seleccionar commits tipo merge en stable/XX representa una dificultad adicional porque hay dos padres para un commit tipo merge. En general, querrás la diferencia del primer padre ya que es la diferencia con la línea principal (aunque podría haber algunas excepciones).
+
+[source, shell]
+....
+% git cherry-pick -x -m 1 $HASH
+....
+es normalmente lo que quieres. Esto le dirá a cherry-pick que aplique el diff correcto.
+
+Hay algunos pocos casos (con suerte) donde es posible que la línea principal haya sido mergeada hacia atrás por el script de conversión. Si ese fuera el caso (y todavía no hemos encontrado ninguno), cambiarías lo de arriba por '-m 2' para escoger el padre adecuado. Simplemente haz
+[source, shell]
+....
+% git cherry-pick --abort
+% git cherry-pick -x -m 2 $HASH
+....
+para hacerlo. El `--abort` limpiará el primer intento fallido.
+
+==== Rehaciendo un MFC
+
+Si haces un MFC y va terriblemente mal y quieres empezar de nuevo, lo más fácil es usar `git reset --hard` así:
+[source, shell]
+....
+% git reset --hard freebsd/stable/12
+....
+aunque si tienes algunas revisiones que quieres mantener, y otras que no, es mejor usar 'git rebase -i '.
+
+==== Consideraciones cuando se hace un MFC
+
+Cuando se hace commit the commits the código fuente a las ramas stable y releng, tenemos los siguientes objetivos:
+
+* Marcar claramente los commits directos y diferenciarlos de commits que traen un cambio desde otra rama.
+* Evitar introducir cambios que rompan algo en stable y releng.
+* Permitir a los desarrolladores determinar qué cambios han sido o no traídos de una u otra rama.
+
+Con Subversion, usábamos las siguientes prácticas para conseguir estos objetivos:
+
+* Usar las etiquetas 'MFC' y 'MFS' para marcar los cambios mergeados desde otra rama.
+* Compactar commits que arreglan problemas en un commit principal cuando se mergea un cambio.
+* Registrar mergeinfo de forma que `svn mergeinfo --show-revs` funcione.
+
+Con Git, necesitaremos usar diferentes estrategias para conseguir los mismos objetivos. Este documento trata de definir las mejores prácticas para conseguir estos objetivos con Git cuando se mergean cambios de código fuente. En general, tratamos de usar el soporte nativo de Git para conseguir los objetivos en lugar de forzar a realizar las prácticas construidas sobre el modelo de Subversion.
+
+Una nota general: debido a las diferencias técnicas con Git, no utilizaremos los "merge commits" de Git (creados mediante `git merge`) en las ramas stable o releng. En su lugar, cuando este documento habla de "merge commits", significa el commit original hecho en `main` que es replicado o "aterrizado" (landed) en una rama stable, o un commit de una rama stable que es replicado a una rama releng con alguna variación de `git cherry-pick`.
+
+==== Encontrando Hashes Seleccionables para MFC
+
+Git proporciona algo de soporte para esto mediante los comandos `git cherry` y `git log --cherry`. Estos comandos comparan los diffs en crudo de los commits (pero no otros metadatos como los mensajes de log) para determinar si dos commits son idénticos. Esto funciona bien cuando cada commit de head se lleva como un sólo commit a la rama stable, pero falla si múltiples commits de main se compactan juntos como un sólo commit en la rama stable.
+
+Hay algunas opciones para resolver esto:
+
+1. Podríamos prohibir el compactado de commits y en su lugar requerir que los committers preparen todos los commits tipo fixup / follow-up a stable en un solo push. Esto alcanzaría el objetivo de estabilidad en las ramas stable y releng ya que los pushes son atómicos y los usuarios que hace un pull simple nunca acabarán teniendo un árbol que tiene el commit principal sin los arreglos (fixups). `git bisect` también es capaz de lidiar con este modelo vía `git bisect skip`.
+
+2. Podríamos adoptar un estilo consistente para describir los MFCs y escribir nuestras propias herramientas que envuelvan `git cherry` para determinar la lista de commits seleccionables. Una aproximación sencilla podría ser usar la sintaxis de `git cherry-pick -x`, pero requiere que un commit compactado liste todos los hashes (uno por línea) al final del mensaje de commit. Los desarrolladores podrían hacer esto utilizando `git cherry-pick -x` para cada commit individual en una rama y después usar `git rebase` para compactar los commits en uno solo, pero recogiendo las anotaciones de `-x` al final del log del commit.
+
+==== Estándares para los mensajes de commit
+===== Marcar MFCs
+
+El proyecto ha adoptado las siguientes prácticas para marcar MFCs:
+
+* Usa el flag `-x` con `git cherry-pick`. Esto añade una línea al mensaje de commit que incluye el hash del commit original cuando se hace el merge. Puesto que Git lo añade directamente, los committers no tienen que editar manualmente el log cuando hacen el merge.
+
+Cuando se mergean varios commits, mantén todas las líneas "cherry picked from".
+
+===== ¿Recortar Metadatos?
+
+Un área que no estaba documentada de forma clara con Subversion (ni con CVS) era cómo formatear los metadatos en los mensajes de log para los commits tipo MFC. ¿Debería incluir los metadatos del commit original sin modificar o se debería modificar para reflejar la información acerca del propio commit MFC?
+
+Históricamente la práctica ha variado, aunque parte de la variación es por campo. Por ejemplo, MFCs relativos a un PR normalmente incluyen el campo PR en el MFC de forma que los commits MFC se incluyen en el log de autoría del sistema de reportes de error (bug tracker). Con otros campos está menos claro. Por ejemplo, Phabricator muestra la diferencia entre el último commit etiquetado a una revisión, de forma que incluir URLs de Phabricator reemplaza el commit `main` con los commits "aterrizados". La lista de revisores tampoco está clara. Si un revisor ha aprobado un cambio a `main`, ¿significa eso que han aprobado el commit MFC? ¿Es cierto si el código es idéntico o con sólo cambios triviales? Claramente no es cierto para trabajos más extensivos. Incluso para código idéntico ¿qué pasa si el commit no tiene conflicto pero introduce un cambio en el ABI? Un revisor podría haber dado el visto bueno para un commit en `main` debido al rompimiento del ABI pero podría no
  aprobar el mergeado del mismo commit tal cual. Cada uno tiene que usar su mejor juicio hasta que acordemos unas directrices claras.
+
+Para MFCs que están regulados por re@, se añaden nuevos campos de metadatos como la etiqueta Approved by para commits aprobados. Estos nuevos metadatos se tendrán que añadir con `git commit --amend` o similar después de que el commit original haya sido revisado y aprobado. También podríamos querer reservar algunos campos en los metadatos de los commtis MFC como las URLs de Phabricator para uso futuro por parte de re@.
+
+Preservar los metadatos existentes proporciona un flujo de trabajo sencillo. Los desarrolladores sólo tienen que usar `git cherry-pick-x` sin tener que editar el mensaje de log.
+
+Si por el contrario escogemos ajustar los metadatos en los MFCs, los desarrolladores tendrán que editar los mensajes de log de forma explícita mediante el uso de `git cherry-pick --edit` o `git commit --amend`. Sin embargo, comparado con svn, al menos el mensaje de commit existente se puede precargar y los campos de metadatos se pueden añadir o eliminar sin tener que reescribir el mensaje de commit entero.
+
+La conclusión es que los desarrolladores seguramente tengan que refinar los mensajes de commit para los MFCs que no sean triviales.
+
+==== Ejemplos
+
+===== Mergeando un Solo Commit de Subversion
+
+Aquí se explica el proceso de mergear un commit a stable/12 que fue añadido originalmente en head en Subversion. En este caso, el commit original es r368685.
+
+El primer paso es mapear el commit de Subversion a un hash de Git. Una vez que te has traído refs/notes/commits, puedes pasar el número de revisión a `git log --grep`:
+
+[source, shell]
+....
+% git log main --grep 368685
+commit ce8395ecfda2c8e332a2adf9a9432c2e7f35ea81
+Author: John Baldwin <jhb@FreeBSD.org>
+Date:   Wed Dec 16 00:11:30 2020 +0000
+
+    Use the 't' modifier to print a ptrdiff_t.
+
+    Reviewed by:    imp
+    Obtained from:  CheriBSD
+    Sponsored by:   DARPA
+    Differential Revision:  https://reviews.freebsd.org/D27576
+
+Notes:
+    svn path=/head/; revision=368685
+....
+
+Luego, haz MFC del commit a `stable/12`:
+
+[source, shell]
+....
+git checkout stable/12
+git cherry-pick -x ce8395ecfda2c8e332a2adf9a9432c2e7f35ea81 --edit
+....
+
+Git invocará el editor. Úsalo para eliminar los metadatos que sólo aplicaban al commit original (URL de Phabricator y Reviewed by). Después de que el editor salve el mensaje de log actualizado, Git completa el commit:
+
+[source, shell]
+....
+[stable/12 3e3a548c4874] Use the 't' modifier to print a ptrdiff_t.
+ Date: Wed Dec 16 00:11:30 2020 +0000
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+....
+
+El contenido del commit del que se ha hecho MFC se puede examinar vía `git show`:
+
*** 15746 LINES SKIPPED ***