Więc dodałem folder do mojego pliku .gitignore.

Kiedy to zrobię git status, mówi mi to

# On branch latest
nothing to commit (working directory clean)

Jednak gdy próbuję zmienić gałęzie, otrzymuję następujące informacje:

My-MacBook-Pro:webapp marcamillion$ git checkout develop
error: The following untracked working tree files would be overwritten by checkout:
    public/system/images/9/thumb/red-stripe.jpg
    public/system/images/9/original/red-stripe.jpg
    public/system/images/8/thumb/red-stripe-red.jpg
    public/system/images/8/original/red-stripe-red.jpg
    public/system/images/8/original/00-louis_c.k.-chewed_up-cover-2008.jpg
    public/system/images/7/thumb/red-stripe-dark.jpg
    public/system/images/7/original/red-stripe-dark.jpg
    public/system/images/7/original/DSC07833.JPG
    public/system/images/6/thumb/red-stripe-bw.jpg
    public/system/images/6/original/website-logo.png
    public/system/images/6/original/red-stripe-bw.jpg
    public/system/images/5/thumb/Guy_Waving_Jamaican_Flag.jpg
    public/system/images/5/original/logocompv-colored-squares-100px.png
    public/system/images/5/original/Guy_Waving_Jamaican_Flag.jpg
    public/system/images/4/thumb/DSC_0001.JPG
    public/system/images/4/original/logo.png
    public/system/images/4/original/DSC_0001.JPG
    public/system/images/4/original/2-up.jpg
    public/system/images/3/thumb/logo2.gif
    public/system/images/3/original/logo2.gif
    public/system/images/3/original/Guy_Waving_Jamaican_Flag.jpg
    public/system/images/3/original/11002000962.jpg
    public/system/images/2/thumb/Profile Pic.jpg
    public/system/images/2/original/Profile Pic.jpg
    public/system/images/2/original/02 Login Screen.jpg
    public/system/images/1/original/Argentina-2010-World-Cup.jpg
Please move or remove them before you can switch branches.
Aborting

Tak wygląda mój plik .gitignore:

