Jak rozwiązać git, mówiąc „Zatwierdź swoje zmiany lub ukryj je, zanim będziesz mógł je scalić”?

761

Wprowadziłem kilka aktualizacji na moim komputerze lokalnym, wypchnąłem je do zdalnego repozytorium, a teraz próbuję pobrać zmiany na serwer i otrzymuję komunikat;

błąd: lokalne zmiany następujących plików zostaną zastąpione przez scalenie:

wp-content / w3tc-config / master.php

Zatwierdź zmiany lub schowaj je, zanim będzie można je scalić.

Więc pobiegłem

git checkout -- wp-content/w3tc-config/master.php

i spróbowałem jeszcze raz, a ja otrzymuję tę samą wiadomość. Zakładam, że w3tccoś zmieniło się w pliku konfiguracyjnym na serwerze. Nie dbam o to, czy kopia lokalna czy zdalna trafi na serwer (chyba zdalna jest najlepsza), chcę tylko móc scalić resztę moich zmian (aktualizacje wtyczek).

Jakieś pomysły?

Jo Sprague
źródło
11
To jest bardziej jednoznaczne pytanie z większą ilością szczegółów i lepszą odpowiedzią. Uważam, że warto mieć to przy sobie. Tak, drugi technicznie został najpierw zapytany, ale usunięcie go utrudniłoby ludziom znalezienie odpowiedzi, których szukają.
Jo Sprague,

Odpowiedzi:

1298

Nie można łączyć się z lokalnymi modyfikacjami. Git chroni przed utratą potencjalnie ważnych zmian.

Masz trzy opcje:

  • Zatwierdź zmianę za pomocą

    git commit -m "My message"
    
  • Schowaj to.

    Skrytka działa jak stos, w którym możesz przesuwać zmiany i przebijać je w odwrotnej kolejności.

    Aby ukryć, wpisz

    git stash
    

    Wykonaj scalenie, a następnie wyciągnij skrytkę:

    git stash pop
    
  • Odrzuć lokalne zmiany

    za pomocą git reset --hard
    lubgit checkout -t -f remote/branch

    Lub: Odrzuć lokalne zmiany dla określonego pliku

    za pomocą git checkout filename

stdcall
źródło
104
Możesz także odrzucić zmiany lokalne dla określonego pliku, wykonując: git checkout nazwa pliku
ckb
6
Dzięki. Dodam do tego, jeśli tak git reset --hard, możesz również usunąć nieśledzone pliki za pomocągit clean -dfx
Jo Sprague,
13
Domyślnie git stashnie przechowują plików, dla których nie ma historii. Jeśli więc masz pliki, które nie zostały jeszcze dodane, ale które zostałyby nadpisane lub „utworzone” przez scalanie, scalanie nadal będzie blokowane. W tej sytuacji możesz także użyć git stash -udo ukrywania niezaangażowanych plików. Lub możesz je po prostu usunąć!
joeytwiddle
25
bieganie git clean -dfxbyło okropnym pomysłem. Usunąłem niektóre pliki .gitignored, których tak naprawdę potrzebowałem.
ezuk
5
Zetknąłem się z sytuacją, w której użytkownik po zrobieniu git reset --hardnadal miał niezmergowane zmiany!
Amedee Van Gasse
83
git stash
git pull <remote name> <remote branch name> (or) switch branch
git stash apply --index

Pierwsze polecenie tymczasowo przechowuje zmiany w skrytce i usuwa je z katalogu roboczego.

Drugie polecenie przełącza gałęzie.

Trzecie polecenie przywraca zmiany, które zostały zapisane w skrytce ( --indexopcja ta jest przydatna, aby upewnić się, że przemieszczane pliki są nadal przemieszczane).

Loganathan
źródło
1
stackoverflow.com/questions/15286075/... , może być również przydatny
vikramvi
2
wyjaśnić punkt @ vikramvi: możemy również użyć git stash popzamiast git stash apply. Ten pierwszy usuwa go ze skrytki, a drugi nadal go trzyma
Anupam
27

Możesz wypróbować jedną z następujących metod:

rebase

W przypadku prostych zmian spróbuj nałożyć na nie zmiany, ciągnąc zmiany, np

git pull origin master -r

Więc po pobraniu zastosuje twoją bieżącą gałąź na górnej gałęzi.

Jest to równoznaczne z: checkout master, fetcha rebase origin/masterpolecenia git.

Jest to potencjalnie niebezpieczny tryb działania. Przepisuje historię, co nie wróży dobrze, gdy już ją opublikowałeś. Nie używaj tej opcji, chyba że git-rebase(1)dokładnie przeczytałeś .


sprawdzić

Jeśli nie przejmujesz się lokalnymi zmianami, możesz przejść do innego oddziału tymczasowo (z użyciem siły) i przywrócić go z powrotem, np

git checkout origin/master -f
git checkout master -f

Resetowanie

