Referencia del comando de repositorio

转载： AOSP > Documentación > Primeros pasos > Referencia del comando Repo

Repo complementa a Git al simplificar el proceso de ejecución en múltiples bases de código. Herramientas de control de código fuente

---

1 、 ayuda

repo help

repo help [command]

2、iniciar

repo init -u url [options]

Instale Repo en el directorio actual. Esto crea un .repo/directorio que contiene el repositorio Git que alberga el código fuente del Repo y los archivos de manifiesto estándar de Android.

Opciones:

• -u: especifica la URL desde la cual recuperar el repositorio de manifiesto. Los manifiestos comunes se encuentran en https://android.googlesource.com/platform/manifest.
• -m: seleccione el archivo de manifiesto en el código base. Si no se selecciona ningún nombre de manifiesto, el valor predeterminado es default.xml.
• -b: especifica la revisión, es decir, una rama de manifiesto específica.

3、sincronización

repo sync [project-list]

La descarga de nuevos cambios y la actualización de archivos de trabajo en su entorno local se pueden realizar básicamente en cualquier repositorio Git git fetch. Si se ejecuta sin argumentos repo sync, el comando sincroniza archivos para todos los proyectos.

Después de ejecutar repo sync, ocurrirá lo siguiente:

• Si el proyecto de destino nunca se ha sincronizado, la sincronización del repositorio es equivalente a git clone. Todas las ramas del repositorio remoto se copian en el directorio del proyecto local.
• Si el proyecto de destino se ha sincronizado antes, la sincronización del repositorio equivale a:

git remote update
git rebase origin/branch

Donde rama es la rama actualmente desprotegida en el directorio del proyecto local. Si la sucursal local no realiza un seguimiento de la sucursal en el repositorio remoto, no se producirá ninguna sincronización para el proyecto.

• Si una operación de rebase de Git causa conflictos de fusión, use comandos regulares de Git (como git rebase --continue) para resolver los conflictos.
  Después de ejecutar correctamente la sincronización del repositorio, el código del proyecto especificado está actualizado y sincronizado con el código del repositorio remoto.

A continuación se muestran las opciones importantes. Para obtener más información, consulte repo help sync:

• -c: obtiene solo la rama del manifiesto actual en el servidor.
• -d: cambia el proyecto especificado a la revisión del manifiesto. Esta opción es útil si el proyecto pertenece actualmente a una rama temática pero requiere temporalmente una revisión del manifiesto.
• -f: Incluso si falla la sincronización de un determinado proyecto, continúe sincronizando otros proyectos.
• -j threadcount: divide las operaciones de sincronización en varios subprocesos para completarlas más rápido. Asegúrese de no sobrecargar su computadora; reserve algo de CPU para otras tareas. Para ver la cantidad de CPU disponibles, primero ejecute:nproc --all
• -q: garantiza que el proceso en ejecución no se interrumpa suprimiendo los mensajes de estado.
• -s:manifest-server sincroniza con una compilación buena conocida especificada por el elemento en el manifiesto actual .

4、subir

repo upload [project-list]

Para el proyecto especificado, Repo compara la rama local con la rama remota que se actualizó durante la última sincronización del Repo. Repo le pedirá que seleccione una o más ramas que aún no se han cargado para su revisión.

A continuación, todas las confirmaciones en la rama seleccionada se transfieren a través de una conexión HTTPS Gerrit. Debe configurar una contraseña HTTPS para habilitar la autorización de carga. Para generar un nuevo par de nombre de usuario/contraseña para la transferencia HTTPS.

Cuando Gerrit recibe datos del objeto a través de su servidor, convierte cada confirmación en un cambio para que los revisores puedan comentar sobre esa confirmación específica. Para combinar varias confirmaciones de "puntos de control" en una, ejecute git rebase -iy luego ejecute upload.

Si se ejecuta sin ningún parámetro repo upload, el comando busca en todos los proyectos cambios para cargar.

Para modificar sus cambios después de haberlos cargado, actualice su envío local usando herramientas como git rebase -io . git commit --amendUna vez completada la modificación, realice las siguientes operaciones:

• Verifique para asegurarse de que la rama actualizada sea la rama actualmente desprotegida.
• Úselo para repo upload --replace PROJECTabrir el editor de coincidencias de cambios.
• Para cada confirmación en la serie correspondiente, ingrese el ID de cambio de Gerrit entre corchetes:

# Replacing from branch foo
[ 3021 ] 35f2596c Refactor part of GetUploadableBranches to lookup one specific...
[ 2829 ] ec18b4ba Update proto client to support patch set replacments
# Insert change numbers in the brackets to add a new patch set.
# To create a new change record, leave the brackets empty.

