Próbuję przesłać moje pliki na github za pomocą basha. Są już tam, a ja przesyłając nowszą wersję z nowych linii i kodu itp Ale gdy próbuję git addi wtedy git statusmówi:
Na gałęzi master
nic do zatwierdzenia, katalog roboczy czysty
A plik, którego używam, został właśnie zmodyfikowany.
git diff(lub git status) nie pokazuje niczego, co wyjaśnia, dlaczego nie ma nic do dodania. Tak więc pytanie naprawdę brzmi: „Dlaczego git nie rozpoznaje, że mój plik został zmieniony?”
Odpowiedzi:
Miałem problem, gdy kiedyś ustawiłem indeks git na „zakładaj niezmieniony” w moim pliku.
Możesz powiedzieć gitowi, aby przestał ignorować zmiany w pliku za pomocą:
git update-index --no-assume-unchanged path/to/file
Jeśli to nie pomoże, reset może wystarczyć w innych dziwnych przypadkach.
W praktyce znalazłem usunięcie pliku z pamięci podręcznej i przywrócenie go do pracy:
git rm --cached path/to/file
git reset path/to/file
Te git rm --cachedśrodki do tylko usunąć plik z indeksem i resetmówi git przeładować indeksu git od ostatniego zatwierdzenia.
git add -f path/to/the/filewymusi dodanie plików do zatwierdzenia.
git add -fplik, który był w tym stanie „zakładaj niezmieniony” i nie zadziałał - musiałem albo git update-indexalbo git rm --cachedpo nim następować a, git resetaby działał.
git rm --cached -r .a następnie git reset ..
git update-index --no-skip-worktree path/to/filew ten sposób rozwiązałem mój problem
Sprawdź swój .gitignoreplik . Może się okazać, że plik, rozszerzenie pliku lub ścieżka do pliku, z którym próbujesz pracować, są zgodne z wpisem .gitignore, co wyjaśniałoby, dlaczego plik ten jest ignorowany (i nie jest rozpoznawany jako zmieniony).
Okazało się, że tak było w moim przypadku, gdy miałem podobny problem.
lib/tym, co sprawia, że git ignoruje ten folder. Nie ma z tym problemu - przynajmniej jeśli ten folder nie jest głównym folderem twojego projektu, tak jak to, co mi się przydarzyło.
Tak jak zostało to już omówione, pliki były prawdopodobnie oznaczone jako „zakładaj-niezmienione”, co po prostu mówi gitowi, że nie będziesz modyfikować plików, więc nie musi śledzić za ich pomocą zmian. Może to jednak mieć wpływ na wiele plików, a jeśli jest to duży obszar roboczy, możesz nie chcieć sprawdzać ich wszystkich jeden po drugim. W takim przypadku możesz spróbować: git update-index --really-refresh
według dokumentów:
Like --refresh, but checks stat information unconditionally, without regard to the "assume unchanged" setting.
Po prostu zmusi git do śledzenia zmian we wszystkich plikach, niezależnie od flag "zakładaj-niezmienione".
git statusmówi , że żadne pliki nie są zmieniane, ale git add .dodaje dwa pliki i git update-index --really-refreshmówi , że te dwa wymagają aktualizacji, ale wydaje się, że nic nie robią. Dowolny pomysł?
git ls-files -v | grep '^[[:lower:]]'Jeśli nic nie pomaga, utwórz pytanie ze szczegółami, abyśmy mogli pomóc ty.
Brzmi szalenie, ale czasami nie jesteś w odpowiednim repozytorium, mimo że myślisz, że tak jest. Na przykład mogłeś przenieść katalog nadrzędny, ale zapomniałeś zmienić repozytorium w edytorze tekstu. Lub odwrotnie: jesteś we właściwym repozytorium w edytorze tekstu, ale niewłaściwym repozytorium w wierszu poleceń. W pierwszej sytuacji edytujesz we właściwym pliku, ale nie jest to ten sam folder, który jest otwarty w linii poleceń, więc w rzeczywistości jest to niewłaściwy plik. W drugiej sytuacji faktycznie wyedytowałeś właściwy plik, ale git z linii poleceń nie rozpozna zmiany, ponieważ nie znajdujesz się we właściwym katalogu w linii poleceń.
cóż, nie mamy wystarczająco dużo, aby odpowiedzieć na to pytanie, więc dam kilka domysłów:
1) zachowałeś swoje zmiany, aby naprawić typ: git stash pop
2) miałeś zmiany i je wprowadziłeś, powinieneś być w stanie zobaczyć swoje zatwierdzenie git log
3) dokonałeś jakichś zmian git reset --hard, twoje zmiany mogą być tam w reflogu, typie, git reflog --allpo którym następuje sprawdzenie lub wybranie najlepszego refu, jeśli kiedykolwiek go znajdziesz.
4) kilkakrotnie sprawdzałeś to samo repozytorium i jesteś w złym.
git commit --amendwprowadzić nowe zmiany w ostatnim zatwierdzeniu , nie rób tego, jeśli już podzieliłeś się swoim zatwierdzeniem.
Działo się coś takiego jak ta. Wtyczka Eclipse Kepler do git automatycznie oznaczała wszystkie foldery moich projektów jako ignorowane w folderze .gitignore.
Kiedy dostałem się commitna Teammenu, to oni wszyscy zestaw z powrotem do ignorowane. O ile wiem, było to spowodowane tym, że ustawiłem je jako pochodne w projekcie nadrzędnym. Odznaczenie ich jako derviednaprawiło ten problem. Nigdy wcześniej tego nie widziałem na Indigo. Mam nadzieję, że to komuś pomoże.
TL; DR; Czy jesteś w ogóle we właściwym repozytorium?
Moja historia jest trochę zabawna, ale pomyślałem, że może się to zdarzyć z kimś, kto może mieć podobny scenariusz, więc udostępnij go tutaj.
Właściwie na moim komputerze miałem dwa oddzielne repozytoria git repo1i repo2skonfigurowane w tym samym katalogu głównym o nazwie source. Te dwa repozytoria są zasadniczo repozytoriami dwóch produktów, które pracuję i pracuję w mojej firmie. Chodzi o to, że zgodnie ze standardową wytyczną struktura katalogów kodu źródłowego wszystkich produktów jest dokładnie taka sama w mojej firmie.
Więc nie zdając sobie sprawy, zmodyfikowałem dokładnie ten sam plik, w repo2którym miałem się zmienić repo1. Tak, ja po prostu przechowywane polecenie działa git statusna repo1i przechowywane dając ten sam komunikat
Na gałęzi master
nic do zatwierdzenia, katalog roboczy czysty
przez pół godziny. Potem mój kolega zauważył to jako niezależną parę oczu i zwrócił mi uwagę, że jestem w złym, ale bardzo podobnie wyglądającym repozytorium. W momencie, gdy przełączyłem się na repo1Gita, zacząłem zauważać zmienione pliki.
Niezbyt częsty przypadek. Ale nigdy nie wiesz!
Zdarzało się to w systemie Windows podczas zmiany plików przez przesyłanie różnic za pomocą narzędzia WinMerge. Najwyraźniej WinMerge (przynajmniej tak, jak jest skonfigurowany na moim komputerze) czasami nie aktualizuje sygnatur czasowych plików, które zmienia.
W systemie Windows stan git wykorzystuje między innymi znacznik czasu pliku i zmiany rozmiaru pliku w celu określenia, czy plik uległ zmianie. Więc ponieważ znacznik czasu nie był aktualizowany, miał tylko rozmiar pliku. Niestety, ten plik był prostą wersją pliku, w której zawartość zmieniła się z 7.1.2 na 7.2.0 . Innymi słowy, rozmiar pliku również pozostał niezmieniony. Inne pliki, które również zostały zmienione przez WinMerge i nie miały zaktualizowanych znaczników czasu, ale miały inny rozmiar po zmianie, zostały wykryte przez status git .
Miałem podobny problem podczas korzystania z Sublime Text-3 . Po wprowadzeniu nowych zmian w kodzie i zapisaniu go, gdy wypróbowałem polecenia git add ./status, odpowiedź brzmiała: „gałąź już aktualna”. Doszedłem do wniosku, że niezależnie od zapisywania aktualizacji w edytorze tekstu, plik był właściwie niezmieniony. Otwarcie pliku w innym edytorze i zapisanie zmian zadziałało dla mnie.
Czy przeniosłeś katalog spod powłoki? Może się tak zdarzyć, jeśli przywróciłeś projekt z kopii zapasowej. Aby to naprawić, po prostu cdwyjdź i z powrotem:
cd ../
cd -
Ogólnie w przypadku tego problemu najpierw sprawdź, czy edytujesz plik, który myślisz, że jesteś! Miałem ten problem, kiedy edytowałem transpiled plik JavaScript zamiast pliku źródłowego (wersja transpiled nie była pod kontrolą źródła).
Mój klient Git (Gitg) spowodował ten problem. Normalne polecenia, które zwykle wykonywałem, nie działały. Nawet dotknięcie każdego pliku w projekcie nie działało.
Znalazłem sposób, aby to naprawić i nadal nie jestem pewien, co było tego przyczyną. Skopiuj katalog projektu. Brakujące pliki pojawią się w skopiowanych katalogach git status. Zmiana nazwy może zrobić to samo.
Natrafiłem na problem, ale były to tylko dwa katalogi i nie wiedziałem, że oba te katalogi zostały skonfigurowane jako podmoduły git. Jak to się stało, nie mam pojęcia, ale proces polegał na wykonaniu niektórych instrukcji pod tym linkiem, ale NIE usunęłem katalogu (tak jak robi to na końcu), ale raczej zrobięgit add path/to/dir
Gdy edytujesz plik w programie Visual Studio, jest on natychmiast wyświetlany w zmianach git, nawet jeśli plik nie został zapisany. Wszystko, co musisz zrobić, to po prostu zapisać plik ręcznie (Ctrl + S dla aktualnie wyświetlanego pliku lub Ctrl + Shift + S dla wszystkich plików projektu), a git bash je pobierze.
.jspliku, podczas pracy z Visual Studio Code. Dziękuję Ci.
Upewnij się, że nie tworzysz dowiązań symbolicznych ( ln -s source dest) z wnętrza Git Bash dla Windows.
NIE tworzy dowiązań symbolicznych, ale robi GŁĘBOKĄ kopię źródła do miejsca docelowego
Doświadczyłem tego samego zachowania co OP na terminalu MINGW64 z Git Bash dla Windows (wersja 2.16.2), aby zdać sobie sprawę, że moje `` edytowane '' zmiany faktycznie znajdowały się w oryginalnym katalogu, a moje polecenia git bash pochodziły z głębokiej kopii, która pozostała niezmieniony.
Mnie też się to przytrafiło, wypróbowałem wyżej wymienione metody i nic nie pomogło. Wtedy rozwiązaniem była zmiana pliku za pośrednictwem terminala, a nie GUI. Nie wiem, dlaczego to zadziałało, ale zadziałało. Po edycji pliku przez nano z terminala git rozpoznał go jako zmieniony i mogłem go dodać i zatwierdzić.
Mam ten sam problem tutaj VS2015 nie rozpoznał moich zmian w plikach js, usunięcie pilotów z ustawień repozytorium, a następnie ponowne dodanie zdalnej ścieżki URL rozwiązało mój problem.
W moim przypadku robienie git reset --hardusuniętych plików i pozostawienie pustych folderów. Po przejrzeniu zawartości zauważyłem, że katalogi są puste.
Jednak git ignoruje puste foldery. (Poprawka, git ignoruje wszystkie katalogi podczas śledzenia zawartości, puste foldery nie są treścią).
spróbuj użyć git add *
wtedygit commit