Como resolvo conflitos de mesclagem no Git?
A postagem do blog a seguir parece dar um exemplo muito bom de como lidar com conflitos de mesclagem com o Git, que devem levá-lo na direção certa. Manuseio e evitar conflitos na Git
Você pode configurar uma ferramenta de mesclagem (kdiff3 jebaird.com/2013/07/08/… ) e usar o git mergetool. Quando você trabalha em grandes equipes de desenvolvedores, sempre encontra conflitos de mesclagem.
— Grady Cooper L
Não esqueça que você pode atenuar a maioria dos conflitos de mesclagem mesclando regularmente a jusante!
Veja também git-tower.com/learn/git/ebook/command-line/tools-services/…
Pergunta fascinante: feita em 2008, 100% aberto terminou sem nenhuma dica sobre o que realmente é (trata-se de GUI? Sobre os comandos git? Sobre semântica? Sobre empurrar / puxar ou apenas conflitos gerais?) - completamente sem resposta. 30 respostas, todas (até onde uma rápida olhada mostra) mais ou menos falando sobre diferentes ferramentas diff3 e de mesclagem, nenhuma aceita. A resposta mais votada menciona um comando que nem funciona imediatamente com uma gitinstalação padrão . Consegui acessar a página inicial do SE hoje, 2017, com 1,3 milhão de visualizações e milhares de votos nos dois sentidos. Fascinante.
Tentar: git mergetool
Ele abre uma GUI que o orienta em cada conflito e você escolhe como mesclar. Às vezes, requer um pouco de edição manual depois, mas geralmente é suficiente por si só. É muito melhor do que fazer a coisa toda com a mão, certamente.
De acordo com o comentário @ JoshGlover:
não abre necessariamente uma GUI, a menos que você instale uma. Correr git mergetoolpara mim resultou em vimdiffser usado. Você pode instalar um dos seguintes ferramentas para usá-lo em vez disso: meld, opendiff, kdiff3, tkdiff, xxdiff, tortoisemerge, gvimdiff, diffuse, ecmerge, p4merge, araxis, vimdiff, emerge.
Abaixo está o procedimento de exemplo a ser usado vimdiffpara resolver conflitos de mesclagem. Com base neste link
Etapa 1 : Execute os seguintes comandos no seu terminal
Isso definirá o vimdiff como a ferramenta de mesclagem padrão.
Etapa 2 : Execute o seguinte comando no terminal
Etapa 3 : Você verá uma exibição do vimdiff no seguinte formato
Essas 4 visualizações são
LOCAL - esse é o arquivo da ramificação atual
BASE - ancestral comum, como o arquivo parecia antes das duas alterações
REMOTO - arquivo que você está mesclando em sua filial
MERGED - mesclar resultado, é isso que é salvo no repositório
Você pode navegar entre essas visualizações usando ctrl+ w. Você pode acessar diretamente a visualização MERGED usando ctrl+ wseguido de j.
Mais informações sobre a navegação vimdiff aqui e aqui
Etapa 4 . Você pode editar a exibição MERGED da seguinte maneira
Se você deseja obter alterações do REMOTE
Se você deseja obter alterações do BASE
Se você deseja obter alterações de LOCAL
Etapa 5 . Salvar, Sair, Confirmar e Limpar
:wqa salvar e sair do vi
git clean Remova arquivos extras (por exemplo, * .orig) criados pela ferramenta diff.
Para sua informação, você pode usar git mergetool -ypara salvar algumas teclas pressionadas se estiver mesclando muitos arquivos de uma só vez.
Bem, ele não abre necessariamente uma GUI, a menos que você instale uma. Correr git mergetoolpara mim resultou em vimdiffser usado. Você pode instalar um dos seguintes ferramentas para usá-lo em vez disso: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis vimdiff emerge.
Bom ponto Josh. No ubuntu, tive a melhor sorte com o meld, sua exibição de mesclagem em três direções não é ruim. No OSX, o git escolheu um bom padrão.
Isso abriu o KDiff3. Que eu não tenho absolutamente nenhuma idéia de como usar.
Você também pode usar o Beyond Compare 3 agora ( git mergetool -t bc3).
— AzP 30/08/2012
Aqui está um provável caso de uso, do topo:
Você fará algumas alterações, mas opa, você não está atualizado:
Portanto, você fica atualizado e tenta novamente, mas tem um conflito:
Então você decide dar uma olhada nas mudanças:
Oh meu Deus, meu Deus, a montante mudou algumas coisas, mas apenas para usar minhas alterações ... não ... as alterações deles ...
E então tentamos uma última vez
Este foi super útil, porque eu tinha um monte de erros fundir com arquivos binários (ativos de arte) e fundindo as parece sempre falhar, então eu preciso substituí-lo com o novo arquivo sempre e não "merge"
— petrocket
Cuidado! O significado de - nossos e - deles é invertido. --ours == o controle remoto. - deles == local. Vejagit merge --help
— mmell 04/03
No meu caso, confirmo que --theirs = repositório remoto, --ours = meu próprio repositório local. É o oposto dos comentários do @mmell.
— Aryo #
@mmell Apenas em uma rebase, aparentemente. Vejathis question
Gente, "nossa" e "deles" é relativa ao fato de você estar ou não se fundindo ou reestruturando. Se você estiver mesclando , então "nosso" significa o ramo no qual você está mesclando e "deles" é o ramo no qual você está mesclando. Quando você está reestruturando , então "nosso" significa os commits nos quais você está reestruturando. , enquanto "deles" refere-se às confirmações que você deseja refazer.
Acho que as ferramentas de mesclagem raramente me ajudam a entender o conflito ou a resolução. Normalmente, sou mais bem-sucedido olhando os marcadores de conflito em um editor de texto e usando o git log como um complemento.
A melhor coisa que eu encontrei é usar o estilo de conflito de mesclagem "diff3":
Isso produz marcadores de conflito como este:
A seção do meio é a aparência do ancestral comum. Isso é útil porque você pode compará-lo com as versões superior e inferior para ter uma melhor noção do que foi alterado em cada ramificação, o que lhe dá uma idéia melhor sobre qual era o objetivo de cada alteração.
Se o conflito é apenas algumas linhas, isso geralmente torna o conflito muito óbvio. (Saber como resolver um conflito é muito diferente; você precisa estar ciente do que as outras pessoas estão trabalhando. Se estiver confuso, provavelmente é melhor chamar essa pessoa para o seu quarto para que elas possam ver o que você está procurando. às.)
Se o conflito for mais longo, recortarei e colarei cada uma das três seções em três arquivos separados, como "meu", "comum" e "deles".
Em seguida, posso executar os seguintes comandos para ver os dois pedaços de diferenças que causaram o conflito:
Isso não é o mesmo que usar uma ferramenta de mesclagem, pois ela também inclui todos os blocos de diferenças não conflitantes. Acho que isso é perturbador.
Alguém já mencionou isso, mas entender a intenção por trás de cada pedaço de diferença geralmente é muito útil para entender de onde veio um conflito e como lidar com ele.
Isso mostra todos os commits que tocaram nesse arquivo entre o ancestral comum e as duas cabeças que você está mesclando. (Portanto, não inclui confirmações que já existem nos dois ramos antes da mesclagem.) Isso ajuda a ignorar as diferenças, que claramente não são um fator no seu conflito atual.
Verifique suas alterações com ferramentas automatizadas.
Se você tiver testes automatizados, execute-os. Se você tem um cotão , execute isso. Se for um projeto montável, construa-o antes de confirmar, etc. Em todos os casos, é necessário fazer alguns testes para garantir que suas alterações não quebrem nada. (Heck, mesmo uma mesclagem sem conflitos pode quebrar o código de trabalho.)
Planejar com antecedência; comunicar com colegas de trabalho.
Planejar com antecedência e estar ciente do que os outros estão trabalhando pode ajudar a evitar conflitos de mesclagem e / ou a resolvê-los mais cedo - enquanto os detalhes ainda estão em mente.
Por exemplo, se você sabe que você e outra pessoa estão trabalhando em uma refatoração diferente que afetará o mesmo conjunto de arquivos, converse com antecedência e tenha uma noção melhor dos tipos de alterações que cada um de vocês é fazer. Você pode economizar tempo e esforço consideráveis ​​se realizar as alterações planejadas em série e não em paralelo.
Para grandes refatorações que abrangem uma grande faixa de código, considere fortemente trabalhar em série: todo mundo para de trabalhar nessa área do código enquanto uma pessoa realiza a refatoração completa.
Se você não pode trabalhar em série (devido à pressão do tempo, talvez), a comunicação sobre os conflitos de mesclagem esperados pelo menos ajuda a resolver os problemas mais cedo, enquanto os detalhes ainda estão em mente. Por exemplo, se um colega de trabalho estiver realizando uma série de confirmações disruptivas ao longo de um período de uma semana, você poderá optar por mesclar / refazer esse ramo de colegas de trabalho uma ou duas vezes por dia durante essa semana. Dessa forma, se você encontrar conflitos de mesclagem / rebase, poderá resolvê-los mais rapidamente do que se esperar algumas semanas para mesclar tudo em um único bloco.
Se você não tiver certeza de uma mesclagem, não a force.
A mesclagem pode parecer esmagadora, principalmente quando há muitos arquivos conflitantes e os marcadores de conflito cobrem centenas de linhas. Muitas vezes, ao estimar projetos de software, não incluímos tempo suficiente para itens de sobrecarga, como lidar com uma mescla gnarly, portanto, é uma pena passar várias horas dissecando cada conflito.
A longo prazo, planejar com antecedência e estar ciente do que os outros estão trabalhando são as melhores ferramentas para antecipar conflitos de mesclagem e preparar-se para resolvê-los corretamente em menos tempo.
A opção diff3 é um ótimo recurso para mesclar. A única GUI que encontrei mostra que é o Perforce p4merge, que pode ser instalado e usado separadamente das outras ferramentas do Perforce (que eu não usei, mas ouvi reclamações).
Após uma tentativa de rebase que resultou em um conflito de mesclagem: $ git log --merge -p build.xml output: fatal: --merge sem MERGE_HEAD?
e se eu tiver alterações em um arquivo do branch1 e exclusão desse arquivo no branch2. Como posso resolver esse conflito de mesclagem? Existe alguma maneira de usar o git onde eu possa mesclá-los mantendo as alterações de um ramo?
git config merge.conflictstyle diff3Obrigado senhor. Isso é incrível e me liberou de tentar encontrar (e pagar $$) por uma boa GUI de mesclagem de 3 maneiras. Na IMO, isso é melhor porque mostra o ancestral comum, bem como local / remoto, e mostra as últimas linhas de log de confirmação que (AFAIK) nenhuma GUI faz. As confirmações definitivamente ajudam a identificar qual código pertence a qual ramificação.
— Ffxsam 04/04
Descobri que, às vezes, o estilo de conflito diff3 resulta em enormes pedaços diff, que são praticamente idênticos, enquanto o padrão produzirá pedaços menores e mais fáceis de gerenciar. Infelizmente, não tenho um reprodutor que possa ser usado para um relatório de erro. Mas se você encontrar esse problema, pode considerar desativar a opção temporariamente.
Identifique quais arquivos estão em conflito (o Git deve informar isso).
Abra cada arquivo e examine as diferenças; O Git os demarca. Espero que seja óbvio qual versão de cada bloco manter. Pode ser necessário discuti-lo com outros desenvolvedores que confirmaram o código.
Depois de resolver o conflito em um arquivo git add the_file.
Depois de resolver todos os conflitos, execute git rebase --continueo comando que o Git disse para executar quando concluir.
@ Justin Pense no Git como rastreando conteúdo, em vez de rastrear arquivos. Então é fácil ver que o conteúdo que você atualizou não está no repositório e precisa ser adicionado. Essa maneira de pensar também explica por que o Git não rastreia pastas vazias: embora sejam tecnicamente arquivos, não há conteúdo para rastrear.
o conteúdo está lá, o conflito ocorre porque há 2 versões do conteúdo. Portanto, "git add" não parece correto. E isso não funciona (git add, git commit) se você deseja confirmar apenas um arquivo após a resolução do conflito ("fatal: não é possível fazer um commit parcial durante uma mesclagem").
Sim, tecnicamente, isso responde à pergunta que foi feita, mas não é uma resposta útil, na minha opinião, desculpe. Qual o sentido de tornar um ramo o mesmo que outro? Claro que uma fusão terá conflitos ..
Thulfir: quem disse algo sobre tornar um ramo o mesmo que outro? Existem diferentes cenários em que você precisa mesclar, sem "tornar uma ramificação igual à outra". Uma é quando você termina um ramo de desenvolvimento e deseja incorporar suas alterações no ramo mestre; depois disso, o ramo de desenvolvimento pode ser excluído. Outra é quando você deseja refazer sua ramificação de desenvolvimento, a fim de facilitar a eventual mesclagem final no mestre.
@JustinGrant cria git addarquivos no índice; ele não acrescentar nada ao repositório. git commitadiciona coisas ao repositório. Esse uso faz sentido para mesclagens - a mesclagem automaticamente monitora todas as alterações que podem ser mescladas automaticamente; é sua responsabilidade mesclar o restante das alterações e adicioná-las ao índice quando terminar.
Confira as respostas na pergunta Stack Overflow Interrompendo uma mesclagem no Git , especialmente a resposta de Charles Bailey, que mostra como exibir as diferentes versões do arquivo com problemas, por exemplo,
Confira também a opção "-m" para "git checkout -m" - ele permite que você extrair os diferentes moscas de volta para seu espaço de trabalho
Isso me salvou. Observar cada arquivo separadamente me permitiu lembrar o que eu estava procurando em cada ramo. Então eu poderia tomar a decisão de escolher.
— Rohmer 14/05
Os conflitos de mesclagem acontecem quando são feitas alterações em um arquivo ao mesmo tempo. Aqui está como resolvê-lo.
Aqui estão etapas simples que você deve fazer quando entrar em estado de conflito:
Observe a lista de arquivos conflitantes com: git status(na Unmerged pathsseção).
Resolva os conflitos separadamente para cada arquivo, usando uma das seguintes abordagens:
Use a GUI para resolver os conflitos: git mergetool(a maneira mais fácil).
Para aceitar remoto / outra versão, use: git checkout --theirs path/file. Isso rejeitará as alterações locais que você fez para esse arquivo.
Para aceitar a versão local / nossa, use: git checkout --ours path/file
No entanto, você deve ter cuidado, pois alterações remotas que conflitos foram feitos por algum motivo.
Relacionado: Qual é o significado preciso de "nosso" e "deles" no git?
Edite os arquivos em conflito manualmente e procure o bloco de código entre <<<<</ >>>>>e escolha a versão acima ou abaixo =====. Veja: Como os conflitos são apresentados .
Os conflitos de caminho e nome de arquivo podem ser resolvidos por git add/ git rm.
Finalmente, rever os arquivos pronto para cometer usando: git status.
Se você ainda tiver quaisquer arquivos sob Unmerged paths, e você conseguiu resolver o conflito manualmente, em seguida, deixar Git saber que você resolveu por: git add path/file.
Se todos os conflitos foram resolvidos com êxito, confirme as alterações com: git commit -ae pressione para remoto como de costume.
Consulte também: Resolvendo um conflito de mesclagem na linha de comando no GitHub
Para um tutorial prático, verifique: Cenário 5 - Corrigindo conflitos de mesclagem por Katacoda .
Usei com sucesso o DiffMerge, que pode comparar e mesclar visualmente arquivos no Windows, macOS e Linux / Unix.
Ele pode mostrar graficamente as alterações entre três arquivos e permite a mesclagem automática (quando seguro) e controle total sobre a edição do arquivo resultante.
Fonte da imagem: DiffMerge (captura de tela do Linux)
Basta fazer o download e executar no repositório como:
No macOS, você pode instalar via:
E provavelmente (se não for fornecido), você precisará do seguinte invólucro extra simples colocado em seu PATH (por exemplo /usr/bin):
Em seguida, você pode usar os seguintes atalhos de teclado:
⌘- Alt- Up/ Downpara pular para as alterações anteriores / próximas.
⌘- Alt- Left/ Rightpara aceitar alterações da esquerda ou da direita
Como alternativa, você pode usar o opendiff (parte do Xcode Tools), que permite mesclar dois arquivos ou diretórios para criar um terceiro arquivo ou diretório.
Se você está fazendo pequenas confirmações frequentes, comece examinando os comentários de confirmação git log --merge. Em seguida git diff, mostrará os conflitos.
Para conflitos que envolvem mais do que algumas linhas, é mais fácil ver o que está acontecendo em uma ferramenta GUI externa. Eu gosto do opendiff - o Git também suporta vimdiff, gvimdiff, kdiff3, tkdiff, meld, xxdiff, emergir da caixa e você pode instalar outros: git config merge.tool "your.tool"você definirá a ferramenta escolhida e, git mergetoolapós uma falha na mesclagem, mostrará as diferenças no contexto.
Cada vez que você edita um arquivo para resolver um conflito, git add filenameatualiza o índice e seu diff não o mostra mais. Quando todos os conflitos forem tratados e seus arquivos tiverem sido git addeliminados, git commita fusão será concluída.
Usar "git add" é o verdadeiro truque aqui. Você pode nem querer confirmar (talvez queira ocultar), mas é necessário "git add" para concluir a mesclagem. Acho que o mergetool faz a adição para você (embora não esteja na página de manual), mas se você fizer a mesclagem manualmente, precisará usar "git add" para concluir (mesmo que não queira confirmar).
— nobar 25/10/10
Consulte Como os conflitos são apresentados ou, no Git, a git mergedocumentação para entender o que são marcadores de conflito de mesclagem.
Além disso, a seção Como resolver conflitos explica como resolver os conflitos:
Depois de ver um conflito, você pode fazer duas coisas:
Decida não mesclar. As únicas limpezas necessárias são redefinir o arquivo de índice para o HEADcommit para reverter 2. e limpar as alterações na árvore de trabalho feitas por 2. e 3 .; git merge --abortpode ser usado para isso.
Resolva os conflitos. O Git marcará os conflitos na árvore de trabalho. Edite os arquivos em forma e git addeles no índice. Use git commitpara selar o acordo.
Você pode solucionar o conflito com várias ferramentas:
Use uma ferramenta de fusão. git mergetoolpara iniciar uma ferramenta gráfica de mesclagem, que o ajudará na mesclagem.
Veja as diferenças. git diffmostrará uma comparação de três vias, destacando as alterações nas versões HEADe MERGE_HEAD.
Veja as diferenças de cada ramo. git log --merge -p <path>mostrará diffs primeiro para a HEADversão e depois a MERGE_HEADversão.
Veja os originais. git show :1:filenamemostra o ancestral comum, git show :2:filenamemostra a HEADversão e git show :3:filenamemostra a MERGE_HEADversão.
Você também pode ler sobre os marcadores de conflito de mesclagem e como resolvê-los na seção do livro do Pro Git , Conflitos básicos de mesclagem .
Desejo minha versão completa ou a versão deles ou desejo revisar alterações individuais e decidir por cada uma delas.
Aceite totalmente a minha versão ou a deles :
Aceite minha versão (local, nossa):
Aceite a versão deles (remota, deles):
Se você deseja fazer para todos os arquivos de conflito, execute:
Revise todas as alterações e aceite-as individualmente
Revise as alterações e aceite uma das versões para cada uma delas.
O padrão mergetoolfunciona na linha de comando . Como usar uma fusão de linha de comando deve ser uma pergunta separada.
Você também pode instalar uma ferramenta visual para isso, por exemplo, melde executar
Ele abrirá a versão local (nossa), a versão "base" ou "mesclada" (o resultado atual da mesclagem) e a versão remota (a deles). Salve a versão mesclada quando terminar, execute git mergetool -t meldnovamente até obter "Nenhum arquivo precisa ser mesclado " e vá para as Etapas 3. e 4.
— Nenhuma idéia
Este comando: --theirs git checkout - <filename> mudado todos os arquivos para o deles, e não apenas <filename>
Na verdade eu estava errado. Isso atualiza apenas o arquivo especificado.
Para usuários do Emacs que desejam resolver conflitos de mesclagem semi-manualmente:
mostra todos os arquivos que requerem resolução de conflitos.
Abra cada um desses arquivos, um por um, ou todos de uma vez:
Ao visitar um buffer que exige edições no Emacs, digite
Isso abrirá três buffers (o meu, o deles e o buffer de saída). Navegue pressionando 'n' (próxima região), 'p' (região de previsão). Pressione 'a' e 'b' para copiar a minha ou a região deles para o buffer de saída, respectivamente. E / ou edite o buffer de saída diretamente.
Quando terminar: Pressione 'q'. O Emacs pergunta se você deseja salvar esse buffer: sim. Depois de terminar um buffer, marque-o como resolvido executando a partir do teriminal:
Quando terminar com todos os tipos de buffers
para finalizar a mesclagem.
Ao falar sobre puxar / buscar / mesclar nas respostas acima, gostaria de compartilhar um truque interessante e produtivo,
Este comando acima é o comando mais útil na minha vida git, que economizou muito tempo.
Antes de empurrar a sua mudança recém comprometido com servidor remoto, tente git pull --rebaseem vez git pulle manual mergee ele será automaticamente sincronizado últimas alterações de servidor remoto (com uma busca + merge) e irá colocar o seu local de última cometer no topo em git log. Não precisa se preocupar com puxar / mesclar manualmente.
Em caso de conflito, basta usar
Simplesmente, se você sabe bem que as mudanças em um dos repositórios não são importantes e deseja resolver todas as mudanças em favor do outro, use:
resolver alterações a favor do seu repositório ou
resolver alterações em favor do outro ou do repositório principal .
Ou então você terá que usar uma ferramenta de mesclagem da GUI para percorrer os arquivos um por um, dizer que a ferramenta de mesclagem é p4mergeou escrever o nome de alguém que você já instalou
e depois de terminar um arquivo, você precisará salvar e fechar, para que o próximo seja aberto.
— Mohamed Selim
git checkout. --theirs resolvido meus problemas, graças
se você preferir resolver conflitos tentar manualmente abrindo a pasta no código do Visual Studio, ele marca arquivos com conflitos e cores linhas de conflito dentro de cada um
Siga as etapas a seguir para corrigir conflitos de mesclagem no Git:
Verifique o status do Git: status do git
Obtenha o patchset: git fetch (faça o checkout do patch correto no commit do Git)
Efetue checkout de uma filial local (temp1 no meu exemplo aqui): git checkout -b temp1
Puxe o conteúdo recente do master: git pull --rebase origin master
Inicie o mergetool e verifique os conflitos e corrija-os ... e verifique as alterações na ramificação remota com sua ramificação atual: git mergetool
Verifique o status novamente: status git
Exclua os arquivos indesejados criados localmente pelo mergetool, geralmente o mergetool cria um arquivo extra com a extensão * .orig. Exclua esse arquivo, pois isso é apenas a duplicata e corrija as alterações localmente e adicione a versão correta dos seus arquivos. git add #your_changed_correct_files
Confirme as alterações no mesmo ID de confirmação (isso evita um novo conjunto de patches separado): git commit --amend
Enviar para o ramo principal: git push (para o seu repositório Git)
— Chhabilal
Existem 3 etapas:
Encontre quais arquivos causam conflitos por comando
Verifique os arquivos nos quais você encontrará os conflitos marcados como
Altere para o modo que você deseja e, em seguida, confirme com comandos
— Qijun Liu
Trabalhou para mim! Obrigado!
— Nuwan Jayawardene
Você deve prestar atenção se fizer isso durante o rebase. Você deve usar git rebase --continue vez de git commit
— Samuel Dauzon
Você pode corrigir conflitos de mesclagem de várias maneiras, conforme detalhado por outras.
Eu acho que a chave real é saber como as mudanças fluem com os repositórios locais e remotos. A chave para isso é entender as ramificações de rastreamento. Descobri que penso no ramo de rastreamento como a 'peça que faltava no meio' entre mim, meu diretório local de arquivos reais e o controle remoto definido como origem.
Eu, pessoalmente, adquiri o hábito de duas coisas para ajudar a evitar isso.
O que tem duas desvantagens -
a) Todos os arquivos novos / alterados são adicionados e podem incluir algumas alterações indesejadas.
b) Você não pode revisar a lista de arquivos primeiro.
Então, eu faço:
Dessa forma, você é mais deliberado sobre quais arquivos são adicionados e também pode revisar a lista e pensar um pouco mais ao usar o editor da mensagem. Acho que também melhora minhas mensagens de confirmação quando uso um editor de tela cheia em vez da -mopção.
[Atualização - com o passar do tempo, mudei mais para:
Além disso (e mais relevante para a sua situação), tento evitar:
porque pull implica uma mesclagem e se você tiver alterações localmente que não deseja mesclar, poderá facilmente acabar com o código mesclado e / ou conflitos de mesclagem para código que não deveria ter sido mesclado.
Em vez disso, tento fazer
Você também pode achar útil:
Ei, eu meio que entendi sua resposta. Mas como eu sou novo no github, mesclar conflitos, acho que há algo faltando. O que acontece com as suas modificações locais quando você faz git checkout mastere git fetch e git rebase --hard origin/master
Eu acredito que você deve adicionar mais detalhes sobre o que fazer. Outro exemplo que está me confundindo, você mencionou na sua resposta: nós git add .salvamos nossas modificações locais para que possamos acompanhar git checkout master? ou são dois cenários diferentes?
— Suhaib 08/08/19
@MichaelDurrant $ git rebase --hard origin/master b5a30cc159ba8dd error: unknown option hard 'use: git rebase [-i] [opções] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>] ou: git rebase [-i] [ opções] [--exec <cmd>] [--onto <newbase>] --root [<branch>] ou: git rebase --continue | --abort | --skip | --edit-todo `
A resposta de CoolAJ86 resume praticamente tudo. Caso você tenha alterações nas duas ramificações no mesmo trecho de código, será necessário fazer uma mesclagem manual. Abra o arquivo em conflito em qualquer editor de texto e você verá a seguinte estrutura.
Escolha uma das alternativas ou uma combinação de ambas da maneira que você deseja que seja o novo código, enquanto remove sinais de igual e colchetes angulares.
Parece que nem sempre funciona para mim e geralmente acaba exibindo todos os commit que eram diferentes entre os dois ramos, isso acontece mesmo quando se usa -- para separar o caminho do comando.
O que faço para solucionar esse problema é abrir duas linhas de comando e em uma execução
Substituindo $MERGED_IN_BRANCHpela ramificação na qual mesclei e [path]pelo arquivo que está em conflito. Este comando registrará todas as confirmações, em forma de patch, entre ( ..) duas confirmações. Se você deixar um lado vazio, como nos comandos acima, o git usará automaticamente HEAD(o ramo no qual você está se fundindo neste caso).
Isso permitirá que você veja quais confirmações foram inseridas no arquivo nos dois ramos depois que eles divergiram. Geralmente facilita muito a solução de conflitos.
— Brian Di Palma
Usando patience
Estou surpreso que ninguém mais tenha falado sobre resolver conflitos usando patiencea estratégia recursiva de mesclagem. Para um grande conflito de mesclagem, o uso patienceforneceu bons resultados para mim. A ideia é que ele tente combinar blocos em vez de linhas individuais.
Se você alterar o recuo do seu programa, por exemplo, a estratégia padrão de mesclagem do Git às vezes combina chaves simples {que pertencem a diferentes funções. Isso é evitado com patience:
Comparação com o ancestral comum
Se você tiver um conflito de mesclagem e quiser ver o que os outros tinham em mente ao modificar sua ramificação, às vezes é mais fácil comparar sua ramificação diretamente com o ancestral comum (em vez de nossa ramificação). Para isso você pode usar merge-base:
Normalmente, você deseja apenas ver as alterações para um arquivo específico:
— Conquilicultor
No meu caso, isso não resolveu bem os conflitos de mesclagem, pois, por algum motivo, mantinha linhas duplicadas de configuração nos projetos em C #. Apesar de ter sido mais amigável do que o arquivo inteiro é diferente, o que eu tinha antes
A partir de 12 de dezembro de 2016, você pode mesclar filiais e resolver conflitos no github.com
Portanto, se você não quiser usar a linha de comando ou qualquer ferramenta de terceiros oferecida aqui a partir de respostas mais antigas , use a ferramenta nativa do GitHub.
Esta postagem do blog explica em detalhes, mas o básico é que, ao 'mesclar' duas ramificações por meio da interface do usuário, você verá uma opção 'resolver conflitos' que o levará a um editor, permitindo que você lide com esses conflitos de mesclagem.
isso não está perguntando sobre o github, portanto, votei no que considero uma resposta muito ruim.
@mschuett está certo, a questão é "como resolver conflitos no git", não "como resolver conflitos no github". Há uma diferença e já existem muitas pessoas que pensam que git e github são a mesma coisa; portanto, qualquer coisa que propague esse sentimento está errada.
Se você deseja mesclar da ramificação (teste) para o mestre, siga estas etapas:
Etapa 1 : vá para o ramo
Etapa 3 : se houver alguns conflitos, vá para esses arquivos para modificá-lo.
Etapa 4 : adicionar essas alterações
Etapa 6 : se ainda houver conflito, volte para a etapa 3 novamente. Se não houver conflito, faça o seguinte:
Etapa 7 : E então não há conflito entre teste e mestre. Você pode usar a mesclagem diretamente.
— Haimei
Eu sempre sigo as etapas abaixo para evitar conflitos.
git checkout master (Venha para a ramificação principal)
git pull (Atualize seu mestre para obter o código mais recente)
git checkout -b mybranch (efetue o checkout de um novo ramo e comece a trabalhar nesse ramo para que seu mestre permaneça sempre no topo do tronco.)
git add. AND git commit AND git push (em sua filial local após as alterações)
git checkout master (Volte para o seu mestre.)
Agora você pode fazer o mesmo e manter quantas filiais locais desejar e trabalhar simultaneamente. Basta fazer um checkout git na sua filial sempre que necessário.
Conflitos de mesclagem podem ocorrer em diferentes situações:
Ao executar "git fetch" e depois "git merge"
Ao executar "git fetch" e depois "git rebase"
Ao executar o "git pull" (que é realmente igual a uma das condições mencionadas acima)
Ao executar o "git stash pop"
Ao aplicar patches git (confirmações que são exportadas para arquivos a serem transferidos, por exemplo, por email)
Você precisa instalar uma ferramenta de mesclagem compatível com o Git para resolver os conflitos. Eu pessoalmente uso o KDiff3 e achei agradável e útil. Você pode baixar a versão do Windows aqui:
Aliás, se você instalar o Git Extensions, há uma opção no assistente de instalação para instalar o Kdiff3.
Em seguida, configure o git configs para usar o Kdiff como sua ferramenta de fusão:
(Lembre-se de substituir o caminho pelo caminho real do arquivo Kdiff exe.)
Então, toda vez que você se deparar com um conflito de mesclagem, basta executar este comando:
Em seguida, ele abre o Kdiff3 e primeiro tenta resolver os conflitos de mesclagem automaticamente. A maioria dos conflitos seria resolvida espontaneamente e você precisará corrigir o restante manualmente.
Aqui está a aparência do Kdiff3:
Depois que terminar, salve o arquivo e ele passará para o próximo arquivo com conflito e você fará a mesma coisa novamente até que todos os conflitos sejam resolvidos.
Para verificar se tudo foi mesclado com êxito, basta executar o comando mergetool novamente, você deve obter este resultado:
— akazemis
Esta resposta é adicionar uma alternativa para usuários do VIM como eu que prefere fazer tudo dentro do editor.
O Tpope criou este ótimo plugin para o VIM, chamado fugitivo . Uma vez instalado, você pode executar :Gstatuspara verificar os arquivos que possuem conflito e:Gdiff abrir o Git de uma maneira de três maneiras.
Uma vez na fusão de três maneiras, o fugitivo permitirá que você obtenha as alterações de qualquer uma das ramificações que você está mesclando da seguinte maneira:
:diffget //2, obtenha alterações do ramo original ( HEAD ):
:diffget //3, obtenha alterações do ramo mesclado:
Quando terminar de mesclar o arquivo, digite :Gwriteo buffer mesclado. O Vimcasts lançou um ótimo vídeo explicando em detalhes essas etapas.
Gitlense para código VS
Você pode experimentar o Gitlense para código VS. Eles são os principais recursos:
3. Resolva facilmente conflitos.
Eu já gosto deste recurso:
2. Responsabilidade da linha atual.
3. Culpa da sarjeta
4. Culpa da barra de status
E há muitos recursos que você pode ver aqui .
git buscar
git checkout seu ramo
Nesta etapa, você tentará corrigir o conflito usando o seu IDE preferencial
Você pode seguir este link para verificar ho para corrigir o conflito no arquivo
git rebase --continue o
git push origin HEAD: refs / drafts / master (pressione como um rascunho)
Agora tudo está bem e você encontrará seu commit em gerrit
Espero que isso ajude todos a respeito deste assunto.
— Baini.Marouane
Experimente o Visual Studio Code para editar, se você ainda não estiver. O que ele faz é depois de tentar mesclar (e aparecer em conflitos de mesclagem). O código VS automaticamente detecta os conflitos de mesclagem.
Isso pode ajudá-lo muito bem, mostrando quais são as alterações feitas na original e você deve aceitar incomingou
current change(ou seja, original antes de mesclar) '?.
Ajudou para mim e também pode funcionar para você!
PS: funcionará apenas se você tiver configurado o git com seu código e o Visual Studio Code.
— Kailash Bhalaki
Uma maneira mais segura de resolver conflitos é usar o git-mediate (as soluções comuns sugeridas aqui são bastante suscetíveis a erros).
Veja este post para uma introdução rápida sobre como usá-lo.
Para quem está usando o Visual Studio (2015 no meu caso)
Feche seu projeto no VS. Especialmente em grandes projetos, o VS tende a surtar ao mesclar usando a interface do usuário.
Faça a mesclagem no prompt de comando.
Em seguida, abra o projeto no VS e vá para Team Explorer -> Filial. Agora, há uma mensagem informando que a mesclagem está pendente e os arquivos conflitantes estão listados logo abaixo da mensagem.
Clique no arquivo em conflito e você terá a opção de Mesclar, Comparar, Obter Origem, Obter Destino. A ferramenta de mesclagem no VS é muito fácil de usar.
Estou usando o VS Code 2017 em um projeto muito grande e não precisa fechar o projeto. Ele lida com isso muito bem :)
Se você estiver usando o intelliJ como IDE, tente mesclar o pai ao seu ramo,
Ele mostrará todos os conflitos como este
A_MBPro: teste a origem da mesclagem anu $ git / mesclagem automática de src / test / java / com /.../ TestClass.java CONFLICT (conteúdo): mescla conflito em src / test / java / com /.../ TestClass.java
Agora observe que o arquivo TestClass.java é mostrado em vermelho no intelliJ. O status do git também será exibido.
Abra o arquivo no intelliJ, ele terá seções com
onde HEAD é alterado na ramificação local e origem / é alterado na ramificação remota. Mantenha aqui o que você precisa e remova o que não precisa. Depois que as etapas normais devem ser executadas. Isso é
Estou usando o Código Visual da Microsoft para resolver conflitos. É muito simples de usar. Eu mantenho meu projeto aberto no espaço de trabalho. Ele detecta e destaca conflitos, além disso, oferece opções de GUI para selecionar qualquer alteração que eu queira manter do HEAD ou de entrada.