Este guia demonstra como resolver alguns conflitos comuns através da linha de comando. Você precisará de um editor de texto para resolver alguns dos conflitos. Criando uma colisão de edição Este é o tipo de conflito mais comum. Isso acontece quando dois ramos mudaram a mesma parte do mesmo arquivo e, em seguida, esses ramos são mesclados. Por exemplo, se você fizer uma alteração em uma determinada linha de um arquivo e seu colega trabalhar em um repositório fizer uma alteração na mesma linha exata, ocorrerá um conflito de mesclagem. O Git tem dificuldade de entender qual mudança deve ser usada, por isso pede que você ajude. Quando esse tipo de conflito ocorre, o Git grava um bloco especial no arquivo que contém o conteúdo de ambas as versões onde o conflito ocorreu. Para concluir esse tipo de mesclagem, use o editor de texto para resolver o conflito e, em seguida, adicione o arquivo e confirme-o para concluir a mesclagem. Para este exemplo, suponha que você esteja trabalhando no branch-a. E fizeram algumas alterações em um arquivo chamado planets. md. Enquanto isso, seu amigo do outro lado do mundo fez uma mudança diferente na mesma linha. Se você tentar mesclar sua ramificação de amigos na sua, haverá um conflito de mesclagem. A execução do git status informa sobre o conflito: Ambos modificaram o planets. md. Quando você abre o arquivo em seu editor de texto, você verá ambas as alterações: Em branch-a. Você escreveu a palavra nove, mas seu amigo escreveu oito. O Git adiciona automaticamente marcadores de conflito às áreas afetadas. Uma área marcada por conflito começa com ltltltltltltlt e termina com gtgtgtgtgtgtgt. Estes também são conhecidos como os marcadores de conflito. Os dois blocos em conflito são divididos por um. Você tem várias opções aqui. Você pode manter suas alterações, fazer mudanças em seus amigos ou fazer uma mudança nova. Faça o que fizer, você precisa se certificar de resolver o conflito de tal forma que o arquivo faz sentido, e todos estão felizes. Neste caso, você colocará uma nova versão inteira da linha que reflete o que aconteceu. O objetivo é fazer com que o arquivo fique exatamente como você deseja. Você vai apagar os marcadores de conflito, e digite apenas uma nova mudança: Isso é que você pode agora git adicionar este arquivo, confirmar a mudança com uma nova mensagem de commit, e estar no seu caminho. Resolvendo um conflito de arquivos removido Os conflitos de arquivos removidos ocorrem quando uma pessoa edita um arquivo e outra pessoa deleta esse arquivo em seu ramo. O Git não sabe se você deseja manter o arquivo com as novas edições, ou excluir o arquivo e esquecer essas edições. Este exemplo mostrará como resolver isso em ambos os sentidos. Mantendo o arquivo editado Primeiro, você resolverá o conflito mantendo as novas alterações. Suponha que você adicionou uma linha ao seu README. md no branch-b. Mas outra pessoa apagou o arquivo inteiramente no branch-c. O Git declara o seguinte conflito: Você pode resolver isso adicionando o arquivo de volta, e confirmando-o mais uma vez: Resolvendo removendo o arquivo Agora, você resolverá o conflito o oposto: deixando o arquivo excluído. Novamente, com um conflito de mesclagem, o Git declara: Agora, você quer remover o arquivo, então faça isso com o comando git rm: Parece bom, então confie com a mensagem padrão: Estou usando o Git no Windows (msysgit) para rastrear Mudanças para algum trabalho de projeto que eu tenho feito. Hoje eu tenho trabalhado em um PC diferente (com remoto repo brian) e Im agora tentando mesclar as edições feitas hoje de volta em minha versão local regular no meu laptop. No meu laptop, Ive usado git puxar brian mestre para puxar as alterações em minha versão local. Tudo estava bem além do documento principal do InDesign - isso mostra como um conflito. A versão no PC (brian) é a mais recente que eu quero manter, mas eu não sei o que comandos diz o repo para usar este. Eu tentei copiar diretamente o arquivo em meu laptop, mas isso parece quebrar todo o processo de mesclagem. Alguém pode me apontar na direção certa Zitrax Você fez o arquivo diff depois de executar git checkout - horas. A página do manual sugere (IMHO) que o checkout --ours / - deles irá remover a alteração do quotboth modificado, necessidade mergequot lista e adicioná-lo ao índice, e eu acho que não está correto. Eu acredito que você precisará executar git add após o checkout. Ndash Tim Keating May 13 13 at 21:06 Você também pode superar esse problema com o que faz com que git para criar cópias locais do binário em conflito e spawn seu editor padrão sobre eles: Obviamente, você não pode editar arquivos úteis binários em um editor de texto. Em vez disso, copie o novo arquivo. REMOTE sem fechar o editor. Então, quando você fechar o editor, o git verá que a cópia de trabalho não decorada foi alterada e seu conflito de mesclagem é resolvido da maneira usual. Se os arquivos são grandes ou você não deseja arriscar abrir um binário em um editor de texto, você pode pressionar ctrlc no prompt de mergetool (quot Hit retornar para iniciar a ferramenta de resolução de mesclagem quot) e git deixará os arquivos extras no lugar. Em seguida, você pode modificá-los ou mesclá-los em uma ferramenta externa (útil para formatos de documento binário como LibreOffice / OpenOffice / MSWord) e salve o resultado de volta para o nome do arquivo original. Para informar ao git que o conflito foi resolvido, git adiciona o nome do arquivo original e você pode concluir o commit de mesclagem. Ndash Felix Aug 24 15 at 21:54 Para resolver mantendo a versão em seu ramo atual (ignore a versão do ramo que você está mesclando), basta adicionar e confirmar o arquivo: Para resolver, substituindo a versão em seu ramo atual com A versão do ramo que você está fundindo em, você precisa recuperar essa versão em seu diretório de trabalho primeiro e, em seguida, adicioná-lo / commit it: Ive vêm através de duas estratégias para gerenciar diff / mesclar arquivos binários com o Git no Windows. O Tortoise git permite configurar as ferramentas diff / merge para diferentes tipos de arquivos com base nas suas extensões de arquivo. Ver 2.35.4.3. Diff / Merge Configurações Avançadas tortoisegit. org/docs/tortoisegit/tgit-dug-settings. Esta estratégia é claro relys sobre adequado diff / merge ferramentas estar disponível. Usando git atributos você pode especificar uma ferramenta / comando para converter o seu arquivo binário para o texto e, em seguida, deixar o seu padrão diff / merge ferramenta fazer a sua coisa. Consulte git-scm / book / it / v2 / Customizing-Git-Git-Attributes. O artigo até dá um exemplo de usar metadados para imagens diff. Eu tenho duas estratégias para trabalhar com arquivos binários de modelos de software, mas fomos com tartaruga git como a configuração foi fácil. Resposta Se o binário é algo mais do que um dll ou algo que pode ser editado diretamente como uma imagem, ou um arquivo de mistura (e você não precisa de lixo / selecionar um arquivo ou outro) uma verdadeira fusão Seria alguns como: Eu sugiro pesquisar uma ferramenta diff orientada para o que você está arquivo binário, por exemplo, existem alguns livres para arquivos de imagem, por exemplo, e compará-los. Se não houver nenhuma ferramenta de comparação para comparar os seus arquivos, então se você tiver o gerador original do arquivo bin (ou seja, existe um editor para ele, como o blender 3d, então você pode inspecionar esses arquivos manualmente, Logs, e pergunte a outra pessoa o que você deve incluir) e fazer uma saída dos arquivos com git-scm / book / es / v2 / Git-Tools-Advanced-Mergingmanualremerge git show: 1: hello. blend gt hellomon. blend git Mostra: 2: hello. blend gt hello. ours. blend git show: hello. blend gt hello. theirs. blend respondeu 13 de agosto às 15:03 Sua resposta 2016 Stack Exchange, IncDESCRIPTION Lê a saída diff fornecida (ou seja, um Patch) e aplica-o aos arquivos. Ao executar a partir de um subdiretório em um repositório, os caminhos corrigidos fora do diretório são ignorados. Com a opção --index, o patch também é aplicado ao índice e com a opção --cached o patch só é aplicado ao índice. Sem essas opções, o comando aplica o patch somente aos arquivos e não exige que eles estejam em um repositório do Git. Este comando aplica o patch mas não cria um commit. Use git-am1 para criar compromissos de patches gerados pelo git-format-patch1 e / ou recebidos por e-mail. OPÇÕES Os arquivos para ler o patch de. - pode ser usado para ler a partir da entrada padrão. Em vez de aplicar o patch, diffstat de saída para a entrada. Desliga se aplica. Semelhante ao --stat. Mas mostra o número de linhas adicionadas e excluídas na notação decimal eo nome do caminho sem abreviação, para torná-lo mais amigável da máquina. Para arquivos binários, saídas dois - em vez de dizer 0 0. Turns off apply. Em vez de aplicar o patch, a saída um sumário condensado de informações obtidas de git dif estendida cabeçalhos, tais como criações, renomeia e mudanças de modo. Desliga se aplica. Em vez de aplicar o patch, verifique se o patch é aplicável à árvore de trabalho atual e / ou ao arquivo de índice e detecta erros. Desliga se aplica. Quando --check estiver em vigor, ou ao aplicar o patch (que é o padrão quando nenhuma das opções que o desativar estiver em vigor), verifique se o patch é aplicável ao que o arquivo de índice atual grava. Se o arquivo a ser corrigido na árvore de trabalho não estiver atualizado, ele será sinalizado como um erro. Este sinalizador também faz com que o arquivo de índice seja atualizado. Aplique um patch sem tocar na árvore de trabalho. Em vez disso, tome os dados em cache, aplique o patch e armazene o resultado no índice sem usar a árvore de trabalho. Isso implica --index. Quando o patch não se aplica de forma limpa, recorra a 3-way merge se o patch registar a identidade de blobs é suposto aplicar, e temos esses blobs disponíveis localmente, possivelmente deixando os marcadores de conflito nos arquivos na árvore de trabalho Para o usuário resolver. Esta opção implica a opção --index e é incompatível com as opções --reject e --cached. A saída git diff mais nova tem informações de índice incorporadas para cada blob para ajudar a identificar a versão original à qual o patch se aplica. Quando esse sinalizador é dado, e se as versões originais dos blobs estiverem disponíveis localmente, constrói um índice temporário contendo esses blobs. Quando uma alteração de modo puro é encontrada (que não tem nenhuma informação de índice), as informações são lidas a partir do índice atual em vez disso. Aplique o patch no verso. Para atomicity, git aplicar por padrão falhar o patch inteiro e não tocar a árvore de trabalho quando alguns dos hunks não se aplicam. Essa opção faz com que ele aplique as partes do patch que são aplicáveis e deixe os hunks rejeitados em arquivos. rej correspondentes. Quando --numstat foi dado, não munge pathnames, mas usar um formato NUL-terminated máquina legível. Sem essa opção, cada saída de caminho terá TAB, LF, aspas duplas e caracteres de barra invertida substituídos por t. N. . E. Respectivamente, eo nome do caminho será colocado entre aspas se qualquer uma dessas substituições ocorreu. Remova ltngt principais barras de caminhos de dif tradicionais. O padrão é 1. Certifique-se de pelo menos ltngt linhas de contexto circundante correspondem antes e depois de cada alteração. Quando existem menos linhas do contexto circundante, todas elas têm de corresponder. Por padrão, nenhum contexto é ignorado. Por padrão, git apply espera que o patch sendo aplicado seja um diff unificado com pelo menos uma linha de contexto. Isso fornece boas medidas de segurança, mas quebra ao aplicar um diff gerado com --unified0. Para ignorar essas verificações use --unidiff-zero. Observe, pelas razões indicadas acima, o uso de patches livres de contexto é desencorajado. Se você usar qualquer uma das opções marcadas Desativa a opção acima, git aplica lê e exibe as informações solicitadas sem realmente aplicar o patch. Dê essa bandeira depois dessas bandeiras para também aplicar o patch. Ao aplicar um patch, ignore as adições feitas pelo patch. Isso pode ser usado para extrair a parte comum entre dois arquivos pela primeira execução diff neles e aplicar o resultado com esta opção, que aplicaria a parte de exclusão, mas não a parte de adição. Historicamente, não permitimos o patch binário aplicado sem uma permissão explícita do usuário, e este sinalizador foi a maneira de fazê-lo. Atualmente, sempre permitir aplicação de patch binário, por isso este é um não-op. Don8217t aplicar alterações aos arquivos correspondentes ao padrão de caminho fornecido. Isso pode ser útil ao importar patchsets, onde você deseja excluir determinados arquivos ou diretórios. Aplique alterações em arquivos correspondentes ao padrão de caminho fornecido. Isso pode ser útil ao importar patchsets, onde você deseja incluir determinados arquivos ou diretórios. Quando --exclude e --include padrões são usados, eles são examinados na ordem em que aparecem na linha de comando, ea primeira correspondência determina se um patch para cada caminho é usado. Um patch para um caminho que não corresponde a qualquer padrão de inclusão / exclusão é usado por padrão se não houver nenhum padrão de inclusão na linha de comando e ignorado se houver qualquer padrão de inclusão. Ao aplicar um patch, ignore as alterações no espaço em branco em linhas de contexto, se necessário. As linhas de contexto preservarão seus espaços em branco e não serão submetidas a fixação de espaço em branco, independentemente do valor da opção --whitespace. No entanto, novas linhas ainda serão corrigidas. Ao aplicar um patch, detecte uma linha nova ou modificada que tenha erros de espaço em branco. O que são considerados erros de espaço em branco é controlado pela configuração core. whitespace. Por padrão, espaços em branco (incluindo linhas que consistem exclusivamente de espaços em branco) e um caractere de espaço imediatamente seguido por um caractere de tabulação dentro do recuo inicial da linha são considerados erros de espaço em branco. Por padrão, o comando exibe mensagens de aviso, mas aplica o patch. Quando git-apply é usado para estatísticas e não aplicar um patch, o padrão é nowarn. Você pode usar diferentes valores ltactiongt para controlar esse comportamento: nowarn desativa o aviso de espaço em branco à direita. Adverte avisos de saída para alguns desses erros, mas aplica o patch como está (padrão). Corrigir saídas avisos para alguns desses erros, e aplica o patch depois de corrigi-los (strip é um sinônimo --- a ferramenta usada para considerar apenas trailing whitespace caracteres como erros, ea correção envolveu stripping-los, mas Gits modernos fazer mais). O erro emite avisos para alguns desses erros e se recusa a aplicar o patch. Error-all é semelhante ao erro, mas mostra todos os erros. Em determinadas circunstâncias, algumas versões de diff não detectam corretamente uma nova linha ausente no final do arquivo. Como resultado, os patches criados por esses programas diff não registram linhas incompletas corretamente. Essa opção adiciona suporte para aplicar esses patches trabalhando em torno desse bug. Reportar progresso para stderr. Por padrão, apenas uma mensagem sobre o patch atual sendo aplicado será impressa. Esta opção fará com que informações adicionais sejam relatadas. Não confie nas contagens de linha nos cabeçalhos hunk, mas inferi-los inspecionando o patch (por exemplo, depois de editar o patch sem ajustar os cabeçalhos hunk adequadamente). Prepend ltrootgt para todos os nomes de arquivos. Se um argumento - p também foi passado, ele é aplicado antes de prepending a nova raiz. Por exemplo, um patch que fala sobre a atualização de um / git-gui. sh para b / git-gui. sh pode ser aplicado ao arquivo nos módulos de árvore de trabalho / git-gui / git-gui. sh executando git apply - - directorymodules / git-gui. Por padrão, um patch que afeta fora da área de trabalho (uma árvore de trabalho controlada pelo Git ou o diretório de trabalho atual quando o git apply é usado como uma substituição do patch GNU) é rejeitado como um erro (ou um mal). Quando git apply é usado como um melhor patch GNU, o usuário pode passar a opção --unsafe-paths para substituir esta verificação de segurança. Esta opção não tem efeito quando --index ou --cached está em uso. Configuração Defina para alterar se você quiser que as alterações nos espaços em branco sejam ignoradas por padrão. Definido como um dos: não, nenhum, nunca, falso se você quiser que as mudanças no espaço em branco sejam significativas. Quando nenhum sinalizador --whitespace é fornecido a partir da linha de comando, esse item de configuração é usado como o padrão. Submodules Se o patch contém quaisquer alterações aos submódulos, então git apply trata essas mudanças da seguinte maneira. Se --index for especificado (explicitamente ou implicitamente), então o submódulo compromete deve corresponder ao índice exatamente para o patch a ser aplicado. Se qualquer um dos submódulos é check-out, em seguida, estes check-outs são completamente ignorados, ou seja, eles não são obrigados a ser up-to-date ou limpo e eles não são atualizados. Se --index não for especificado, então o submódulo confirma no patch são ignorados e somente a ausência ou presença do subdiretório correspondente é verificada e (se possível) atualizada. VEJA TAMBÉM Como você resolve um conflito de mesclagem para arquivos binários (por exemplo, duas versões de um. png) 45 pconrad Esta é uma grande questão para a qual eu deveria começar com alguns pontos. Git não mergulha nas mudanças de arquivos binários de forma diferente de outros sistemas de controle de versão O Git pode lançar uma ferramenta de dif que compreende imagens (git difftool e git mergetool) O usuário ainda tem pouca probabilidade de ser capaz de mesclar as mudanças díspares como binário Formatos como PNGs apenas arent bem concebido para isso. Eu usei Araxis Merge para dif algumas imagens com sucesso modesto. GitHub Training Team membro Gostaria apenas de acrescentar que se você estiver em um conflito de mesclagem de um binário, ou mesmo um documento de texto para esse assunto, você pode resolver rapidamente e checkout a cópia desejada correta usando essas opções durante a resolução: git checkout --our ltbinaryfilegt git checkout --thet ltbinaryfilegtComo resolver um conflito de arquivos binários com o Git Ao executar uma mesclagem no git. Você pode ver a mensagem: Neste cenário, somefile. dll é um arquivo binário que foi modificado no ramo atual ea ramificação que você está tentando mesclar para o ramo atual. Como o arquivo não pode ser mesclado textualmente, você precisa tomar uma decisão: você mantém a versão do arquivo em seu ramo atual ou a versão no outro ramo. No TortoiseSVN, eu estava acostumado a poder clicar com o botão direito do mouse no arquivo em questão e escolher Resolver usando o meu ou Resolver usando o deles. Então o que é o git equivalente Resolve using mine O arquivo em sua cópia de trabalho ainda é a cópia de seu ramo atual em outras palavras, ele não foi modificado pela tentativa de mesclagem. Para resolver o conflito e manter este arquivo: Resolve using theirs Se você preferir resolver o conflito usando sua cópia, você precisa obter a versão do arquivo da filial que você estava tentando mesclar: Agora que você tem a versão correta do O arquivo em sua cópia de trabalho, você pode marcá-lo como resolvido (adicionando-o), e confirmar: Note que no lugar de otherbranch. Você pode usar qualquer nome (treeish) que se refira a um ramo: um nome de ramo local (otherbranch), um nome de ramo remoto (origem / mestre), um commit SHA específico (980e3cc), etc Por exemplo, se você estava mesclando A partir de seu controle remoto quando você recebeu o conflito, e você queria resolver usando a versão remota, você recuperaria essa cópia do arquivo usando: Você adiciona o arquivo e commit como descrito acima. UPDATE. Há um atalho para obter a cópia do outro ramo (e ele mesmo usa a terminologia que eu estava esperando): Esta entrada foi postada no git. Marcar como favorito o link permanente. Siga os comentários aqui com o feed RSS para esta postagem.
No comments:
Post a Comment