Resolva problemas de conflito do Git e mescle problemas de desaparecimento de código no Idea [dicas comuns do git]

Resolva problemas de conflito do Git e mescle problemas de desaparecimento de código no Idea

Série completa de comandos Git

1 Pequenos problemas e habilidades de uso do git no Idea

• Podemos extrair código diretamente de plataformas como GitLab ou GitHub através do Idea

File - New - Project from Version Control

输入对应项目的URL即可

• Se você não conseguir retirá-lo com as dicas acima, tente verificar a opção na imagem abaixo.
  

2 Ideia para resolver questões de conflito

2.1 Conflitos de demonstração (GitLab)

①Primeiro crie seu próprio warehouse no GitLab ou em qualquer plataforma de hospedagem de código

git clone 仓库的URL

Clone o warehouse com o comando acima

②Em seu próprio projeto, crie uma classe arbitrariamente

③ Envie-o para o armazém local e, em seguida, envie-o para o armazém remoto

④ Em seguida, modifique o código arbitrariamente na biblioteca remota

Aqui eu adicionei uma frase

⑤Modifique o código local e tente enviá-lo para o armazém remoto

Neste momento, ocorrerão conflitos de versão porque nosso código local não é a versão mais recente da biblioteca remota.

⑥Conflito ocorre

2.2 Resolvendo conflitos de versão do Git

①Escolha o rebase neste momento (deve escolher o rebase, conforme exigido pelos padrões corporativos, a fusão direta pode causar uma série de problemas)

Como usei rebase como opção padrão antes, pulei a seleção aqui.

② Opere de acordo com seus próprios requisitos

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

③Em circunstâncias normais, iremos Mege manualmente

A parte esquerda aqui é o código do nosso armazém local, a parte direita é o código do armazém remoto e o resultado no meio é o que modificamos.

Como resultado, AcceptLeft e Accept Right no canto inferior esquerdo são, na verdade, equivalentes aos anteriores Accept Yours e Accept.

Deles, Aplicar no canto inferior direito confirma a mesclagem e Abortar cancela a mesclagem.

Após modificarmos o código que queremos mesclar no resultado, basta clicar em Aplicar. Neste ponto o conflito está resolvido.

Documentação detalhada:
https://www.cnblogs.com/newAndHui/p/10851807.html

2.3 rebase falhou

Se nosso rebase falhar:

a solução:

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

3 Relatório de erros do Git

Quando houve um conflito no Git, cliquei acidentalmente na operação de mesclagem, fazendo com que os códigos nos armazéns locais e remotos desaparecessem do nada
. Aqui, minha pasta src foi excluída.

3.1 Quando o Git opera a mesclagem, o código desaparece

① Use git log para encontrar o commit que modificou o arquivo especificado
. O arquivo do projeto atual foi excluído, mas de acordo com a estrutura do código do projeto, pode-se inferir que a pasta src existia originalmente

Tente detectar o processamento deste arquivo em todos os registros históricos. O comando utilizado é o seguinte:

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

O comando acima exibirá os commits envolvidos nas alterações na pasta. Pela saída, podemos ver que no commit que termina em 857, excluímos acidentalmente 11 linhas de código.

② Ao mudar para esta versão

git checkout 982918cd36668686c2644decbf0a0e4988283857

Em seguida, volte ao projeto e você descobrirá que nosso código anterior foi restaurado

Por que existe tal situação?
Análise: https://cloud.tencent.com/developer/article/2033888

3.2 Relatório de erro Git pull --rebase

git pull --rebase报错

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

Isso ocorre porque temos alterações locais que não foram enviadas.
Se precisarmos enviar, basta git add, git commit; submit.
Se não precisarmos enviar as alterações, apenas git stash,
armazenamento temporário. Etapas da solução:

Siga as instruções para realizar as seguintes operações

• esconderijo
• git pull --rebase
• git stash pop

ou:

• adicionar *
• git commit
• git pull -rebase

