Resumen de uso no oficial de Git

Dirección original: https://blog.dpf114.top/posts/git-often-used/

1. ¿Qué sistema de control de versiones?

Hablando por separado sobre el control de versiones, es posible que no sepamos qué es, pero para un pequeño ejemplo en nuestras vidas, podemos entender fácilmente qué es.

Por ejemplo, hemos revisado la tesis innumerables veces después de la graduación:

毕业论文最终版
毕业论文最最终版
毕业论文最最最终版
毕业论文最最最最终版
毕业论文最终不改版
毕业论文最终真不改版
毕业论文最终真真不改版
毕业论文最终打死不改版
毕业论文最终打死不改版 2

...

Hay muchas versiones, y el sistema de control de versiones es el sistema que controla las diferentes versiones del contenido que escribimos.

Los sistemas de control de versiones más utilizados son SVNy Git. Usamos mucho Git en el desarrollo real.

2. Instalación y configuración

2.1. Instalación

Ventanas

Para Windows, simplemente descargue el paquete de instalación e instálelo directamente.

Linux

Utilice la herramienta apt-get para descargar e instalar

apt-get update
sudo apt-get install git

Mac

Utilice la herramienta de preparación para descargar e instalar

brew install git

2.2. Configuración después de la instalación

Independientemente de si se trata de una instalación de Windows o una instalación de Linux, una vez finalizada la instalación, primero realizaremos una configuración básica a través de las siguientes dos líneas de comandos. El propósito es distinguir las identidades de los diferentes desarrolladores, es decir, quién envió cada presentación. El método de configuración es el siguiente:

git config --global user.name 'username'
git config --global  user.email '[email protected]'

Una vez completada la configuración, la información de configuración se almacena en el ~/.gitconfigarchivo

3. Uso básico

Antes de la operación básica, necesitamos comprender las particiones que usa Git

• Área de trabajo: el área de trabajo es donde normalmente escribimos el código.
• Área de almacenamiento temporal: git addun lugar para almacenar temporalmente el código después del envío
• Biblioteca local: a través git commitdel lugar donde se almacena el código después del envío, la biblioteca local guarda información relacionada con la versión histórica.
• Bibliotecas remotas: las bibliotecas remotas también son repositorios de código remoto, como Gitee, GitHub y gitlab.

3.1. Inicializar el almacén

Hay dos formas de inicializar el almacén, una es clonar desde un almacén remoto y la otra es inicializar directamente desde el directorio actual. El comando es el siguiente:

git init

Una vez completada la implementación, habrá más de una .gitcarpeta oculta del directorio actual , todos gitlos datos y recursos necesarios se almacenan en el directorio.

3.2. Ver el estado del almacén

git statusPuede ver el estado del almacén a través de comandos. El estado de vista de almacén recién inicializado es el siguiente:

Después de modificar el espacio de trabajo, verifique el estado como se muestra en la siguiente figura:

Después de enviar el área de almacenamiento temporal, verifique el estado como se muestra en la siguiente figura:

Después de enviarlo al almacén local, verifique el estado como se muestra a continuación:

3.3. Presentar al área de preparación

A través git adddel contenido del área de trabajo que se puede enviar al área de almacenamiento temporal, existen los siguientes casos de uso:

git add 具体文件
git add .
git add *

.*Ambos y ambos representan todos los archivos enviados al espacio de trabajo.

3.4. Enviar a la biblioteca local

Al git commitenviar el contenido del área de almacenamiento temporal al almacén local, el uso específico es el siguiente:

git commit -m '提交描述内容'

Nota: El contenido de la descripción no puede estar vacío. Se recomienda escribir claramente el contenido de cada envío, que se puede utilizar para la reversión de la versión.

3.5. Enviar a almacén remoto

Si el almacén se inicializa mediante la clonación, después de enviarlo al almacén local, puede git pushenviarlo directamente al almacén remoto directamente. Si es a través de la git initinicialización, debe crear el almacén correspondiente de forma remota y luego asociar el almacén local con el almacén remoto. y úselo más tarde git push.

Almacén remoto asociado

Utilice git remotecomandos para asociar almacenes remotos, el formato es el git remote add 别名 远程仓库urlsiguiente

git remote add origin https://github.com/xiaoxiaoshou/testgit.git

Url donde puede que ambos tipos, respectivamente, https://github.com/username/reponame.gity [email protected]:username/reponame.github.io.gitgit representen dos conexiones diferentes.

Otros comandos relacionados relacionados con el almacén remoto:

# 查看关联了哪些远程分支
git remote -v
# 删除关联分支
git remote remove 别名

