Błąd podczas zmiany na gałąź główną: moje zmiany lokalne zostałyby nadpisane przy kasie


129

To pytanie jest podobne do tego , ale bardziej szczegółowe.

Mam projekt z dwoma gałęziami ( stagingi beta).

Rozwijam się dalej stagingi używam mastergałęzi do naprawiania błędów. Więc jeśli pracuję nad stagingiem i widzę błąd, zmieniam na mastergałąź:

git checkout master

i zrób to:

git add fileToAdd
git commit -m "bug fixed"

a potem łączę się z obiema gałęziami:

git checkout staging
git merge master
git checkout beta
git merge beta

I nie ma znaczenia, czy w drzewie roboczym są inne pliki.

Ale teraz, gdy próbuję przejść na mastergałąź , pojawia się błąd :

error: Your local changes to the following files would be overwritten by checkout:
src/Pro/ConvocationBundle/Controller/DefaultController.php
Please, commit your changes or stash them before you can switch branches.
Aborting

Pomyślałem, że powinienem usunąć plik z obszaru przemieszczania:

git reset HEAD src/Pro/ConvocationBundle/Controller/DefaultController.php

ale otrzymuję ten sam błąd. Jeśli git statusdostanęNo changes to commit


4
Czy próbowałeś reset --hard? Jeśli naprawdę chcesz odrzucić zmiany. Lub użyj skrytki, jeśli tego nie zrobisz.
keltar

@keltar - Nie. Nie chcę odrzucać moich zmian. Po prostu trzymaj je na drzewie roboczym do późniejszego zatwierdzenia
Manolo

1
Nie sądzę, aby można było przełączać gałęzie, zachowując niezatwierdzone zmiany, ale łatwo mogę się mylić - nie do końca moja dziedzina. Spróbuj się git add your-filezaangażować.
keltar

@keltar - pracowałem wcześniej w ten sposób. Nie chcę stagingteraz wprowadzać żadnych zmian .
Manolo

Być może plik powodujący konflikt nie został zmieniony, gdy próbowałeś tego wcześniej. Masz zmiany, git musi je gdzieś zapisać, aby później przywrócić. Bez zatwierdzeń jest to bardzo mało prawdopodobne. Ale jeśli naprawdę nie chcesz - użyj skrytki, właśnie dlatego ona istnieje.
keltar

Odpowiedzi:


128

Twój błąd pojawia się, gdy zmodyfikowałeś plik, a gałąź, do której się przełączasz, również zawiera zmiany dla tego pliku (z ostatniego punktu scalania).

Twoje opcje, jak ja to widzę, to - commit, a następnie uzupełnij ten commit o dodatkowe zmiany (możesz modyfikować zatwierdzenia w git, o ile nie są edytowane push); lub - użyj skrytki:

git stash save your-file-name
git checkout master
# do whatever you had to do with master
git checkout staging
git stash pop

git stash saveutworzy magazyn zawierający twoje zmiany, ale nie jest powiązany z żadnym zatwierdzeniem ani nawet gałęzią. git stash popzastosuje najnowszy wpis do twojego aktualnego oddziału, przywracając zapisane zmiany i usuwając go ze skrytki.


3
Dziękuję Ci. Czy na pewno nie spowoduje to żadnych zmian w moim drzewie roboczym (nie dodane pliki)? Nie chcę stracić zmian: - /
Manolo

Ups, błędnie wpisano, addkiedy jest faktycznie save.. zaktualizowany. Masz na myśli inne pliki? git stash savebez parametru nazwy pliku zapisze wszystkie zmodyfikowane pliki, jeśli chcesz (i przywróci je do stanu ostatnio zatwierdzonego). Posiadanie dodatkowej kopii drzewa katalogów nigdy nie boli, ale zawsze mam paranoję.
keltar

Chodzi o to, aby zapisać wszystkie zmodyfikowane pliki z wyjątkiem tego, który chcę dodać do mastergałęzi. Opcją byłyby popteż zmiany w innej branży?
Manolo,

Nie jestem pewny co masz na myśli. Tak, możesz zastosować skrytkę w innej gałęzi, ale spowoduje to po prostu zastąpienie zawartości plików, a nie ich scalenie.
keltar

1
@ Kochanie, to nie ma nic wspólnego z gałęziami, problemem są niezatwierdzone zmiany. Checkout, z definicji, musi zresetować pliki do stanu master, ale w ten sposób utraci swoją aktualną zawartość, a ponieważ ta zawartość nie zostanie zatwierdzona , nie będzie można później wrócić do tego stanu, stąd błąd, więc nie byłby zdenerwowany utraconymi zmianami później.
keltar

152

Napotkałem ten sam problem i rozwiązałem go przez

git checkout -f branch

a jego specyfikacja jest dość jasna.

-f, --force

Podczas przełączania gałęzi należy postępować, nawet jeśli indeks lub drzewo robocze różni się od HEAD. Służy do odrzucania lokalnych zmian.

