Escenarios de aplicación de Git-03_gitlab

Tomando Linux como ejemplo, la plataforma Windows es la misma que Linux.
En el frente (2.2.1, haga clic en el botón "Nuevo proyecto" para crear un proyecto) Aparecen instrucciones de la línea de comandos al crear un nuevo proyecto, y casi todas las operaciones a continuación giran en torno a estos comandos.

Instrucciones de la línea de comandos

Configuración global de Git

Git debe configurarse en el primer uso

git config --global user.name "yhh"
git config --global user.email "[email protected]"

Crear un nuevo repositorio

Clone un proyecto vacío del repositorio remoto y cree nuevos archivos.

git clone [email protected]:example_firmware/test.git
cd test
touch README.md
git add README.md	        //1.将代码从工作区中添加到版本库暂存区中去
git commit -m "add README"  //2.把暂存区的所有修改提交到master分支上去
git push -u origin master   //3.把分master支上代码push到远程仓库中去 

Carpeta existente

Generalmente usamos este comando para enviar el código del proyecto existente a la biblioteca remota.

cd existing_folder
git init //创建版本库,后面会有详细介绍(只有第一次操作即可,后面不用操作)
 
关联仓库(两种push代码方式)
git remote add origin http://example.wicp.vip/example_firmware/test.git /*走http协议(只有第一次操作即可,后面不用操作)*/
git remote add origin [email protected]:example_firmware/plug-in_framework.git /*走SSH协议 (只有第一次操作即可,后面不用操作)*/
 
git add .                      //1.将代码从工作区中添加到版本库暂存区中去
git commit -m "Initial commit" //2.把暂存区的所有修改提交到master分支上去
git push -u origin master      //3.把分master支上代码push到远程仓库中去

El repositorio Git existente
no investigó (omitido)

1. Crear una biblioteca de versiones.
Ejecutar en el directorio de trabajo del proyecto correspondiente de la plataforma Linux: después de git init, se generará un archivo .git en el directorio de trabajo correspondiente. Esto se usa para rastrear la biblioteca de versiones de administración de la biblioteca. No elimine esto en el futuro, de lo contrario, se destruirán todos los registros de git anteriores.

 

2. Almacén asociado

Asocie el almacén local con el almacén remoto antes de agregar contenido al almacén remoto.

Modo SSH

git remote add origin [email protected]:example_firmware/plug-in_framework.git  

 método HTTP

git remote add origin http://example.wicp.vip/example_firmware/test.git

3. Gestión de códigos

Para la gestión de código, varios comandos de uso común son en realidad tres trucos.

3.1 Ver el estado del código

Ejecutando una orden:

git status

3.2 Agregar código al repositorio 

Ejecutando una orden:

git add .

3.3 Agregar código a la sucursal

Ejecutando una orden:

git commit -m “初次提交”

 

3.4 Enviar el código de sucursal a la biblioteca remota

Ejecutando una orden:

git push -u origin master(第一次执行命令需要加上-u,后面就不需要)

4. Reversión de versión 

En nuestro trabajo, muchas veces queremos saber cuántas versiones hemos enviado al repositorio, ejecute el comando:

git log

 

o comando:

git log --pretty=onelin

 

Entre ellos, la confirmación 4b10e619d0b82c574a34b2266ca40ad13b7d5622 es la identificación de cada versión calculada por SHA1.

o comando:

git reflog

4.1 Reversión del código a la versión anterior

Ejecutando una orden:

git reset --hard HEAD^

 

 Entre ellos, HEAD es el puntero de la versión actual, ^ significa la versión anterior y ^^ significa la versión anterior.

4.2 Versión especificada de reversión de código

Comando comando:

git reset --hard 57d3f9aa669dc646697064a97810b842a50fe1bc

 4.3 Reversión del código a la última versión 

El primer paso es ejecutar el comando:

git reflog //找到所有版本的commit id

 

 El segundo paso es ejecutar el comando:

git reset --hard 4b10e61

 

 5. Múltiples sucursales

Para el desarrollo normal, normalmente reservamos la rama maestra para la versión de lanzamiento y la rama dev para el desarrollo de prueba.

5.1 Crear una nueva sucursal

Ejecutar un comando:

git checkout -b dev

Este comando se puede dividir en dos pasos:

