Resuelva el problema de los conflictos de Git y la desaparición del código de combinación en Idea [consejos de uso común de git]

Resuelva el problema del conflicto de Git y la desaparición del código de fusión en Idea

Serie completa de comandos de Git

1 Pequeños problemas y habilidades de usar git en Idea

• Podemos extraer código directamente de plataformas como GitLab o GitHub a través de Idea

File - New - Project from Version Control

输入对应项目的URL即可

• Si los consejos anteriores no se pueden eliminar, intente verificar las opciones en la imagen a continuación
  

2 Idea para resolver problemas de conflicto

2.1 Conflictos de demostración (GitLab)

①Primero cree su propio almacén en GitLab o cualquier plataforma de alojamiento de código

git clone 仓库的URL

Clona el almacén con el comando anterior.

②En tu propio proyecto, crea una clase arbitrariamente

③ Envíelo al almacén local y luego envíelo al almacén remoto

④ Luego modifique el código arbitrariamente en la biblioteca remota

Agregué una oración aquí

⑤Modifique el código local e intente enviarlo al almacén remoto

En este momento, se producirán conflictos de versiones porque nuestro código local no es la última versión de la biblioteca remota.

⑥ Conflicto

2.2 Resolver conflictos de versiones de Git

①Elija rebase en este momento (debe elegir rebase, según lo exigen los estándares corporativos, la fusión directa puede causar una serie de problemas)

Debido a que antes usé rebase como opción predeterminada, me salté la selección aquí.

② Opere según sus propios requisitos

Accept Yours 就是直接选取本地的代码，覆盖掉远程仓库的
Accept Theirs是直接选取远程仓库的，覆盖掉本地的
Merge  自己手动进行选择，修改

③En circunstancias normales, realizaremos Mege manualmente

La parte izquierda aquí es el código de nuestro almacén local, la parte derecha es el código del almacén remoto y el resultado en el medio es lo que modificamos.

Como resultado, AcceptLeft y Accept Right en la esquina inferior izquierda son en realidad equivalentes a Accept Yours y Accept anteriores.

El suyo, Aplicar en la esquina inferior derecha confirma la fusión y Abortar cancela la fusión.

Después de modificar el código que queremos fusionar en el resultado, simplemente haga clic en Aplicar, en este punto el conflicto se resuelve.

Documentación detallada:
https://www.cnblogs.com/newAndHui/p/10851807.html

2.3 rebase falló

Si nuestra rebase falla:

Solución:

$ git add .(只要有修改都需要git add . 或者git add 具体的文件)
$ git rebase --continue
Applying: 【HCF】*******************
$ git push origin ******************************
git rebase --continue 就相当于 git commit 

3 Informe de errores de Git

Cuando Git entra en conflicto, accidentalmente hice clic en la operación de fusión, lo que provocó que los códigos en los almacenes locales y remotos desaparecieran de la nada.
Aquí, mi carpeta src fue eliminada.

3.1 Cuando Git opera la fusión, el código desaparece

① Descubra la confirmación que modificó el archivo especificado a través de git log.
El archivo del proyecto actual se ha eliminado, pero de acuerdo con la estructura del código del proyecto, se puede inferir que la carpeta src existía originalmente

Intenta detectar el procesamiento de este archivo en todos los registros históricos, el comando utilizado es el siguiente:

git log --stat --full-history --simplify-merges -- src

El comando anterior mostrará las confirmaciones que involucran cambios en esta carpeta. En el resultado, podemos ver que en la confirmación que termina en 857, eliminamos accidentalmente 11 líneas de código.

② Al cambiar a esta versión

git checkout 982918cd36668686c2644decbf0a0e4988283857

Luego regrese al proyecto, puede encontrar que nuestro código anterior ha sido restaurado.

¿Por qué existe tal situación?
Análisis: https://cloud.tencent.com/developer/article/2033888

3.2 Error de rebase de Git pull

git pull --rebase报错

error: cannot pull with rebase: Your index contains uncommitted changes.
error: please commit or stash them.

Esto se debe a que tenemos cambios locales que no se han enviado
. Si necesitamos enviar, podemos usar git add y git commit;
si no necesitamos enviar cambios, podemos usar git stash para almacenamiento temporal
. Pasos de la solución:

Siga las indicaciones para hacer lo siguiente

• alijo de git
• git pull --rebase
• git alijo pop

o:

• git agregar *
• git comprometerse
• git pull -rebase

Entonces podemos enviar

3.3 error de confirmación o clonación de git: errno 10054 o errno 10054