.bundle
.DS_Store
db/*.sqlite3
log/*.log
tmp/**/*
public/system/images/*
public/system/avatars/*

Jak mogę to uruchomić, aby móc przełączać gałęzie bez usuwania tych plików?

Jeśli dokonam zmiany, czy wpłynie to na te pliki? Innymi słowy, jeśli później wrócę do tej gałęzi, czy wszystko będzie idealnie jak do mojego ostatniego zatwierdzenia?

Nie chcę stracić tych plików, po prostu nie chcę ich śledzić.

Wygląda na to, że chcesz zignorować pliki, ale zostały już zatwierdzone. .gitignore nie ma wpływu na pliki, które są już w repozytorium, więc należy je usunąć za pomocą git rm --cached. --cachedBędzie zapobiec konieczności żadnego wpływu na swojej kopii roboczej i będzie to tylko oznaczyć jako usunięte podczas następnego zatwierdzenia. Po usunięciu plików z repozytorium .gitignore uniemożliwi ich ponowne dodanie.

Ale masz inny problem z .gitignore, nadmiernie używasz symboli wieloznacznych i powoduje to, że pasuje mniej, niż się spodziewasz. Zamiast tego zmieńmy .gitignore i spróbuj tego.

.bundle
.DS_Store
db/*.sqlite3
log/*.log
tmp/
public/system/images/
public/system/avatars/

OSTRZEŻENIE: usunie nieśledzone pliki, więc nie jest to świetna odpowiedź na postawione pytanie.

Uderzyłem również w tę wiadomość. 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  -f .

starszy git

git clean  -d  -f ""

Jeśli chcesz również usunąć pliki ignorowane przez git, wykonaj następujące polecenie.

BYĆ OSTRZEŻONYM!!! NAJBARDZIEJ PRAWDOPODOBNIE NISZCZY TWÓJ PROJEKT, WYKORZYSTAJ TYLKO JEŻELI WIESZ 100% CO ROBISZ

git 2.11 i nowsze

git clean  -d  -fx .

starszy git

git clean  -d  -fx ""

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, aby wymusić uruchomienie.

Ostrzeżenie: spowoduje to usunięcie plików lokalnych, które nie są indeksowane

Po prostu wymuś: git checkout -f another-branch

Jeśli korzystasz z systemu OS X, przyczyną może być to, że w nazwie pliku zmieniła się wielkość liter. Spróbuj ustawić następującą opcję konfiguracji:

git config core.ignorecase true

Git mówi ci, że chce tworzyć pliki (o nazwie public/system/images/9/...itp.), Ale masz już pliki w tym katalogu, które nie są śledzone przez Git. Być może ktoś inny dodał te pliki do repozytorium Git i po raz pierwszy przeszedłeś do tej gałęzi?

Prawdopodobnie istnieje powód, dla którego te pliki w twoim developoddziale, ale nie w bieżącym oddziale. Być może będziesz musiał zapytać współpracowników, dlaczego tak jest.

jak mogę to uruchomić, aby móc przełączać gałęzie bez usuwania tych plików?

Nie możesz tego zrobić, jeśli pliki nie znikną. Na razie możesz zmienić nazwę publicna my_publiclub coś takiego.

jeśli wrócę później do tej gałęzi, czy wszystko będzie idealnie jak do mojego ostatniego zatwierdzenia?

Jeśli zatwierdzisz zmiany, Git ich nie utraci. Jeśli nie zatwierdzisz zmian, Git bardzo się postara, aby nie nadpisać wykonanej pracy. Właśnie o tym ostrzega Git w pierwszej instancji (kiedy próbowałeś zmienić gałąź).

To zadziałało dla mnie.

 1. git fetch --all
 2. git reset --hard origin/{branch_name}

Dla tego delikatnego zadania istnieje polecenie (trwałe usunięcie nieśledzonych plików)

git clean -i

Wtedy git pullzrobi.

Dla tych, którzy potrzebują czegoś mniej dalekosiężnego niż odpowiedź Scotta Schafera ,

git clean -f

prawdopodobnie zadziała. I bardzo sugerują działa

git clean --dry-run

pierwszy. To polecenie wyświetli listę plików, które Git usunie, jeśli uruchomisz git clean -f, i może zaoszczędzić ci bólu związanego z przypadkowym usunięciem czegoś, czego nie chciałeś.

Zobacz tę odpowiedź Stos Oveflow lub docs aby uzyskać więcej informacji na temat git clean.

Niestety, ani git rm --cachedczy git clean -d -fx ""zrobił to dla mnie.

Moje rozwiązanie zakończyło się wypychaniem mojego oddziału do zdalnego, klonowaniem nowego repozytorium, a następnie scalaniem w nowym repozytorium. Inne osoby uzyskujące dostęp do repozytorium musiały zrobić to samo.

Morał tej historii: użyj .gitignorepliku od samego początku.

Jeśli chcesz szybko rozwiązać to pytanie, możesz użyć tego polecenia:

git checkout -f dev

Miałem ten sam problem podczas sprawdzania w oddziale na podstawie wcześniejszego zatwierdzenia. Git odmówił realizacji transakcji z powodu nieśledzonych plików.

Znalazłem rozwiązanie i mam nadzieję, że to również pomoże.

Dodanie katalogów, których dotyczy problem, .gitignorei wydawanie $ git rm -r --cachedna nich najwyraźniej nie wystarczy.

Załóżmy, że chcesz, aby gałąź była oparta na wcześniejszym zatwierdzeniu K w celu przetestowania niektórych rzeczy i powrotu do bieżącej wersji. Zrobiłbym to w następujących krokach:

1. Skonfiguruj nieśledzone pliki: edytuj .gitignorei zastosuj $ git rm -r --cacheddo plików i katalogów, które git ma ignorować. Dodaj także .gitignoresam plik .gitignorei nie zapomnij go wydać $ git rm -r --cached .gitignore. Zapewni to zachowanie ignorowania git pozostawi to samo we wcześniejszych zatwierdzeniach.

2. Zatwierdź właśnie wprowadzone zmiany:

   $ git add -A
$ git commit

3. Zapisz bieżący dziennik, w przeciwnym razie możesz mieć problemy z powrotem do bieżącej wersji

   $ git log > ../git.log

4. Twardy reset do zatwierdzenia K

   $ git reset --hard version_k

5. Utwórz gałąź na podstawie zatwierdzenia K

   $ git branch commit_k_branch

6. Kasa do tego oddziału

   $ git checkout commit_k_branch

7. Rób swoje rzeczy i popełniaj je

8. Kasa ponownie do mistrza

   $ git checkout master

9. Zresetuj ponownie do bieżącej wersji

   $ git reset current_version lub $ git reset ORIG_HEAD

10. Teraz możesz ciężko zresetować HEAD

    git reset --hard HEAD

UWAGA! Nie pomijaj kroku od ostatniego do ostatniego (jak np. $ git reset --hard ORIG_HEAD ), Ponieważ nieśledzone pliki, które skarżył się powyżej, zostaną utracone.

Upewniłem się również, że pliki, na które skarżył się git, nie zostały usunięte. Skopiowałem je do pliku tekstowego i wydałem polecenie$ for i in $(cat ../test.txt); do ls -ahl $i; done

Jeśli ponownie dokonujesz płatności do wyżej wymienionej gałęzi, nie zapomnij wydać polecenia, $ git statusaby upewnić się, że nie pojawią się niepożądane zmiany.

Zdarzyło mi się to w systemie Windows 8 , używając Git z wiersza polecenia. Reszta mojego zespołu używa TFS , a ja używam git-tf Microsoftu do wypychania / ściągania między TFS a moim lokalnym repozytorium Git.

Problem powstał z powodu zmiany nazw niektórych plików tylko w celu zmiany ich wielkości . Wydaje się, że tak się stało:

• Pliki były rejestrowane z mieszaną obudową w ich nazwach.
• W późniejszym zatwierdzeniu nazwy plików zostały zmienione na wszystkie małe litery.
• git-tf początkowo dostał pliki w różnych przypadkach.
• Gdy nazwy plików zmieniono na małe, git-tf nie otrzymał plików, ponieważ w systemie Windows 8 te nazwy plików są równoważne.
• Ponieważ w Git rozróżniana jest wielkość liter, narzekał, że mam pliki o różnej wielkości liter, które nie były pod kontrolą źródła. Ale przy użyciu git statusnie widziałem żadnych zmian, ponieważ w wierszu polecenia systemu Windows te nazwy plików są równoważne.

Najprostszym rozwiązaniem dla mnie było:

• git checkoutpoprzednia wersja projektu, na długo przed dodaniem tych plików .
• Następnie git checkoutnajnowsza wersja projektu z poprawną obudową pliku.

Te dwie funkcje (git rm --cached, git checkout -f another-branch) NIE działały dla mnie.

Zamiast tego fizycznie usunąłem plik (zaćmienie) zgodnie z poleceniem Gita; Proszę je przenieść lub usunąć, zanim będzie można zmienić oddziały.

a następnie dodaję / zatwierdzam.

a potem pociągnąłem i zadziałało!

W moim przypadku problem dotyczył submodułów. masterzostał połączony z innym oddziałem, który dodał nowy podmoduł do projektu. Oddział, który próbowałem wyewidencjonować, nie miał go, dlatego git narzekał na nieśledzone pliki i żadne inne sugerowane rozwiązanie nie działało dla mnie. Zmusiłem kasę do mojego nowego oddziału i pociągnąłem mistrza.

• git checkout -f my_branch
• git pull origin master
• git submodule update --init

W moim przypadku git rm --cachednie działało. Ale mam to zgit rebase

Miałem również podobny problem i wypróbowałem wszystkie powyższe rozwiązania, ale to nie zadziałało

Kwestia ta była spowodowana kiedy przemianowano mój onMusicUpdateListener.javaTO OnMusicUpdateListener.javaw developbranży.

Teraz mastermiał onMusicUpdateListener.java i developmiał taki sam plik jakOnMusicUpdateListener.java

Teraz, gdy przełączałem się na master, dawał mi błąd

The following untracked working tree files would be overwritten by checkout

a potem to aborted.

Aby rozwiązać ten problem, i mocno checked out mastergałęzi i następnie przemianowany na mój onMusicUpdateListener.javado OnMusicUpdateListener.java, committedto i wtedy mergedona z developgałęzi.

Potem aktualizowane mój developoddział przez mergingniego do masteri teraz wszystko wróciło do normy i problem został rozwiązany.

Może to być problem z pozwoleniem,

zmienić własność,

sudo chown -v -R usr-name:group-name folder-name

Problemem mogą być 2 pliki o tej samej nazwie, ale w innym przypadku.

Możesz usunąć jeden z tych plików lub zmienić jego nazwę. Dawny:

Pdf.html.twig (The GOOD one)

pdf.html.twig (The one I deleted)

Przenieś pliki zamiast usuń

Jednym ze sposobów uniknięcia usuwania plików jest ich przeniesienie. Na przykład:

cd "`git rev-parse --show-toplevel`"
git checkout 2>&1 | while read f; do [ ! -e "$f" ] || mv "$f" "$f".bak; done

Jeśli nazwa pliku została zmieniona lokalnie, a następnie wykonaj pull, zostanie wyświetlony ten komunikat o błędzie.

to łatwe do rozwiązania, git mówi, że masz te same pliki w obu gałęziach, dlatego musisz usunąć określone pliki z gałęzi master, a następnie będziesz mógł scalić:

git scala „twoją gałąź”

Mam nadzieję, że to zadziała, właśnie rozwiązałem swój błąd. mój błąd to:

błąd: Następujące nie śledzone pliki działającego drzewa zostaną zastąpione przez scalanie: .vs / slnx.sqlite Proszę przenieść lub usunąć je przed scaleniem. Przerwanie

Teraz działa! W moim przypadku .vs / slnx.sqlite został wygenerowany przez visual studio, musiałem go zamknąć przed usunięciem.

W moim przypadku widziałem ten błąd, ponieważ korzystam z popularnego CMS typu open source, a katalog, który powodował problemy, to katalog do przesyłania, do którego CMS zapisuje.

Mówił więc, że istnieją pliki, których nie masz, ale których nie można uzyskać z wersji.

Pobieram wszystkie pliki z witryny na żywo do mojego lokalnego, a następnie sprawdzę to w repozytorium w nadziei, że to rozwiąże problem.

Usuń .gitignore plik appname / Gen / , aby rozwiązać ten problem.

Po prostu poszedłem do systemu plików i bezpośrednio usunąłem plik, a następnie kontynuowałem sprawdzanie git i zadziałało.

Problem występował kilka razy i może być związany z programistami wykonującymi usuwanie, wypychanie, ponowne dodawanie, wypychanie lub coś takiego.

Większość odpowiedzi rozważa usunięcie lub usunięcie plików, co jest łatwym sposobem. Ale czasami nie chcesz pozbyć się lokalnych plików. Ale połącz się ze strategią, więc git też ma na to rozwiązanie;

git merge --strategy=ours master 

Wystarczy usunąć pliki lub zmienić ich nazwę.

na przykład

$ git pull
Enter passphrase for key '/c/Users/PC983/.ssh/id_rsa':
error: Your local changes to the following files would be overwritten by merge:
        ajax/productPrice.php
Please commit your changes or stash them before you merge.
error: The following untracked working tree files would be overwritten by merge:
        ajax/product.php
Please move or remove them before you merge.
Aborting
Updating a04cbe7a..6aa8ead5

Musiałem zmienić nazwę / usunąć ajax / product.php i ajax / produtPrice.php .

Nie martw się, git pull przywróci je. Sugeruję zmianę nazwy zamiast usuwania, ponieważ możesz utracić niektóre zmiany.

Jeśli to nie pomoże, musisz usunąć cały Oddział i utworzyć go ponownie, a następnie zrobić git pull origin remotebranch

Aby zapisać zmodyfikowane pliki i użyć zmodyfikowanej zawartości później. Znalazłem ten błąd, gdy próbuję sprawdzić gałąź i podczas próby zmiany bazy. Wypróbuj skrytkę Git

git stash

Sprawdź, czy nazwa folderu ma symbol „/” lub jakiś specjalny symbol, a następnie zmień nazwę tego folderu. Następnie klonujesz repozytorium w inne miejsce.

Prostym rozwiązaniem może być: Upewnij się, że jesteś w odpowiednim katalogu roboczym GitBash. Wiadomość ta pojawia się prawie za każdym razem, gdy użytkownik próbuje scalić katalog zbyt wysoko w swojej hierarchii folderów.

Przykład:

/workspace/git/myBashSourceFolder/myProjectSourcefolder

Scenariusz: Użytkownik sklonował repozytorium w git-folder, stworzył nowy projekt Java w Eclipse, zaimportował sklonowane repozytorium. Eclipse ustawił myProjectSourceFolder jako folder źródłowy w swoim lokalnym projekcie. dlatego Użytkownik wprowadził go w git bash i pchnął, pociągnął i zlecił swój projekt stamtąd. git synchronizuje więc myProjectSourceFolder- ale nie ma w swojej historii żadnego rekordu dla myBashSourceFolder. Dlatego push / pull / merge z myBashSourceFolder wygeneruje dane wyjściowe, jeśli użytkownik spróbuje synchronizować stamtąd następnym razem, zamiast folderu, który wcześniej pracował.

Rozwiązanie: Wprowadź poprawny folder i spróbuj ponownie. Niemal za każdym razem, gdy się spotkałem, to rozwiązanie działało dobrze :)