Então podemos enviar

3.3 git clone ou erro de commit: errno 10054 ou errno 10054

Registro de erros:

1. fatal: não foi possível acessar 'https://github.com/AliyunContainerService/k8s-for-docker-desktop.git/': OpenSSL SSL_read: a conexão foi redefinida, errno 10054

ou

2. fatal: não foi possível acessar 'https://github.com/xxx/autowrite.git/':
   falha ao conectar-se à porta 443 do github.com: tempo limite esgotado

razão:

• Porque quando o git puxa ou envia um projeto, haverá proxies http e https do git no meio, mas nosso próprio ambiente local tem um protocolo SSL, então cancele o proxy https do git. Se isso não funcionar, cancele o proxy http .
• Há outro motivo: a velocidade atual da rede proxy é muito lenta, por isso ocasionalmente funciona e falha ocasionalmente.

Solução:

1. , execute o seguinte comando para cancelar o proxy https do próprio git e usar seu próprio proxy local. Caso contrário, o git será usado por padrão;

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

2. Internet científica, resolva problemas de rede

4 Expansão:

4.1 A diferença entre git clone e git pull

git clone não possui um repositório local e baixa todo o warehouse remoto.

Git pull tem um repositório local, baixa os novos dados de commit (se houver) no warehouse remoto e os mescla com o código local

4.2 A diferença entre mesclar e rebase

Explicação detalhada: https://zhuanlan.zhihu.com/p/75499871
https://segmentfault.com/a/1190000038547167

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

• O Rebase colocará o commit do seu branch atual no final do branch público, por isso é chamado de rebase. É como se você puxasse esse ramo do ramo público novamente.
• Por exemplo: se você extrair um branch prod do master e, em seguida, enviar alguns commits, e alguém mesclar as coisas que ele desenvolveu no master, então o master terá vários commits a mais do que quando você puxou o branch. master neste momento, seus commits atuais serão colocados atrás dos commits daquela pessoa.
• Os efeitos específicos são os seguintes:

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 local para remoto

Normalmente, durante o desenvolvimento, faremos o commit antes do commit, depois puxaremos o warehouse remoto para garantir que a versão atual seja a versão mais recente e, em seguida, enviaremos para o warehouse remoto.

• Selecione a operação de mesclagem
  

• Selecione a operação de rebase

4.4 Parte do código temporário não é enviada ao armazém remoto (git stash)

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

Durante o desenvolvimento, inevitavelmente encontraremos colegas que precisam mesclar códigos, mas neste momento também escrevemos alguns localmente e, por alguns motivos (nenhum teste concluído), não queremos enviar esses códigos para a biblioteca remota.

Então, o que devemos fazer neste momento? git stash funciona
① Clique com o botão direito no nome do projeto, selecione git, selecione alterações de stash (armazenar)

② Em seguida, git pull, extraia o código mais recente do armazém remoto para mesclar (mesclar)
③ Depois de obter o código mais recente, descompacte, obtenha o anterior code O código que escrevemos localmente

4.5 git pull origin master --allow-não relacionados-históricos

POST git-upload-pack (327 bytes) De https://gitee.com/Zifasdfa/graduation-music * branch master -> FETCH_HEAD = [atualizado] master -> origin/master recusando-se a mesclar históricos não relacionados

A principal razão para este problema é que o armazém local e o armazém remoto são, na verdade, dois armazéns independentes. Se eu tivesse clonado diretamente o repositório local do repositório remoto do github localmente, esse problema não teria ocorrido.

git pull origin master --allow-unrelated-histories

resolverá o problema

4.6 git remove os arquivos que foram adicionados

git remove arquivos que foram adicionados

1. Não exclui o arquivo físico, apenas limpa o arquivo do cache

git rm --cached "文件路径"