Podczas wypisywania ścieżek z indeksu nie przerywaj niescalonych pozycji; zamiast tego niescalone wpisy są ignorowane.


7
Kiedy mój git się zaciął (brak lokalnych zmian, ale nadal ten błąd), to rozwiązanie pomogło mi!
lukyer

6
Dzięki, uratowałeś mój ekran przed przebiciem się przez niego pięścią.
Owl

3
W ten sposób straciłem swoje zmiany
Jacek Dziurdzikowski

1
Tak, utracisz zmiany, robiąc to, powinno to wiązać się z dużym zastrzeżeniem.
Alexander Mills,

Chcę tego na odwrót. master znajduje się za moją gałęzią i jestem na bieżąco z mistrzem, ale nadal nie mogę zmienić gałęzi. To musi być błąd git.
jgmjgm

12

Możesz wymusić wyewidencjonowanie swojego oddziału, jeśli nie chcesz zatwierdzać lokalnych zmian.

git checkout -f branch_name

1
Nie sudojest to konieczne, spowoduje tylko złamanie uprawnień do pliku. To ta sama komenda git, którą opublikował rok wcześniej @kiki_yu , ale jest jeszcze gorzej.
kenorb

2
W ten sposób straciłem swoje zmiany
Jacek Dziurdzikowski

2
@JacekDziurdzikowski Tak więc dwukrotnie straciłeś swoje zmiany (patrz komentarz do odpowiedzi kiki_yu), oba przez zastosowanie rozwiązań, które bardzo wyraźnie wspominają, że głównym celem było odrzucenie lokalnych zmian . Czy mój wykrywacz sarkazmu jest uszkodzony, czy ... mówisz poważnie?
RomainValeri

@RomainValeri Hmm, myślę, że to był mój sposób na ostrzeżenie innych, którzy są początkującymi z gitem (muszą być początkującymi, jeśli czytają ten post), aby byli gotowi pożegnać się ze zmianami, które wprowadzili. Pomyślałem, że czas, kiedy zmiany dokonane w jednym oddziale powinny pozostać w tym oddziale, dopóki go ponownie nie sprawdzę. Wskazówka dla nowicjuszy, którzy też myślą w ten sposób: użyj skrytki git :)
Jacek Dziurdzikowski

Zduplikowana odpowiedź bez powodu. Pierwsza odpowiedź zawiera jeszcze więcej informacji.
MAChitgarha

9

Napotkałem ten sam problem i rozwiązałem go przez

git checkout -f gałąź

Cóż, uważaj na -fprzełącznik. Jeśli użyjesz -fprzełącznika, utracisz wszystkie niezatwierdzone zmiany . Chociaż mogą istnieć przypadki użycia, w których warto użyć -f, w większości przypadków możesz chcieć stashwprowadzić zmiany, a następnie switchrozgałęzić. stashingProcedurę przedstawiono powyżej.


0

Możesz zatwierdzić w bieżącej gałęzi, wyewidencjonować do innej gałęzi, a na koniec wybrać najlepsze zatwierdzenie (zamiast scalania).


Może być bardziej pomocne, jeśli podasz więcej wyjaśnień na ten temat.
MAChitgarha

-1

Jeśli otrzymasz ten komunikat podczas próby wyewidencjonowania innej gałęzi:

my-mac:myGHProject ~$ git checkout other-branch
error: Your local changes to the following files would be overwritten by checkout:
    src/main/resources/reference.conf

Oznacza to, że masz pewne zmiany, które musisz zatwierdzić w gałęzi, którą wyewidencjonowałeś - lub musisz je wyczyścić lub schować, jak większość powyższych punktów. W 19 na 20 razy bardziej prawdopodobne jest, że po prostu wprowadzę zmiany.

my-mac:myGHProject ~$ git branch
  * my-local-branch
  * develop    

my-mac:myGHProject ~$ git status
On branch my-local-branch
   Changes not staged for commit:
   (use "git add <file>..." to update what will be committed)
   (use "git checkout -- <file>..." to discard changes in working directory)
 modified:   src/main/resources/reference.conf

my-mac:myGHProject ~$ git add src/main/resources/reference.conf

my-mac:myGHProject ~$ git commit -m "updates on some config"
  [my-local-branch] updates on some config
  1 file changed, 131 insertions(+), 85 deletions(-)

Teraz, gdy to zrobiłeś, możesz sprawdzić drugą gałąź i dość łatwo przełączać się tam iz powrotem.

my-mac:myGHProject ~$ git checkout other-branch

my-mac:myGHProject ~$ git status
  On branch other-branch

my-mac:myGHProject ~$ git checkout my-local-branch
  Switched to branch 'my-local-branch'

Po prostu upewnij się, że oboje znajdujesz się na właściwej gałęzi i pchasz do prawej gałęzi, gdy uruchamiasz polecenie git push origin $ {branch}. Uwaga: jeśli masz swój projekt bezpośrednio podpięty do Intellij, możesz zobaczyć, że zmieniłeś gałąź w prawym dolnym rogu głównego okna.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.