Registro de errores:

1. fatal: no se puede acceder a 'https://github.com/AliyunContainerService/k8s-for-docker-desktop.git/': OpenSSL SSL_read: la conexión se restableció, error 10054

o

2. fatal: no se puede acceder a 'https://github.com/xxx/autowrite.git/':
   no ​​se pudo conectar al puerto 443 de github.com: se agotó el tiempo de espera

razón:

• Porque cuando git extrae o envía proyectos, habrá servidores proxy http y https de git en el medio, pero nuestro entorno local tiene el protocolo SSL, así que cancele el proxy https de git y, si no, cancele el proxy http.
• Hay otra razón: la velocidad actual de la red proxy es demasiado lenta, por lo que ocasionalmente tiene éxito y ocasionalmente falla.

Solución:

1. , Ejecute el siguiente comando para cancelar el proxy https de git y use su propio proxy local. De lo contrario, git todavía se usa de forma predeterminada;

//取消http代理
git config --global --unset http.proxy
//取消https代理 
git config --global --unset https.proxy
//重新执行git clone 或git commit

2. Utilice Internet científicamente para resolver problemas de red.

4 Expansión:

4.1 La diferencia entre git clone y git pull

git clone no tiene un repositorio local y descarga todo el almacén remoto.

git pull es un repositorio local, descargue los nuevos datos de confirmación (si los hay) en el almacén remoto y combínelos con el código local

4.2 La diferencia entre fusionar y rebase

Explicación detallada: https://zhuanlan.zhihu.com/p/75499871
https://segmentfault.com/a/1190000038547167

rebase与merge实现，版本提交数风格会呈现不同的效果

• Rebase pondrá el compromiso de su rama actual al final de la rama pública, por eso se llama rebase. Es como si volvieras a sacar esta rama de la rama pública.
• Ejemplo: si extrae una rama prod del maestro y luego envía algunas confirmaciones, en este momento alguien simplemente fusiona su desarrollo en el maestro, y en este momento el maestro tiene algunas confirmaciones más que cuando extrajo la rama. Si cambia la base de master en este momento, sus confirmaciones actuales se colocarán detrás de las confirmaciones de esa persona.
• El efecto específico es el siguiente:

master 初始状态为1，2，3.在此基础上新建一个prod分支
master 提交了4，5.  prod分支提交了6，7.
此时分支状态：master->1-2-3-4-5
            prod ->1-2-3-6-7
在prod上使用rebase master，prod分支状态变成1-2-3-4-5-6-7            
如果merge master，prod分支状态变成1-2-3-6-7-8
        这里的8提交的是4-5合起来的提交
merge之后想回退到你分支上的某个提交就会很麻烦！

4.3 Enviar código localmente al extremo remoto

Por lo general, durante el desarrollo, nos comprometemos antes de confirmar, luego extraemos el almacén remoto para asegurarnos de que la versión actual sea la última y luego lo enviamos al almacén remoto.

• Seleccione la operación de fusión
  

• Seleccione la operación de rebase

4.4 Parte del código temporal no se envía al almacén remoto (git stash)

也可以参考4.9的方法：change list

Durante el desarrollo, inevitablemente nos encontraremos con colegas que necesitan que fusionemos código, pero en este momento también hemos escrito algunos localmente y, por algunas razones (no probadas), no queremos enviar estos códigos a la biblioteca remota.

Entonces, ¿qué debemos hacer en este momento? git stash funciona
① Haga clic derecho en el nombre del proyecto, seleccione git, seleccione cambios de almacenamiento (almacenamiento)

② Luego, git pull, extraiga el último código del almacén remoto para fusionar (fusionar)
③ Después de obtener el último código, desatascarlo, obtenerlo antes El código que escribir localmente

4.5 git pull origin master --permitir-historias-no relacionadas

POST git-upload-pack (327 bytes) Desde https://gitee.com/Zifasdfa/graduation-music * rama maestra -> FETCH_HEAD = [actualizado] maestro -> origen/maestro se niega a fusionar historias no relacionadas

La razón principal de este problema es que el almacén local y el almacén remoto son en realidad dos almacenes independientes. Si hubiera clonado directamente el repositorio local del repositorio remoto de github localmente, este problema no habría ocurrido.

git pull origin master --allow-unrelated-histories

puede resolver el problema

4.6 git elimina archivos que se han agregado

git elimina archivos que se han agregado

1. No elimina el archivo físico, solo borra el archivo del caché

git rm --cached "文件路径"