Jeśli nie przejmujesz się lokalnymi zmianami, spróbuj zresetować je do HEAD (stan pierwotny), np

git reset HEAD --hard

Jeśli powyższe nie pomoże, mogą to być reguły w twoim pliku normalizacji git ( .gitattributes), więc lepiej jest zatwierdzić to, co mówi. Lub twój system plików nie obsługuje uprawnień, więc musisz wyłączyć filemodew konfiguracji git.

Powiązane: Jak wymusić polecenie „git pull”, aby zastąpić pliki lokalne?

kenorb
źródło
1
Nie działa: wciąż pojawia się ten sam komunikat: „najpierw ukryj swoje zmiany”. Kiedy wpisuję „git stash”, a następnie „git pull” -> „błąd: masz niezapisane zmiany ... najpierw wykonaj ukrywanie”. Krótko przed zniszczeniem mojego komputera
trinity420,
@ trinity420 Czy to mogą być twoje uprawnienia do plików, sprawdź git statusjakie zmiany wprowadzasz po ukryciu. Jeśli żadna odpowiedź nie pomoże, rozważ dodanie nowego pytania.
kenorb
dziękuję, ale mój problem rozwiązany, próbowałem wszystkiego tutaj, nic nie działało, potem kliknąłem „zatwierdzanie zmian”, „scalanie” w PHPStorm, a następnie rozpakowałem zmiany i zadziałało.
trinity420
13

Tak więc sytuacja, na którą wpadłem, była następująca:

błąd: lokalne zmiany w następujących plikach zostałyby zastąpione przez scalenie: wp-content / w3tc-config / master.php Proszę zatwierdzić zmiany lub ukryć je przed scaleniem.

z wyjątkiem, tuż przed tym, był zdalny: tak właściwie to:

remote: error: Lokalne zmiany w następujących plikach zostałyby zastąpione przez scalanie: some / file.ext Proszę zatwierdzić zmiany lub ukryć je przed scaleniem.

To, co się działo, było (myślę, że nie w 100% pozytywne) hak po otrzymaniu git po uruchomieniu zaczął się psować z powodu zmian ruchu w zdalnym repozytorium serwera, które teoretycznie nie powinny były zostać dotknięte.

Więc to, co skończyło się na przeszukaniu przechwytywania po otrzymaniu i znalezieniu tego, to musiałem udać się do zdalnego repozytorium na serwerze i nastąpiła zmiana (która nie była w moim lokalnym repozytorium, która w rzeczywistości powiedział, że pasuje, nie ma zmian, nic do zatwierdzenia, na bieżąco itp.) Tak więc, podczas gdy na lokalnym, nie było żadnych zmian, na serwerze, zrobiłem git checkout -- some/file.exta następnie lokalne i zdalne repozytoria faktycznie pasowały i mogłem kontynuuj pracę i wdrażaj. Nie do końca wiadomo, jak doszło do tej sytuacji, chociaż kilkudziesięciu programistów plus zmiany IT mogą mieć z tym coś wspólnego.

Mikrofon
źródło
2
Czy to pytanie czy odpowiedź?
stdcall
2
@stdcall - Trochę obu. Kiedy wpadłem na taką sytuację, jak opisano w pytaniu, to właśnie musiałem zrobić, aby to naprawić. Zdecydowanie nie było to normalne rozwiązywanie problemów z gitem i z pytania wynika, że ​​może to być ta sama nienormalna sytuacja (tj. Zmiany konfiguracji na serwerze, ale lokalny nie ma zmian). Jeśli ktoś ma więcej pomysłów na to, dlaczego (lub jak) to się wydarzyło, chętnie wrócę.
Mike
7

OSTRZEŻENIE: Spowoduje to usunięcie nieśledzonych plików, więc nie jest to świetna odpowiedź na to pytanie.

W moim przypadku nie chciałem przechowywać plików, więc zadziałało to dla mnie:

Git 2.11 i nowsze:

git clean  -d  -fx .

Starsze Git:

git clean  -d  -fx ""

Odniesienie: http://www.kernel.org/pub/software/scm/git/docs/git-clean.html

  • -x oznacza, że ​​ignorowane pliki są również usuwane, a także pliki nieznane dla git.

  • -d oznacza usunięcie nieśledzonych katalogów oprócz nieśledzonych plików.

  • -f jest wymagane do wymuszenia uruchomienia.

Ciemna materia
źródło
4

Aby zachować rejestr nowo utworzonych plików podczas rozwiązywania tego problemu:

Jeśli masz nowo utworzone pliki , możesz utworzyć poprawkę lokalnych zmian, pobrać zdalne scalenia i zastosować poprawkę lokalną po zakończeniu zdalnego scalania, jak zdefiniowano krok po kroku poniżej:

  1. Dokonaj zmian lokalnych. (nie zatwierdzaj). Staging jest wymagany, aby utworzyć poprawkę do nowo utworzonych plików (ponieważ nadal nie są one śledzone)