Una vez cargados, estos cambios tendrán un conjunto de parches adicional.

Si solo desea cargar la rama de Git que está actualmente desprotegida, use la etiqueta --current-branch(o nombre corto --cbr).

5 、 diferencia

repo diff [project-list]

Úselo git diffpara mostrar cambios visibles entre las confirmaciones y el árbol de trabajo.

6、descargar

repo download [target change]

Descarga los cambios especificados del sistema de revisión y los coloca en el directorio de trabajo local de su proyecto para su uso.

Por ejemplo, para descargar el cambio 23823 a su directorio de plataforma/compilación, ejecute el siguiente comando:

repo download platform/build 23823

La ejecución repo syncelimina repo downloadtodas las confirmaciones recuperadas usando . Alternativamente, puede utilizar git checkout m/masterla opción de pago en la sucursal remota.

7 、 para todos

repo forall [project-list] -c command

Ejecuta el comando de shell especificado en cada proyecto. repo forallLas siguientes variables de entorno adicionales están disponibles a través de :

• REPO_PROJECT tiene un nombre único para el proyecto.
• REPO_PATH es la ruta relativa al directorio raíz del cliente.
• REPO_REMOTE es el nombre del sistema remoto en el inventario.
• REPO_LREV es el nombre de la revisión en el manifiesto que se convirtió en una rama de seguimiento local. Utilice esta variable si necesita pasar la revisión del manifiesto a un comando Git que se ejecuta localmente.
• REPO_RREV es el nombre de la revisión en el manifiesto, exactamente como aparece en el manifiesto.

Opciones:

• -c: Comando y parámetros a ejecutar. Este comando se evalúa contra /bin/sh y cualquier argumento posterior se pasa como argumento posicional del shell.
• -p: muestra los encabezados del proyecto antes de la salida del comando especificado. Esto se logra vinculando tuberías a las secuencias stdin, stdout y sterr del comando, y luego canalizando toda la salida en una secuencia continua que se muestra en una sesión de una sola página.
• -v: muestra los mensajes escritos por este comando en stderr.

8 、 podar

repo prune [project-list]

Podar (eliminar) temas combinados.

9 、 inicio

repo start
branch-name [project-list]

Cree una nueva rama para desarrollo a partir de la revisión especificada en el manifiesto.
El parámetro BRANCH_NAME se utiliza para describir brevemente los cambios que intenta realizar en el proyecto. Si no lo sabe, considere usar el nombre default .
El parámetro lista de proyectos especifica los proyectos que participarán en esta rama temática.

10、estado

repo status [project-list]

Para cada proyecto especificado, compara el árbol de trabajo con el área de preparación (índice) y HEADla confirmación más reciente en esta rama (). Muestra una línea de resumen para cada archivo que difiere entre estos tres estados.
Para ver el estado de la rama actual, ejecute repo status. La información de estado se enumera por proyecto. Cada archivo del proyecto está representado por un código de dos letras:
en la primera columna, una letra mayúscula indica la diferencia entre el área de preparación y el estado de la última confirmación.

carta	significado	ilustrar
-	ningún cambio	Lo mismo en HEAD que en index
A	agregado	No existe en HEAD, pero existe en el índice.
METRO	ya editado	existe en HEAD, pero el archivo en el índice ha sido modificado
D	eliminado	existe en HEAD pero no en el índice
R	renombrado	no existe en HEAD, la ruta al archivo en el índice ha cambiado
C	Copiado	No existe en HEAD, copiado de otro archivo en el índice
t	El modo ha cambiado	HEAD es el mismo que en el índice, pero el esquema ha cambiado.
Ud.	No fusionado	Conflicto entre HEAD e índice; debe resolverse

En la segunda columna, las letras minúsculas indican la diferencia entre el directorio de trabajo y el índice.

carta	significado	ilustrar
-	nuevo/desconocido	no existe en el índice pero existe en el árbol de trabajo
metro	ya editado	existe en el índice y también existe en el árbol de trabajo (pero se ha modificado en ambas ubicaciones)
d	eliminado	existe en el índice pero no en el árbol de trabajo

11. Manejar errores de repositorio

git commit -a # Commit local changes first so they aren't lost.
repo start branch-name # Start the branch
git reset --hard HEAD@{
    
    1} # And reset the branch so that it matches the commit before repo start
repo upload .

Si el comando no se ejecuta al comienzo de la sesión repo start, el sistema muestra un error repo: error: no branches ready for upload. Para revertir, puede verificar el ID de confirmación, crear una nueva rama y fusionarla.