[Otros] ¿Cuál es la diferencia entre git rm --cache y git reset HEAD?
Si desea eliminar un archivo, es mejor usar git rm file_name en lugar de rm file_name directamente en el espacio de trabajo.
Si se agregó un archivo al área de almacenamiento temporal y aún no se ha confirmado, si no desea este archivo en este momento, existen dos métodos:
1. Borre el área de almacenamiento temporal con el contenido de la biblioteca de versiones, git reinicie HEAD pero úselo con cuidado
2. Solo coloque archivos específicos que se eliminen del área de almacenamiento temporal, git rm --cached xxx

2. No solo se eliminará el archivo de la caché, sino que también se eliminará el archivo físico (no se reciclará a la papelera).

git rm --f "文件路径"

• Para amigos que usan IDEA:

Puedes optar por ponerlo en espera temporalmente

Al confirmar, seleccione el archivo que desea archivar, haga clic derecho y seleccione Archivar cambios.

Puedes elegir cambios de alijo

Seleccione el proyecto, haga clic derecho para seleccionar git y busque cambios ocultos

• Agregar directamente al archivo ignorado

右击项目 - git - .git/info/exclude

3. También se puede implementar retrocediendo

Como se muestra en la imagen: accidentalmente agregué README.md al almacén local de git

通过rollback解决：

Seleccione el archivo que desea revertir y haga clic en revertir

Puede ver que README.md se ha vuelto rojo, lo que indica que no se ha agregado al almacén local.

4.7 Idea revierte el código local a la versión especificada y lo actualiza al control remoto al mismo tiempo

Puede encontrar un problema de este tipo durante el desarrollo, es decir, ha enviado el código incorrecto al almacén remoto y desea revertir el código remoto y local al mismo tiempo.

有两种方法：1、Revert操作  2、利用IDEA的Reset Head指针

• La operación Revertir del método 1 se tratará como un nuevo registro de envío y se agregará al registro de envío, conservando así el registro de envío original. (recomendar)
• El puntero Restablecer encabezado en el método 2 descartará el registro de envío original y forzará al puntero Head a apuntar a la versión especificada.

Después de modificar el contenido según la versión 1 y enviar los almacenes locales y remotos, descubrí que el contenido enviado no era lo que quería o era completamente incorrecto y necesitaba revertir la versión 1.

① Las sucursales locales y remotas actuales están en la posición de la segunda presentación.

• Haga clic derecho en la versión histórica que desea revertir y seleccione "Revertir" (consulte la figura a continuación)
  
  ② En este momento, debe resolver el conflicto

En este momento, aparecerá un cuadro de diálogo de conflicto. Haga doble clic en el archivo de conflicto para resolver el conflicto. (Vea abajo)

注意：Si la reversión falla, es posible que tenga otras modificaciones locales que no se hayan enviado, que pueden almacenarse temporalmente mediante alijo

your local changes would be overwritten by revert.
hint: commit your changes or stash them to proceed.
revert failed

operación de alijo:

③ Una vez resuelto el conflicto, el local volverá al código correcto antes de

④ Confirmar localmente y puede encontrar que el registro ha agregado un registro de reversión y, al mismo tiempo, presionar al remoto, puede encontrar que el control remoto y locales están sincronizados [ ] originRemoto

:

La ventaja de este tipo de reversión es que si se arrepiente de la operación de "reversión", también puede volver a la versión anterior a la reversión. Porque el registro histórico también conserva el registro de confirmación.

4.8 Uso de selección de cereza en git

elección de cereza: la mejor opción

Para el código de múltiples ramas, es común transferir código de una rama a otra.
En este momento se presentan dos situaciones:

1. Todos los cambios de código que requieren otra rama ( git merge 合并)
2. Algunos cambios de código, algunas confirmaciones ( cherry pick )

Por ejemplo, el repositorio de código tiene dos ramas, maestra y característica.

    a - b - c - d   Master
         \
           e - f - g Feature

Ahora aplique el compromiso f a la rama maestra.

# 切换到 master 分支
$ git checkout master

# Cherry pick 操作
$ git cherry-pick f

Una vez completadas las operaciones anteriores, la base del código tendrá el siguiente aspecto.

    a - b - c - d - f   Master
         \
           e - f - g Feature

Como puede ver en lo anterior, se agrega una confirmación f al final de la rama maestra.

• Los parámetros del comando git cherry-pick no son necesariamente el valor hash de la confirmación. El nombre de la rama también es aceptable, lo que indica que se transfiere la última confirmación de la rama.

$ git cherry-pick feature

