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