Por que o git não reconhece que meu arquivo foi alterado, portanto o git add não está funcionando

Estou tentando enviar meus arquivos para o github usando o bash. Eles já estão lá, e estou enviando uma versão mais recente com novas linhas e código, etc. Mas quando tento git adde então git statusele diz:

No mestre de filial

nada para confirmar, diretório de trabalho limpo

E o arquivo que estou usando acaba de ser modificado.

Eu tive um problema onde uma vez eu configurei o índice git para 'assumir inalterado' no meu arquivo.

Você pode dizer ao git para parar de ignorar as alterações no arquivo com:

git update-index --no-assume-unchanged path/to/file

Se isso não ajudar, um reset pode ser suficiente para outros casos estranhos.

Na prática, descobri remover o arquivo em cache e redefini-lo para funcionar:

git rm --cached path/to/file
git reset path/to/file

O git rm --cachedmeio apenas de remover o arquivo do índice e resetdiz ao git para recarregar o índice git do último commit.

Verifique seu .gitignorearquivo . Você pode descobrir que o arquivo, ou extensão do arquivo, ou caminho para o arquivo com o qual está tentando trabalhar corresponde a uma entrada .gitignore, o que explicaria por que esse arquivo está sendo ignorado (e não reconhecido como um arquivo alterado).

Este acabou sendo o meu caso quando tive um problema semelhante.

Como já foi discutido, os arquivos provavelmente foram marcados com "assume-unchanged", o que basicamente diz ao git que você não modificará os arquivos, então ele não precisa rastrear as alterações com eles. No entanto, isso pode estar afetando vários arquivos e, se for um grande espaço de trabalho, você pode não querer verificar todos eles um por um. Nesse caso, você pode tentar: git update-index --really-refresh

de acordo com os docs:

Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.

Basicamente, ele forçará o git a rastrear as alterações de todos os arquivos, independentemente dos sinalizadores "assume-unchanged".

bem, não temos o suficiente para responder a essa pergunta, então vou dar vários palpites:

1) você escondeu suas alterações, para corrigir o tipo: git stash pop

2) você teve mudanças e as comprometeu, você deve ser capaz de ver o seu commit em git log

3) você teve alterações de algum tipo git reset --hardou outro, suas alterações podem estar lá no reflog, digitegit reflog --all seguido por check-out ou escolhendo o ref se algum dia o encontrar.

4) você verificou o mesmo repositório várias vezes e está no errado.

Parece loucura, mas às vezes você não está no repositório certo, embora pense que está. Por exemplo, você pode ter movido o diretório pai, mas se esqueceu de alternar os repositórios em seu editor de texto. Ou vice-versa: você está no repositório certo no editor de texto, mas no repositório errado na linha de comando. Na primeira situação, você faz suas edições no arquivo certo, mas não é a mesma pasta que está aberta na linha de comando, portanto, é o arquivo errado. Na segunda situação, você realmente editou o arquivo certo, mas seu git de linha de comando não reconhecerá a mudança porque você não está no diretório correto na linha de comando.

Tive uma coisa estranha como essa acontecendo. O plugin git do Eclipse Kepler estava marcando automaticamente todas as minhas pastas de projeto como ignoradas na pasta .gitignore.

Quando eu chegava commitno Teammenu, todos eles voltavam a ser ignorados. Pelo que eu posso dizer, isso aconteceu porque eu os defini como derivados no projeto pai. Desmarcá-los como derviedconsertou isso. Eu nunca tinha visto isso antes no Indigo. Espero que ajude alguém.

Já vimos isso acontecer no Windows ao alterar arquivos, transferindo diferenças por meio da ferramenta WinMerge. Aparentemente, o WinMerge (pelo menos a forma como está configurado no meu computador) às vezes não atualiza os carimbos de data / hora dos arquivos que muda.

No Windows, o git status usa, entre outras coisas, o registro de data e hora de um arquivo e mudanças no tamanho do arquivo para determinar se um arquivo foi alterado ou não. Portanto, como o registro de data e hora não foi atualizado, ele teve apenas o tamanho do arquivo para seguir. Infelizmente, o arquivo em questão era um arquivo de versão simples em que o conteúdo mudou de 7.1.2 para 7.2.0 . Em outras palavras, o tamanho do arquivo também permaneceu inalterado. Outros arquivos que também foram alterados pelo WinMerge e não tiveram seus timestamps atualizados, mas tiveram um tamanho diferente após a mudança, foram detectados pelo git status perfeitamente.

Tive um problema semelhante ao usar o Sublime Text-3 . Depois de fazer novas alterações no código e salvá-lo, quando tentei os comandos git add ./status, a resposta foi "branch já atualizado". Eu descobri que, independentemente de salvar as atualizações no editor de texto, o arquivo estava realmente inalterado. Abrir o arquivo em outro editor e salvar as alterações funcionou para mim.

TL; DR; Você está no repositório correto?