git branch dev和git checkout dev

 

 Nota: Al cambiar la rama de desarrollo, debe enviar el código de la rama maestra a la biblioteca de versiones; de lo contrario, el cambio no tendrá éxito o el código original no se guardará.

5.2 Ver rama

Ejecutando una orden:

git branch

 

Indica que ahora se puede llevar a cabo el desarrollo en la rama dev, como se muestra en la fuente verde de la figura. 

5.3 Fusión de sucursales

Modifique el código en la rama dev y envíelo al repositorio, y luego ingrese a la rama maestra para ejecutar el comando:

git merge dev

5.4 Eliminar rama

Ejecutando una orden:

git branch -d dev

 5.5 El conflicto de fusionar ramas
El llamado conflicto significa que varias ramas no están sincronizadas. Generalmente, antes de modificar el código de la rama maestra, primero debemos extraer el código, de lo contrario ocurrirán los siguientes conflictos. En este caso, Es necesario editar manualmente el archivo que no pudo fusionarse con git al contenido que queremos y luego enviarlo.

Paso 1: Cree y modifique una rama, luego confirme. como sigue:

Paso 2: cambie a la rama maestra, modifique la rama maestra y luego fusione la rama dev1.

Puede ver que hay conflictos de combinación y verificar readme.txt al mismo tiempo

Esta situación es un conflicto, y el conflicto debe resolverse manualmente antes del envío. Elimine la parte innecesaria de readme.txt y luego confirme.

Ejecutando una orden:

git log --graph --pretty=oneline --abbrev-commit

 Puede ver la situación de fusión de sucursales, como se muestra en la figura.

 5.6 Colaboración de varias personas

Cuando varias personas colaboran, todos impulsarán sus propias modificaciones a las ramas principal y de desarrollo. Suponga que usted es A y hay una persona B que clona en otra computadora (tenga en cuenta que la clave SSH debe agregarse a GitLab) u otro directorio de la misma computadora.

Ejecutando una orden:

git clone [email protected]:xxx_firmware/test.git

Por defecto, es la rama maestra, de la siguiente manera: git branch

En este punto, B desarrollará y enviará el código a la rama de desarrollo.

 Luego, A también hizo una modificación y envió el código a la rama de desarrollo al mismo tiempo, de la siguiente manera

Lo anterior muestra que la inserción falló, porque hay un conflicto entre el último envío de B y el envío de A. La solución es extraer primero el código de la biblioteca remota, como se muestra en la figura a continuación.

  Nota: Cuando falla la extracción del código, debe especificar la asociación entre la rama de desarrollo local y la rama de origen/desarrollo de la biblioteca remota. Al mismo tiempo, verifique la modificación de la rama readme.txt local, puede encontrar

Esta vez es el mismo que el conflicto de la rama de fusión 5.6. Enviar después de resolver, y finalmente empujar.

 

6. Configuración de la etiqueta y número de versión

 Gitlab no envía un código de versión con un ID de confirmación. Podemos etiquetarlos de acuerdo con estos ID de confirmación. Esta etiqueta puede ser un número de versión.

 6.1 Pestaña predeterminada

La etiqueta predeterminada se imprime en la última confirmación de la siguiente manera:

6.2 Especificar una etiqueta en el ID de confirmación 

primer paso:

git log --pretty=oneline --abbrev-commit

 Encuentre la identificación de confirmación de la versión de confirmación en todas las ramas maestras

Segundo paso:

git tag v0.9 8c1b181

Especificar compromiso con la etiqueta

6.3 Ver información específica de la etiqueta específica

Ejecutando una orden:

git show v0.9

 

6.4 Etiquetas de inserción

Empuje una etiqueta:

git push origin v1.0

Empuje todas las etiquetas:

git push origin –tags

 Observe el lado web en este momento:

 

 Esta es la etiqueta.

6.5 Eliminar etiquetas

Si la etiqueta solo existe localmente, ejecute el comando directamente:

git tag -d v1.0

 Si la etiqueta se envió al control remoto, el primer paso es eliminar la etiqueta remota
, primero elimine la etiqueta local:

git tag -d v1.0

El segundo paso es eliminar la etiqueta remota:

git push origin :refs/tags/v1.0

Supongo que te gusta

Origin blog.csdn.net/zhangyuexiang123/article/details/121409368
Recomendado
Clasificación