[Outros] Qual é a diferença entre git rm --cache e git reset HEAD?
Se você deseja excluir um arquivo, é melhor usar git rm file_name em vez de rm file_name diretamente no espaço de trabalho.
Se um arquivo foi adicionado à área de teste e ainda não foi confirmado, se você não deseja mais o arquivo, existem dois métodos:
1. Limpe a área de teste com o conteúdo do repositório, git reset HEAD mas use-o com cuidado
. 2. Use apenas para excluir arquivos específicos da área de teste, git rm --cached xxx

2. Não apenas o arquivo será removido do cache, mas o arquivo físico também será excluído (não reciclado para a lixeira)

git rm --f "文件路径"

• Para amigos que usam IDEA:

Você pode optar por colocá-lo em espera temporariamente

Ao confirmar, selecione o arquivo que deseja arquivar, clique com o botão direito e selecione Arquivar alterações

Você pode escolher mudanças no stash

Selecione o projeto, clique com o botão direito para selecionar git e encontre as alterações no stash

• Adicione diretamente ao arquivo ignorado

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

3. Também pode ser alcançado revertendo

Conforme mostrado na imagem: adicionei acidentalmente README.md ao repositório local git

通过rollback解决：

Selecione o arquivo que deseja reverter e clique em reverter

Você pode ver que README.md ficou vermelho, indicando que não foi adicionado ao warehouse local.

4.7 O Idea reverte o código local para a versão especificada e o atualiza para o remoto ao mesmo tempo

Você pode encontrar esse problema durante o desenvolvimento, ou seja, enviou o código errado para o warehouse remoto e deseja reverter o código remoto e local ao mesmo tempo.

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

• A operação Reverter do método 1 será tratada como um novo registro de envio e anexada ao log de envio, mantendo assim o registro de envio original. (recomendar)
• O ponteiro Reset Head no método 2 descartará o registro de envio original e forçará o ponteiro Head a apontar para a versão especificada.

Depois de modificar o conteúdo com base na versão 1 e enviá-lo aos armazéns locais e remotos, descobri que o conteúdo enviado não era o que eu queria ou estava completamente errado e precisei reverter para a versão 1.

① Atualmente, as filiais locais e remotas estão no local da segunda submissão.

• Clique com o botão direito na versão histórica que deseja reverter e selecione "Reverter" (veja a imagem abaixo)
  
  ② Neste momento, o conflito precisa ser resolvido

Uma caixa de diálogo de conflito aparecerá. Clique duas vezes no arquivo de conflito para resolvê-lo. (Veja abaixo)

注意：Se a reversão falhar, pode ser que você tenha outras modificações locais que não foram enviadas, que podem ser armazenadas temporariamente por meio do stash.

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

operação de armazenamento:

③ Depois que o conflito for resolvido, o código local retorna ao código correto anterior

④ Confirme localmente novamente, você pode descobrir que um registro de reversão foi adicionado ao log e enviar para o controle remoto ao mesmo tempo, você pode descobrir que ambos o remoto e o local são sincronizados [] originRemoto

:

A vantagem desse tipo de reversão é que se você se arrepender da operação de "reversão", também poderá reverter para a versão anterior à reversão. Porque o histórico também mantém registros de commits.

4.8 Uso do Cherry Pick no git

escolha de cereja: melhor escolha

Para código com várias ramificações, é comum mover o código de uma ramificação para outra.
Existem duas situações neste momento:

1. Todas as alterações de código que exigem outra ramificação ( git merge 合并)
2. Algumas mudanças de código, alguns commits ( cherry pick )

Por exemplo, o repositório de código possui duas ramificações: master e feature.

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

Agora aplique commit f ao branch master.

# 切换到 master 分支
$ git checkout master

# Cherry pick 操作
$ git cherry-pick f

Depois que as operações acima forem concluídas, a base de código terá a seguinte aparência.

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

Como você pode ver acima, um commit f é adicionado ao final do branch master.

• Os parâmetros do comando git cherry-pick não são necessariamente o valor hash do commit. O nome do branch também é aceitável, indicando que o último commit do branch foi transferido.