Minha história é um pouco engraçada, mas achei que pode acontecer com alguém que pode estar passando por um cenário semelhante, então compartilhando isso aqui.

Na verdade, na minha máquina, eu tinha dois repositórios git separados repo1e repo2configurados no mesmo diretório raiz chamado source. Esses dois repositórios são essencialmente os repositórios de dois produtos com os quais trabalho intermitentemente na minha empresa. Agora a questão é que, como diretriz padrão, a estrutura de diretório do código-fonte de todos os produtos é exatamente a mesma na minha empresa.

Portanto, sem perceber, modifiquei exatamente o mesmo arquivo com o mesmo nome no repo2qual deveria mudar repo1. Então, eu continuei comando em execução git statusno repo1e continuou dando a mesma mensagem

No mestre de filial

nada para confirmar, diretório de trabalho limpo

por meia hora. Então, um colega meu observou-o como um par de olhos independente e me chamou a atenção para o fato de que eu estava no repositório errado, mas de aparência muito semelhante. No momento em que mudei pararepo1 Git comecei a notar os arquivos alterados.

Não é um caso tão comum. Mas você nunca sabe!

Você removeu o diretório do shell? Isso pode acontecer se você restaurou seu projeto de um backup. Para corrigir isso, basta cdentrar e sair:

cd ../
cd -

Em geral, com esse problema, primeiro verifique se você está editando o arquivo que pensa que está! Tive esse problema quando estava editando um arquivo JavaScript transpilado em vez do arquivo de origem (a versão transpilada não estava sob controle de origem).

Meu cliente Git (Gitg) causou esse problema para mim. Os comandos normais que normalmente executaria não funcionavam. Nem mesmo tocar em todos os arquivos do projeto funcionou.

Eu encontrei uma maneira de consertar e ainda não tenho certeza do que causou isso. Copie o diretório do seu projeto. Os arquivos ausentes aparecerão no diretório copiado git status. Renomear pode fazer a mesma coisa.

Encontrei o problema, mas eram apenas dois diretórios e o que eu não sabia é que ambos acabaram sendo configurados como submódulos git. Não tenho ideia de como isso aconteceu, mas o processo foi seguir algumas das instruções neste link, mas NÃO remover o diretório (como ele faz no final), mas sim fazergit add path/to/dir

Quando você edita um arquivo no Visual Studio, ele é listado no git muda instantaneamente, mesmo se o arquivo não for salvo. Portanto, tudo o que você precisa fazer é salvar o arquivo manualmente (Ctrl + S para o arquivo exibido atualmente ou Ctrl + Shift + S para todos os arquivos de projeto) e git bash irá selecioná-los.

Que tipo de arquivo você tentou enviar? Agora eu gastei quase uma hora para fazer o upload da minha modificação de css. Mas este css compilado de um arquivo de estilo, portanto, o git simplesmente o ignorou. Quando mudei a fonte do estilo, tudo funcionou.

Espero que ajude.

Às vezes dependem e pela versão git e se você esquecer de fazer git add ..

Para verificar a sua mudança no repositório, use sempre git statusque mostra todos os arquivos não rastreados e alterados. Porque git diffmostra apenas os arquivos adicionados.

Certifique-se de não criar links simbólicos ( ln -s source dest) de dentro do Git Bash para Windows.

NÃO cria links simbólicos, mas faz uma cópia PROFUNDA da fonte para o destino

Eu experimentei o mesmo comportamento de OP em um terminal MINGW64 do Git Bash para Windows (versão 2.16.2) para perceber que minhas alterações 'editadas' na verdade estavam no diretório original e meus comandos git bash estavam em uma cópia profunda que havia permanecido inalterado.

Eu tive o mesmo problema. Acontece que eu tinha duas cópias do projeto e meu terminal estava na pasta de projeto errada!

Aconteceu comigo também, tentei os métodos acima mencionados e nada adiantou. Então, a solução foi mudar o arquivo via terminal, não GUI. Não sei por que isso funcionou, mas funcionou. Depois que editei o arquivo via nano do terminal, git reconheceu-o como alterado e fui capaz de adicioná-lo e fazer commit.

Eu tenho o mesmo problema aqui VS2015 não reconheceu minhas alterações de arquivos js, remover remotos das configurações do repositório e, em seguida, adicionar novamente o caminho de URL remoto resolveu meu problema.

Eu tive um problema semelhante quando criei um arquivo de patch no servidor com o editor vi. Parece que o problema era com espaçamento. Quando eu empurrei o patch do local, a implantação foi adequada.

Eu tive esse problema. O meu não estava funcionando porque eu estava colocando meus arquivos na pasta .git dentro do meu projeto.

No meu caso, git reset --hardexcluí arquivos e deixei algumas pastas vazias. Depois de inspecionar o conteúdo, percebi que os diretórios estavam vazios.

No entanto, git ignora pastas vazias. (Correção, git ignora todos os diretórios enquanto rastreia o conteúdo, pastas vazias não têm conteúdo.)

tente usar git add * entãogit commit