git add .

  1. Utwórz łatkę, aby zachować rejestr

git diff --cached > mypatch.patch

  1. Odrzuć lokalne zmiany i usuń nowe lokalne pliki

git reset --hard

  1. Wyciągnij zmiany

git pull

  1. Zastosuj łatkę

git apply mypatch.patch

Git połączy zmiany i utworzy pliki .rej dla zmian, które nie zostały scalone.

Zgodnie z sugestią Anu, jeśli masz problemy ze stosowaniem łatki, spróbuj:

git apply --reject --whitespace=fix mypatch.patch Ta odpowiedź git: patch nie stosuje szczegółowych rozmów na ten temat

Ciesz się dalszą pracą nad funkcją i po zakończeniu zatwierdź lokalne zmiany.

Manpreet
źródło
Chciałem przesunąć część kodu z nowymi zmianami, więc: 1. utworzyłem łatkę z mojej lokalnej gałęzi programistów 2. wykonałem twardy reset 3. ściągnąłem nowe zmiany z master na dev (aby uniknąć konfliktów scalania) 4 zrobiłem małą zmianę w moim lokalnym dev 5. wypchnąłem do zdalnego dev 6. zastosowałem łatkę z powrotem -> error: patch failed: yourfile.py:33 error: yourfile.py: patch does not applyWystąpił błąd :, wciąż mam plik mypatch.patch, ale nie wiem, dlaczego nie został zastosowany i straciłem zmiany !
Anu
Rozumiem, poprawne polecenie brzmiało git apply --reject --whitespace=fix mypatch.patch: odzyskałem moje zmiany, uff !!! [Dzięki] ( stackoverflow.com/a/15375869/6484358 )
Anu
1
Anu, polecenie git Apply mypatch.patch jest poprawne, aby zastosować łatkę, tego używam cały czas, może być jakiś problem z samą utworzoną łatką, i nigdy nie stracisz zmian, jeśli masz pod ręką łatkę, to zawiera wszystkie skonsolidowane zmiany.
Manpreet
2

Pytanie o zatwierdzenie przed ściągnięciem

  • git skrytka
  • git pull origin << nazwa gałęzi >>

Jeśli potrzebne :

  • zastosowanie git stash
Rahul Mankar
źródło
1
Użyj git stash, jeśli chcesz zapisać bieżący stan katalogu roboczego i indeksu, ale chcesz wrócić do czystego katalogu roboczego. Polecenie zapisuje lokalne modyfikacje i przywraca katalog roboczy, aby pasował do zatwierdzenia HEAD.
Pushpak Sharma
2

Dla mnie tylko git reset --harddziałało.

Zatwierdzenie nie było opcją, ponieważ nie było nic do popełnienia.

Składowanie nie było opcją, ponieważ nie było nic do ukrycia.

Wygląda jakby mogło być od wykluczonych plików w .git/info/excludei po git update-index --assume-unchanged <file>„ed niektórych plików.

Lew
źródło
0

W moim przypadku utworzyłem kopię zapasową, a następnie usunąłem plik, na który Git narzekał, popełnił, po czym mogłem w końcu sprawdzić inny oddział.

Następnie zastąpiłem plik, skopiowałem z powrotem do treści i kontynuowałem, jakby nic się nie stało.

CodyBugstein
źródło
0

Spróbowałem pierwszej odpowiedzi: git stashz najwyższym wynikiem, ale komunikat o błędzie wciąż się pojawiał, a potem znalazłem ten artykuł, aby zatwierdzić zmiany zamiast ukryć „Niechętne popełnienie”

i komunikat o błędzie zniknął w końcu:

1: git add .

2: git commit -m "this is an additional commit"

3: git checkout the-other-file-name

wtedy zadziałało. mam nadzieję, że ta odpowiedź pomoże. :)

Sophie Cai
źródło
0

Jeśli używasz rozszerzeń Git , powinieneś być w stanie znaleźć lokalne zmiany w Working directorysposób pokazany poniżej:

wprowadź opis zdjęcia tutaj

Jeśli nie widzisz żadnych zmian, prawdopodobnie przyczyną jest niewłaściwy podmoduł. Sprawdź więc wszystkie elementy za pomocą ikony łodzi podwodnej, jak pokazano poniżej:

wprowadź opis zdjęcia tutaj

Po znalezieniu niezatwierdzonej zmiany:

Wybierz linię za pomocą Working directory, przejdź do zakładki Zróżnicowane , kliknij prawym przyciskiem myszy ikonę ołówka (lub +lub -), wybierz Resetuj, aby najpierw zatwierdzić lub zatwierdzić lub ukryć lub cokolwiek z tym zrobić.

Bizhan
źródło
0

Dla mnie to zadziałało:

git reset --hard

i wtedy

git pull origin <*current branch>

po tym

git checkout <*branch>

Chloe
źródło
0

Prawdopodobnie

git --rebase --autostash

mogłoby pomóc

Eugen Konkov
źródło