$ git cherry-pick feature

O código acima significa transferir o commit mais recente da ramificação do recurso para a ramificação atual.

4.9 Criar lista de alterações localmente (enviar arquivo especificado)

Às vezes, quando extraímos vários projetos, frequentemente encontramos este problema:
修改了多个项目，但是只想提交一个项目中的代码, então você pode criar uma lista de alterações

Por exemplo, aqui queremos apenas enviar DynamicLinkDTO

Então podemos criar localmente umchangelist

1. Botão direito do mouse, diretamentenew changelist
   
2. Mova o código que queremos enviar para aquele que acabamos de criar changelist, como: default_change
   
3. Selecione nosso default_change, clique com o botão direito, selecione git e push
   

4.10 Existe um armazém git localmente e um armazém git no gitee. Como mesclar?

git pull origin master --allow-unrelated-histories

ou

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

• git pull origin master --allow-unrelated-histories: Este comando é usado para mesclar a ramificação master do warehouse remoto com a ramificação atual do warehouse local.
  • O parâmetro –allow-un Related-histories é usado para permitir a fusão de duas ramificações do histórico não relacionadas. Este comando é adequado para mesclar operações entre dois armazéns.
• git push -u origin "master": Este comando é usado para enviar a ramificação master do warehouse local para o warehouse remoto.
  • O parâmetro -u é usado para definir a ramificação upstream para que git push possa ser usado diretamente na próxima vez que você fizer push. Este comando é adequado para operações push para um único armazém.

4.11 O envio de commit do git é muito lento

Encontre as configurações do git e fecheanalyze code

4.12 checkout inteligente e checkout forçado do git

Quando o IDEA modifica o conteúdo em uma ramificação sem confirmá-lo e depois muda para outra ramificação, podem ocorrer conflitos.

Neste momento, o IDEA exibirá um prompt solicitando que você escolha Smart Checkout ou Force Checkout:

• Se você quiser manter suas modificações na filial original, escolha Smart Checkout,

• Force Checkout não manterá suas modificações. Se você mudar para outro branch, o conteúdo desaparecerá e se você voltar para o branch original, não será possível recuperá-los. É uma perda de tempo.

Princípio: Selecione Smart Checkout, o IDEA primeiro executará o comando stash para armazenar essas modificações não confirmadas e, em seguida, fará o checkout na filial B. Depois de mudar para a filial B, ele irá desfazer o stash dessas modificações, de modo que essas modificações locais na filial A serão trazidas para a filial B. .

4.13 Inconsistência na caixa de correio

Às vezes, quando estamos desenvolvendo, alternamos entre o e-mail em nosso github ou gitee e aquele no gitlab da empresa.

Se encontrarmos os seguintes problemas ao modificar o código da empresa e enviar, então:

remoto: exceção push: este envio a84887a5d29a8643fd6ef45904b47f2067dbcc35 detecta que o endereço de e-mail definido pelo seu cliente local ([email protected]) não é o endereço de e-mail que você definiu no GitLab ([email protected]). Certifique-se de que seu endereço de e-mail local e remoto O endereço de e-mail é o mesmo!

Neste ponto, devemos verificar se a configuração da nossa caixa de correio git local é consistente com aquela definida no 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

Em seguida, pressionamos novamente e descobrimos que, se um erro ainda for relatado, pode ser porque nosso commit ainda usa o endereço de e-mail anterior. Não geramos um novo commit, portanto o novo endereço de e-mail não foi usado com sucesso.修改注释或者增加空行，然后commit即可解决

4.14 As atualizações foram rejeitadas porque a ponta da sua filial atual está atrasada

Este erro geralmente ocorre quando o histórico de commits da sua filial local e da filial remota são inconsistentes. A solução é extrair o commit mais recente da filial remota antes de enviar para a filial local.

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

Artigos de referência:
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