El código anterior significa transferir la última confirmación de la rama de características a la rama actual.

4.9 Crear lista de cambios localmente (enviar el archivo especificado)

A veces, cuando extraemos varios elementos, a menudo nos encontramos con este problema:
修改了多个项目，但是只想提交一个项目中的代码entonces podemos crear una lista de cambios.

Por ejemplo, aquí solo queremos enviar DynamicLinkDTO

Entonces podemos crear localmente unchangelist

1. Botón derecho del ratón, directamentenew changelist
   
2. Mueva el código que queremos enviar al que acabamos de crear changelist, como por ejemplo: default_change
   
3. Seleccione nuestro default_change, haga clic derecho, luego seleccione git y presione
   

4.10 Hay almacenes de git localmente y gitee tiene almacenes de git, cómo fusionarlos

git pull origin master --allow-unrelated-histories

o

# 添加远程地址
git remote add origin https://gitee.com/Zifasdfa/ziyi-app.git
git push -u origin "master"

• git pull origin master --allow-un related-histories: este comando se utiliza para fusionar la rama maestra del almacén remoto con la rama actual del almacén local.
  • El parámetro --allow-un related-histories se utiliza para permitir fusionar dos ramas del historial no relacionadas. Este comando es adecuado para operaciones de fusión entre dos repositorios.
• git push -u origin "master": este comando se utiliza para enviar la rama maestra del almacén local al almacén remoto.
  • El parámetro -u se usa para configurar la rama ascendente para que git push pueda usarse directamente para el siguiente envío. Este comando es adecuado para operaciones de envío a un único almacén.

4.11 El envío de confirmación de git es demasiado lento

Encuentra la configuración de git y cierraanalyze code

4.12 pago inteligente y pago forzado de git

Cuando IDEA modifica el contenido en una rama sin confirmarlo y luego cambia a otra rama, pueden ocurrir conflictos.

En este momento, IDEA mostrará un mensaje emergente pidiéndole que elija Smart Checkout o Force Checkout:

• Si desea mantener sus modificaciones en la rama original, elija Smart Checkout,

• Force Checkout no mantendrá tus modificaciones, el contenido desaparecerá cuando cambies a otra rama y no podrás recuperar la rama original si vuelves a cambiar, por lo que no sirve de nada.

Principio: seleccione Smart Checkout, IDEA primero ejecutará el comando de almacenamiento para almacenar estas modificaciones no confirmadas y luego realizará el pago en la rama B. Después de cambiar a la rama B, deshaga estas modificaciones, de modo que las modificaciones locales de la rama A se lleven a la rama B. .

4.13 Inconsistencia del buzón

A veces, cuando estamos desarrollando, alternamos entre el correo electrónico de nuestro github o gitee y el del gitlab de la empresa.

Si encontramos los siguientes problemas cuando modificamos el código de la empresa y lo enviamos, entonces:

remoto: Excepción de inserción: este envío a84887a5d29a8643fd6ef45904b47f2067dbcc35 detecta que la dirección de correo electrónico ([email protected]) establecida por su cliente local no es la dirección de correo electrónico ([email protected]) que configuró en GitLab, asegúrese de que su local y remoto ¡La dirección de correo electrónico es la misma!

En este punto debemos verificar si la configuración de nuestro buzón de correo local de git es consistente con la configurada en gitlab:

# 查看git全局邮箱配置
git config --global user.email

# 修改git全局邮箱配置
git config --gloabl user.email yyyss@xxx.com.cn

# 修改私有配置（某个git文件的）
git config user.email ziyi@163.com

Luego presionamos nuevamente, y si encontramos que el error aún se informa, puede ser porque nuestra confirmación todavía usa el buzón anterior y no generamos una nueva confirmación, por lo que no pudimos usar el nuevo buzón.修改注释或者增加空行，然后commit即可解决

4.14 Las actualizaciones fueron rechazadas porque la punta de su rama actual está atrasada

Este error generalmente ocurre cuando el historial de confirmaciones de su sucursal local y la sucursal remota son inconsistentes. La solución es extraer la última confirmación de la sucursal remota antes de enviarla a su sucursal local.

# 1. 切到本地分支
git checkout main
# 2. 拉取远程分支
git pull origin main
# 如果有冲突产生，需要解决冲突后再继续

Artículos de referencia:
https://blog.csdn.net/Torey_Li/article/details/87442355
https://blog.csdn.net/woshi1226a/article/details/86664159
https://blog.csdn.net/Deronn/article /details/106574498
https://blog.csdn.net/good_good_xiu/article/details/118567249