[gestión del almacén de git] separación del almacén de gitlab, conservando todos los registros de envío históricos

fondo

Un proyecto actualmente en desarrollo, debido a la falta de una gestión estandarizada al principio, comenzó a funcionar de manera desenfrenada con el código después de que el personal se uniera.
La cantidad de código está aumentando y varios proyectos se están acoplando cada vez más; para separar la plataforma y los complementos, distinguir diferentes capas de código: como framework, db, om, business, etc.; es necesario separe el almacén de git existente en diferentes almacenes, desarrolle por separado y mantenga en grupos correspondientes, reduzca el costo de mantenimiento del código, reduzca el acoplamiento y evite la introducción de problemas desconocidos
Herramientas de gestión de almacenes : git
warehouse hosting : gitlab

Preparativos para dividir

No hay mucho que decir, los proyectos son diferentes y el contenido a hacer es diferente, no coincide con el contenido principal de este artículo.

La inserción falló después de crear un nuevo almacén de gitlab

El trabajo de división inicial fue extremadamente largo y doloroso. Limpié todos los complementos y códigos de aplicaciones de capa superior que estaban acoplados a la plataforma. También encontré un montón de errores de compilación y atravesé montañas y ríos. Después de finalmente resolver todo. , Creé un nuevo almacén en gitlab
. , un almacén en blanco puro sin archivos ni registros de confirmación.
En este momento, cuando obtengo git push -f remoto master, después de una larga carga comprimida, ¡el resultado es un error! ! !
Insertar descripción de la imagen aquí
Como mi permiso es de desarrollador y master es una rama protegida, habilité los permisos de Mantenedor y lo ejecuté nuevamente. El error es el siguiente
Insertar descripción de la imagen aquí

使用了
git clone --depth <number> remote-url local-dir
这会导致浅克隆。局限性之一就是不能将仓库的提交推送到一个全新的仓库中,因为其中的信息不全

Solución

拉去全部的代码仓库历史记录
git fetch --unshollaw origin

Después de ejecutar el comando anterior, presione nuevamente y se mostrará que fue exitoso.
Pero aquí hay un problema, es decir, el contenido enviado al nuevo almacén requiere mucho más espacio que el antiguo almacén (nuestro almacén en sí es relativamente grande, varios G), este problema aún no está claro
. Hablemos de ello más tarde.

Después de que la inserción sea exitosa, git pull del nuevo almacén falla. Después de la modificación, git push falla nuevamente.

![Inserte descripción de la imagen aquí](https://img-blog.csdnimg.cn/ae50b22fce29406ab5d97fc13930efa8.png Insertar descripción de la imagen aquí
Insertar descripción de la imagen aquí
El avance no rápido anterior significa que hay nuevos envíos localmente y hay nuevos envíos en el almacén de git, y el push Las confirmaciones de avance rápido (en pocas palabras, significa que desde la última vez que actualizó el código maestro, otros tienen nuevas confirmaciones fusionadas en el maestro), puede forzar el envío, pero el registro del historial puede se perderá (se sobrescribirá); el enfoque general es primero git pull a local y fusionar

El error de gancho de pre-recepción rechazado cuando se forzó el envío significa que nuestro envío forzado fue rechazado durante la pre-recepción. Esta situación a menudo se debe a que las restricciones establecidas por el propio almacén en la sucursal no se cumplen; por ejemplo, configuramos arriba gitlab Master es una rama de protección, y el empuje forzado que no sea de avance rápido generalmente fallará.

La solución es utilizar el siguiente comando para crear una nueva rama en el extremo remoto y enviar una solicitud de fusión para la fusión.

git push --set-upstream origin branchname

Luego combínelo manualmente y luego haga un git pull local, y la solución es perfecta.

Supongo que te gusta

Origin blog.csdn.net/weixin_43500200/article/details/131837367
Recomendado
Clasificación