Czy jest dobry sposób wyjaśnienia, jak rozwiązać "! [rejected] master -> master (fetch first)'" w Git?! [odrzucone] master -> master (pobierz najpierw)
Po użyciu tego polecenia $ git push origin master wyświetla komunikat o błędzie.
! [rejected] master -> master (fetch first)
error: failed to push some refs to '[email protected]:zapnaa/abcappp.git'
Odpowiedź jest na to, git mówi, abyś najpierw pobierał.
Prawdopodobnie ktoś jeszcze popchnął do opanowania, a twoje zatwierdzenie jest z tyłu. Dlatego musisz pobrać, połączyć zestaw zmian, a następnie będziesz mógł ponownie naciskać.
Jeśli nie (lub co gorsza, jeśli wymusisz je przy użyciu opcji --force), możesz zepsuć historię zatwierdzania.
EDYCJA: Dostaję więcej szczegółów na temat ostatniego punktu, ponieważ facet tutaj właśnie dał bardzo złą poradę dotyczącą korzystania z opcji --force.
Ponieważ git jest DVCS, najlepiej wielu innych programistów pracuje nad tym samym projektem co ty, używając tego samego repozytorium (lub jego widelca). Jeśli nadpisasz na siłę swój zestaw zmian, twoje repozytorium będzie niezgodne z cudzymi, ponieważ "przepisałeś historię". Sprawisz, że inni ludzie będą nieszczęśliwi, a repozytorium ucierpi. Prawdopodobnie płacze też na tym świecie.
TL; DR
--force.Poprosiłeś o pierwsze. Idź na 1) zawsze, nawet jeśli zawsze będziesz używał gita sam, ponieważ jest to dobra praktyka.
Może nie ściągam usunąć ważnych zmian w plikach lokalnych? –
Nie zmienia się po pobraniu – dhein
@dhein tak jak napisałem, po fetch musi nastąpić scalenie - chodzi o to, że musisz "wyrównać" lokalne drzewo ze zdalnym drzewem (stąd przy scalaniu) - ale dzięki, napisałem to w TL; DR też – linuxbandit
Spróbuj polecenia git
git push origin master --force
lub krótkie siły -f
git push origin master -f
Dzięki @ user1865618, git push origin master --force. to polecenie uratowało mój czas. –
To zabawne, kiedy to czytasz, po przeczytaniu innych odpowiedzi mówiących: "Nie rób tego, chyba że wiesz co robisz". :-) – Zeth
To przesłoni ograniczenie wciskania git. Niezalecane do pracy zespołowej.Z dokumentacji git wypychania: _If ktoś zbudowany na szczycie swojej oryginalnej historii podczas przebazowania, końcówka oddziału w pilocie może przejść z nią popełnić, i ślepo popychając --force will_ ** straci pracę **. – Casey
Należy wykorzystać git pull, komenda that's zrobić git fetch a następnie wykonać git merge.
Jeśli używasz polecenia git push origin master --force, możesz mieć problemy w przyszłości.
Czy to prawda, że powinieneś używać tylko - siły, jeśli jesteś jedyną osobą w projekcie i denerwujesz się, próbując zrobić pierwsze pchnięcie? – Chrips
pull jest zawsze właściwym podejściem, ale jednym wyjątkiem może być sytuacja, gdy próbuje się przekonwertować system plików Git-a na Github. Tam musiałbyś wymusić pierwsze zatwierdzenie.
git init
git add README.md
git add .
git commit -m "first commit"
git remote add origin https://github.com/userName/repoName.git
git push --force origin master
pracuje dla mnie, zacząłem znowu nowy projekt (sam repo) i chciałem go zastąpić. – ucotta
try:
git fetch origin master
git merge origin master
Po aby napisał ten kod otrzymałem inny błąd: (non-fast-forward)
piszę ten kod:
git fetch origin master:tmp
git rebase tmp
git push origin HEAD:master
git branch -D tmp
I rozwiązał mój problem
To samo dla mnie. To rozwiązało mój problem. Istnieje kilka ostrzeżeń. Zepsułem podkatalog, ale rozwiązałem go: http://stackoverflow.com/questions/19584255/what-does-a-grey-icon-in-remote-github-mean –
Dzięki to działa dla mnie – core114
" prawdopodobne jest, że ktoś inny (np. Twój kolega) umieścił commit na origin/master, które nie znajdują się w lokalnym oddziale master i próbujesz przesłać kilka commitów z lokalnego oddziału do serwera. W 99% przypadków, zakładając, że nie chcesz wymazać swojej pracy z origin, masz dwie opcje:
2) Połącz swoje zmiany w lokalnym oddziale, a następnie popchnij scalony wynik. git checkout master git pull # resolve conflicts here git push
(Zauważ, że git pull jest zasadniczo tylko git fetch i git merge w tym przypadku.)
1) zmieniają bazę swój lokalny oddział, tak, że wygląda jak Twój kolega się ich dopuszcza, po pierwsze, a następnie dokonaniu popełnia. Dzięki temu historia zatwierdzeń jest przyjemna i liniowa - i unika "zatwierdzenia scalenia". Jeśli jednak występują konflikty ze zmianami współpracownika, być może trzeba będzie rozwiązać te konflikty dla każdego z zatwierdzeń (a nie tylko raz) w najgorszym przypadku. Zasadniczo jest to przyjemniejsze dla wszystkich, ale dla ciebie więcej wysiłku. git pull --rebase # resolve conflicts here git push
(Zauważ, że git pull --rebase jest zasadniczo git fetch i git rebase origin/master.)
Czasami zdarza się, gdy zduplikowane pliki zazwyczaj Readme rodzaju.
Można użyć następującego polecenia: Pierwszy klon świeża kopia repo, używając --mirror flag
$ git clone --mirror git://example.com/some-big-repo.git
Następnie kody odpowiednio:
Adding an existing project to GitHub using the command line
Nawet jeśli to nie zadziała, możesz po prostu wpisać kod:
$ git push origin master --force
lub
$ git push origin master -f
sam problem: D – core114