Enviar al almacén remoto

El formato del comando de envío es el git push 别名 分支名siguiente:

git push origin master

3.6. Extraer código del control remoto

Hay dos métodos de uso común:

1. Usa git clone

Extraiga de la rama maestra remota de forma predeterminada:

git clone 远程url地址

Tirón de rama designado:

git clone -b 分支名称 远程url地址

Usa git pull

Usar formato git pull <远程主机名> <远程分支名>:<本地分支名>.

Por ejemplo, queremos extraer la rama maestra del origen remoto y fusionarla con la rama maestra local.

git pull origin master:master

También podemos simplificar a

git pull origin master
git pull origin 
git pull 

git pull = git fetch+git merge, La función de buscar es extraer código de forma remota, y la función de fusionar es fusionar código (la administración de la sucursal se analizará en detalle más adelante)

4. Revocación del código y reversión de la versión

4.1. Ver registros de envíos

Utilice git logpara ver la información enviada, cada envío ( git commit) al almacén local, la información detallada, cada información de envío es aproximadamente la siguiente:

commit cdc2ac8c3b6d9f8bde05140aca484aa4482f8895
Author: xiaoxiaoshou <[email protected]>
Date:   Tue Dec 1 15:41:13 2020 +0800

    提交描述内容

El número después de la confirmación es un índice para cada envío (podemos llamarlo número de versión), que se usa para avanzar o rebobinar la versión.

Utilizar git logel contenido que se muestra demasiado, generalmente usamos el doble sentido relativamente simple siguiente para ver:

# 推荐使用
git reflog

git log --online

4.2. Cancelación del código de área de trabajo

Puede que un día que esté escribiendo código, escribiendo durante mucho tiempo haya encontrado un error y le gustaría volver a su estado inicial, eliminar una forma estúpida es simplemente escribir el código línea por línea, pero de esta manera es demasiado costoso, usted puede git checkout -- <file>ordenar Deshacer la modificación del código en el espacio de trabajo. Como se muestra abajo:

4.3. Deshacer código agregado al área de preparación

Desea cancelar el código enviado al área de preparación en los siguientes dos pasos:

• 1. Deshaga el código de área de almacenamiento temporal en el área de trabajogit reset HEAD

• 2. Cancele el código de área de trabajo (lo mismo que la revocación del código de área de trabajo)git checkout -- file

4.4. Enviar al almacén local la reversión de la versión del código

Revertir según la versión del índice (recomendado)

1. Ver historial de envíos

2. Usar git reset --hard [局部索引值]atrás (adelante y atrás)

Usa el símbolo ^

git reset --hard^

Un ^paso atrás

Usa el símbolo ~

git reset --hard~n	

n representa el número de pasos hacia atrás

Comparación de tres parámetros en git reset

git reset --soft
git reset --mixed
git reset --hard

• -suave
  • Solo mueva el puntero HEAD en la biblioteca nativa
• -mezclado
  • Mueva el puntero HEAD en el almacén local
  • Restablecer el área de preparación
• -difícil
  • Mover el puntero HEAD en la biblioteca local
  • Restablecer el área de preparación
  • Restablecer espacio de trabajo

4.5. Enviar a la reversión de la versión del almacén remoto

Dado que el contenido del almacén remoto es coherente con el almacén local, es necesario revertir la versión del almacén remoto y solo se revierte la versión local y luego se envía al almacén remoto.

5. Gestión de sucursales

5.1. ¿Qué es una rama?

Cuando completamos un proyecto, es imposible desarrollarlo de manera "single-thread", muchas veces las tareas son paralelas. Déjame darte una idea: la versión 2.0 del proyecto está en línea, y ahora vamos a desarrollar la versión 3.0. Al mismo tiempo, puede haber algunos errores en la versión 2.0 que deben corregirse. Después de que estos errores sean corregidos , podemos lanzar 2.1, 2.2 y 2.3. No podemos esperar a todos. Después de que todos los errores sean corregidos, desarrollaremos la versión 3.0. Arreglar los errores de 2.0 y desarrollar nuevas características de 3.0 son dos tareas paralelas. En este momento, definitivamente no es adecuado que desarrollemos funciones 3.0 directamente en la rama maestra. Debemos asegurarnos de que exista una rama estable que pueda ser liberada en cualquier momento (en general, este papel lo desempeña el master branch), en este momento podemos usar de manera flexible la función de administración de sucursales en Git:

