Información general
Básicamente, esto te permite volver a implementar muchas de las funcionalidades de Git sobre nuestra API mediante la creación de objetos sin procesar (raw) directamente en la base de datos y actualizando las referencias de rama que técnicamente podrían hacer todo lo que pueda hacer Git sin que se éste se instale.
Las funciones de la API de la base de datos de Git devolverán un elemento 409 Conflict
si el repositorio de Git está vacío o no está disponible. Que un repositorio se muestre como no disponible habitualmente significa que GitHub Enterprise Server está en el proceso de crearlo. Para un repositorio vacío, puede usar el punto de conexión de "Creación o actualización del contenido del archivo" para crear contenido e inicializar el repositorio, de modo que pueda usar la API de la base de datos de Git. Contacta a el administrador del sitio si este estado de respuesta persiste.
Para obtener más información sobre la base de datos de objetos de Git, lea el capítulo Información interna de Git del libro Pro Git.
Como ejemplo, si quisiera confirmar un cambio en un archivo de su repositorio, haría lo siguiente:
- Obtener el objeto de la confirmación actual
- Recuperar el árbol al cual apunta
- Recuperar el contenido del objeto del blob que tiene el árbol para esa ruta de archivo en particular
- Cambiar el contenido de alguna manera y publicar un objeto de blob nuevo con este contenido nuevo, obteniendo el SHA del blob a cambio
- Publicar un nuevo objeto de árbol con ese indicador de la ruta del archivo reemplazándolo con el SHA de tu blob nuevo y obteniendo a cambio el SHA del árbol
- Crear un objeo de confirmación nuevo con el SHA de la confirmación actual como el padre y el SHA del árbol nuevo, obteniendo a cambio el SHA de la confirmación
- Actualizar la referencia de tu rama para apuntar al nuevo SHA de la confirmación
Puede que parezca complejo, pero en realidad es bastante sencillo cuando entiende el modelo y proporciona la oportunidad de hacer un sin fin de cosas cuando lo hace potencialmente con la API.
Verificar la capacidad de fusión de las solicitudes de extracción
Advertencia No dependa del uso de Git directamente o de GET /repos/{owner}/{repo}/git/refs/{ref}
de las actualizaciones en las referencias merge
de Git, ya que este contenido queda obsoleto sin previo aviso.
Una API consumible debe solicitar explícitamente una solicitud de incorporación de cambios para crear una confirmación de combinación de prueba. Se crea una confirmación de combinación de prueba cuando ve la solicitud de incorporación de cambios en la interfaz de usuario y se muestra el botón "Merge" (Combinar), o cuando obtiene, crea o edita una solicitud de incorporación de cambios mediante la API REST. Sin esta solicitud, las referencias merge
de Git quedarán obsoletas hasta la próxima vez que alguien vea la solicitud de incorporación de cambios.
Si actualmente utiliza métodos de sondeo que producen referencias merge
de Git obsoletas, GitHub le recomienda utilizar los pasos siguientes para obtener los cambios más recientes de la rama predeterminada:
- Recibir el webhook de la solicitud de extracción.
- Llame a
GET /repos/{owner}/{repo}/pulls/{pull_number}
para iniciar un trabajo en segundo plano a fin de crear el candidato de confirmación de combinación. - Sondee el repositorio mediante
GET /repos/{owner}/{repo}/pulls/{pull_number}
para ver si el atributomergeable
estrue
ofalse
. Puede usar Git directamente oGET /repos/{owner}/{repo}/git/refs/{ref}
para las actualizaciones de las referenciasmerge
de Git solo después de realizar los pasos anteriores.