1. Cree una rama a largo plazo para desarrollar características 3.0. Suponiendo que el nombre de esta rama es v3, agregamos nuevas características a la v3 y continuamos probándola. Cuando v3 es estable, fusionamos v3 en la rama maestra.
2. Cree una rama de funciones para corregir errores de 2.0. Una vez que el error se solucione con éxito, la rama se fusionará con el maestro. Una vez que se encuentre un nuevo error, la rama se creará inmediatamente para corregirlo y luego se fusionará después de que la reparación sea exitosa .

5.2. Ver rama

Podemos usar el comando git branchpara ver en qué sucursales del almacén actual y la sucursal en la que estamos actualmente

*La sucursal de enfrente es nuestra sucursal actual.

5.3. Crear y cambiar de rama

el primer método

• Primer uso para git branch 分支名crear una rama
• Luego usa la git checkout 分支名rama del interruptor

El segundo metodo

Úselo para git checkout -b 分支名crear y cambiar de rama en un solo paso.

5.4. Rama de integración

Hay dos formas de integración de ramas, una es merge, la otra esrebase

unir

Utilice comandos para git merge [有新内容的分支名]fusionar ramas.

La figura anterior explica: la rama principal encontró un error en m1, así que elimine una rama bugFix, después de un período de tiempo, la rama principal se desarrolló a m3, la rama bugFix (enviada como m2), el error se resolvió, y la rama bugFix debe fusionarse con La rama principal es usar el comando git merge bugFix.

rebase

Rebase también se llama rebase, y git rebase [有新内容的分支]puede usar comandos para rebase .

Análisis de la figura anterior: La figura anterior es utilizar el comando git rebase bugFixpara integrar la rama en la rama principal . El proceso de integración consiste en registrar el envío del bugFix en la rama principal y volver a enviarlo de abajo hacia arriba.

La diferencia entre fusionar y rebase

• Fusionar es fusionar la rama actual y la rama que se fusionarán juntas, y hacer un envío de confirmación

• Rebase es volver a enviar el envío histórico de la rama para que se vuelva a establecer en la rama actual en orden, y la posición de HEAD permanece sin cambios después de la rebase (es decir, * en la figura)

• Los conflictos pueden ocurrir durante el proceso de rebase, continúe enviando después de que se resuelva el conflicto

  • La resolución de conflictos
  • Comprometerse a amortiguargit add .
  • Continuar para completar la fusióngit rebase --continue

  Lo siguiente es parte del conflicto

  <<<<<<< HEAD
  需要合并分支的内容
  =======
  当前分支内容
  >>>>>>> 
  

6. Gestión de etiquetas

Podemos etiquetar un determinado envío para mostrar que es importante. Las etiquetas más representativas lo utilizan para lanzar la versión de la aplicación correspondiente, como v1.0, v2.0. Git admite dos tipos de etiquetas: ligeras y anotadas.

Podemos usar el siguiente comando para ver todas las etiquetas en el almacén:

git tag

6.1. Etiquetas ligeras

Una etiqueta ligera se parece mucho a una rama que no cambia, es solo una referencia a una confirmación específica. Básicamente, la etiqueta ligera almacena la suma de comprobación enviada en un archivo; no se guarda ninguna otra información.

Formato de etiquetado ligero git tag 标签名称, por ejemplo:

git tag v0.0

Las etiquetas ligeras son las más recientes de forma predeterminada commit.

También podemos commitetiquetar y formatear la designación git tag 标签名称 commi对应索引. Los ejemplos son los siguientes

# 查看commit索引
git reflog
# 打标签
git tag v0.01 bcde256

También podemos eliminar etiquetas y formatos en el almacén local git tag -d 标签名称, por ejemplo:

git tag -d v0.01

6.2. Etiqueta de nota

La etiqueta de la nota es un objeto completo almacenado en el almacén, tiene su propia información de suma de verificación, que contiene el nombre de la etiquetadora, dirección de correo electrónico, fecha y hora, e información de la etiqueta. Se puede GNU Privacy Guard （GPG)firmar y verificar.

El formato de la etiqueta de la nota es el git tag -a 标签名称 -m '标签信息'siguiente:

git tag -a v1.0 -m 'my version 1.0'

6.3. Enviar etiquetas al almacén remoto

De forma predeterminada, el git pushcomando no envía etiquetas al almacén remoto. Necesitamos empujar manualmente la etiqueta al almacén remoto, el formato push git push 远程分支别名 标签名, por ejemplo:

git push origin v1.0

---

Materiales de referencia:

https://git-scm.com/book/zh/v2

https://www.runoob.com/git/git-tutorial.html

https://segmentfault.com/a/1190000037465780

Aprenda mientras juega: https://learngitbranching.js.org/?locale=zh_CN