Vietos saugyklos atstatymo filialas turėtų būti kaip nuotolinė saugykla HEAD

Kaip atstatyti savo vietinį filialą atrodys kaip filialas nuotolinėje saugykloje?

Aš:

 git reset --hard HEAD 

Bet kai git status ,

 On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: java/com/mycompany/TestContacts.java modified: java/com/mycompany/TestParser.java 

Ar galėtumėte man pasakyti, kodėl aš „pakeitiau“? Negaliu paliesti šių failų? Jei tai padariau, noriu juos pašalinti.

2844
27 окт. nustatyti hap497 27 okt. 2009-10-27 03:27 '09 3:27 am 2009-10-27 03:27
@ 18 atsakymų

Filialo nustatymą tiksliai pagal nuotolinį filialą galima atlikti dviem etapais:

 git fetch origin git reset --hard origin/master 

Jei norite išsaugoti dabartinę filialo būseną prieš tai atlikdami (tik tuo atveju), galite:

 git commit -a -m "Saving my work, just in case" git branch my-saved-work 

Dabar jūsų darbas išsaugomas „mano išsaugotame darbe“ skyriuje, jei nuspręsite, kad norite jį grąžinti (arba norite jį peržiūrėti vėliau arba nukreipti į atnaujintą filialą).

Atkreipkite dėmesį, kad pirmame pavyzdyje daroma prielaida, kad nuotolinio repo pavadinimas yra „šaltinis“ ir kad nuotolinio repo filialas, pavadintas „kapitonas“, atitinka dabartinį išskleidžiamąjį filialą vietiniame repo.

Beje, ši situacija, kurioje jūs patys atrodote, atrodo labai keista, kaip įprasta atvejis, kai stumiama į dabartinę neturtingų saugyklos bandymų šaką. Ar pastaruoju metu susidomėjote savo vietine repo? Jei ne, tada nesijaudinkite - kažkas turėtų padaryti šiuos failus netikėtai keičiantis. Priešingu atveju turėtumėte žinoti, kad nerekomenduojama įterpti į ne plikas saugyklą (o ne į šiuo metu pažymėtą filialą).

5013
27 окт. Dan Molding atsakymas, spalio 27 d 2009-10-27 04:44 '09, 4:44 2009-10-27 04:44

Turėjau daryti (sprendimas priimtu atsakymu):

 git fetch origin git reset --hard origin/master 

Toliau pateikiami:

 git clean -f 
border=0

ištrinti vietinius failus

Norėdami sužinoti, kurie failai bus ištrinti (neištrindami):

 git clean -n -f 
288
27 дек. atsakymas pateikiamas Akavall, gruodžio 27 d. 2014-12-27 09:20 '14 ne 9:20 2014-12-27 09:20

Pirmiausia grįžkime prie anksčiau išgauto atitinkamo aukštesnio lygio filialo HEAD :

 git reset --hard @{u} 

Nurodant @{u} arba jo išsamią formą @{upstream} yra tas, kad nereikia aiškiai nurodyti nuotolinio repo ir filialo pavadinimo.

Tada, jei reikia, ištrinkite nepažymėtas rinkmenas, taip pat su -x :

 git clean -df 

Galiausiai, jei reikia, gauti naujausius pakeitimus:

 git pull 
165
10 февр. Atsakymą ABB pateikė vasario 10 d. 2015-02-10 23:27 '15, 23:27, 2015-02-10 23:27

git reset --hard HEAD tikrųjų iš naujo nustatoma tik į paskutinę valstybę. Šiuo atveju HEAD nurodo savo filialo HEAD.

Jei turite kelis įsipareigojimus, tai neveiks.

Tai, ką tikriausiai norite padaryti, yra iš naujo nustatyti šaltinio galvutei arba tai, ką vadinate nuotoliniu saugykla. Aš tiesiog kažką panašaus

 git reset --hard origin/HEAD 

Būkite atsargūs. Kietieji debetai negali būti lengvai atšaukti. Geriau daryti tai, ką siūlo „Dan“, ir atmesti savo pakeitimų kopiją.

97
27 окт. atsakymas, kurį pateikė Mikael Ohlson, spalio 27 d 2009-10-27 04:08 '09, 4:08 val. 2009-10-27 04:08

Visi aukščiau pateikti .gitignore pasiūlymai, bet dažnai, norėdami iš naujo nustatyti projektą, taip pat turite ištrinti net .gitignore esančius failus.

Norėdami gauti moralinį lygiavertį projekto katalogo ištrinimą ir pakartotinį klonavimą iš nuotolinio kompiuterio, atlikite šiuos veiksmus:

 git fetch git reset --hard git clean -x -d -f 

Įspėjimas : git clean -x -d -f negrįžtamas ir galite prarasti failus ir duomenis (pvz., Dalykus, kuriuos ignoravote naudodami .gitignore ).

61
23 июля '15 в 20:48 2015-07-23 20:48 Christopher Smith atsakymas liepos 15 d. 15 val. 20:48 2015-07-23 20:48

Klausime yra du klausimai:

  • kaip atstatyti vietinį filialą iki taško, kuriame yra konsolė
  • kaip išvalyti tarpinę programinę įrangą (ir galbūt darbo katalogą), todėl „ git status sako, kad nothing to commit, working directory clean.

Vienas atsakymas:

  • git fetch --prune (neprivaloma) Atnaujina nuotolinio repo momentinę nuotrauką. Kitos komandos yra tik vietos.
    git reset --hard @{upstream} Vietos šakos rodyklė, kurioje yra nuotolinio vaizdo momentinė nuotrauka, taip pat nustato šio įsipareigojimo failų indeksą ir darbo katalogą.
  • git clean -d --force Pašalina nereikalingus failus ir katalogus, kurie neleidžia git clean -d --force sakyti „darbo katalogo“.
30
31 янв. atsakymą pateikė Robert Siemer sausio 31 d 2016-01-31 04:29 '16 at 4:29 2016-01-31 04:29

Štai ką aš reguliariai susiduriu, ir apibendrinau pirmiau minėtą scenarijų „Wolfgang“ darbui su bet kuriuo filialu

Aš taip pat pridėjau kvietimą „esate tikras“ ir kai kuriuos atsiliepimus

21
09 нояб. Atsakymą pateikė Andrew Tulloch 09.11 . 2012-11-09 16:01 '12 at 4:01 pm 2012-11-09 16:01

Čia yra scenarijus, kuris automatizuoja populiariausio atsakymo pasiūlymus ... Žr. ngn-wiki.ru.site/questions/477 / ... patobulintą versiją, kuri palaiko filialus.

12
15 окт. Wolfgang Fahl atsakymas spalio 15 d 2012-10-15 11:50 '12 11:50 2012-10-15 11:50

Jei nuotolinė saugykla yra origin ir jus domina branch_name :

 git fetch origin git reset --hard origin/<branch_name> 

Be to, grįžtate į pradinę šakos pradinę dalį HEAD .

 git fetch origin git reset --hard origin/HEAD 

Kaip tai veikia:

git fetch origin atsisiunčia naujausią iš nuotolinio kompiuterio, nesistengdama sujungti ar perkelti nieko.

Tada git reset atstato <branch_name> tai, ką jūs tiesiog <branch_name> . Pasirinkimas --hard pakeičia visus jūsų darbiniame medyje esančius failus pagal failų origin/branch_name .

12
08 мая '17 в 14:12 2017-05-08 14:12 atsakymą pateikė eigenharsha gegužės 08 d. 17 d. 14 val

Aš:

 git branch -D master git checkout master 

visiškai atstatyti filialą


Atkreipkite dėmesį, kad turite pašalinti kitą filialą, kad pašalintumėte reikiamą filialą

11
14 мая '14 в 10:48 2014-05-14 10:48 atsakymą pateikė vartotojo2846569 gegužės 14 d., „14, 10:48 2014-05-14 10:48

Jei su manimi kilo problemų, kad jau atlikote kai kuriuos pakeitimus, bet dabar dėl kokios nors priežasties norite atsikratyti, greičiausias būdas yra naudoti „ git reset :

 git reset --hard HEAD~2 

Aš turėjau 2 nereikalingus pataisymus, taigi, skaičių 2. Galite jį pakeisti į savo fiksavimo numerį, kad jį iš naujo nustatytumėte.

Taigi, atsakydami į klausimą: jei prieš nuotolinį HEAD saugyklą uždirbote 5 bitus, turėtumėte paleisti šią komandą:

 git reset --hard HEAD~5 

Atminkite, kad prarasite atliktus pakeitimus, todėl būkite atsargūs!

7
16 июня '14 в 6:35 2014-06-16 06:35 atsakymą Karolis pateikė birželio 16 d. 14 val. 6:35 2014-06-16 06:35

Jei norite grįžti į HEAD būseną ir darbo katalogui, ir indeksui, turite git reset --hard HEAD , o ne HEAD^ . (Galbūt tai buvo klaidos, kaip ir vienintelis ar dvigubas brūkšnys.)

Kalbant apie konkretų klausimą, kodėl šie failai rodomi pakeistoje būsenoje, atrodo, kad jūs atlikote minkštą atstatymą vietoj kietojo atkūrimo. Dėl šios priežasties failai, kurie buvo pakeisti HEAD deklaracijoje, bus rodomi taip, tarsi jie būtų pristatyti, kuriuos tikriausiai matote čia.

5
27 окт. atsakymas, kurį pateikė Emil Sit 27 spalis. 2009-10-27 05:10 '09, 5:10 val. 2009-10-27 05:10

Ankstesni atsakymai rodo, kad atšaukimo filialas yra dabartinis filialas (išėjimas). Pastabose OP hap497 paaiškino, kad filialas yra iš tikrųjų patikrintas, tačiau tai neabejotinai reikalauja pirminis klausimas. Kadangi yra bent vienas „pasikartojantis“ klausimas, atstatymas yra visiškai priskirtas saugyklos būklei , kuri nereiškia, kad filialas yra patikrintas, yra alternatyva:

Jei „mybranch“ filialas šiuo metu nėra patikrintas, prieš iš naujo nustatydami „nuotolinio“ / „mybranch“ filialą, galite naudoti šią žemo lygio komandą :

 git update-ref refs/heads/mybranch myremote/mybranch 

Šis metodas palieka pasirinktą šaką, o darbo medis nepažeistas. Ji tiesiog perkelia „mybranch“ galvą į kitą pataisą, neatsižvelgiant į tai, kas nurodyta antrajame argumente. Tai ypač naudinga, jei keliose šakose reikia atnaujinti naujas nuotolines galvutes.

Būkite atsargūs ir naudokite gitk arba panašią priemonę, kad patikrintumėte šaltinį ir paskirties vietą. Jei atsitiktinai tai padarote dabartiniame filiale (ir git jums nepadeda), galite susipainioti, nes naujas filialo turinys neatitinka darbo medžio, kuris nepasikeitė (pataisyti, atnaujinkite filialą, kur jis buvo anksčiau).

5
25 июня '16 в 20:13 2016-06-25 20:13 atsakymą pateikė Rainer Blome , birželio 25 d. 16, 20:13 2016-06-25 20:13

Atrodo, kad jokio plovimo ir valymo kiekio nepaveikė neištrinti ir modifikuoti failai mano vietiniame git-repo (bandžiau visas aukščiau pateiktas parinktis). Mano vienintelis šios problemos sprendimas buvo atkurti vietos saugyklą ir iš naujo klonuoti jį iš nuotolinio kompiuterio.

Laimei, neturėjau kitų šakų, apie kurias aš rūpinčiau.

xkcd: Git

3
01 дек. Atsakymas yra Martin 01. Dec 2016-12-01 13:25 '16 at 1:25 pm 2016-12-01 13:25

Tai aš reguliariai naudoju:

 git fetch upstream master; git reset --hard upstream/master; git clean -d --force; 

Atkreipkite dėmesį, kad gera praktika nekeisti vietinio kapitono, o vietoj to, kad pakeistumėte kitą filialą, pakeiskite filialo pavadinimą, prieš kurį pasikeičia, pvz., feat/ , chore/ , fix/ ir kt. Taigi, jums reikia tik keisti pokyčius, o ne daryti jokių vedlio pakeitimų. Tas pats pasakytina ir apie kitas pramonės šakas, kurias skatina kiti. Taigi aukščiau paminėta informacija turėtų būti naudojama tik tuo atveju, jei įrašėte filialo pakeitimus, kuriuose yra kitų įsipareigojimų, ir jums reikia atlikti iš naujo. Priešingu atveju, ateityje venkite paspaudimo ant šakos, į kurią kiti stumia, o pašalinkite ir perkelkite į nurodytą šaką per išgautą šaką.

Jei norite atstatyti vietinį filialą į paskutinį įvykį kylančiojo filialo filiale, jis vis dar veikia man:

Patikrinkite savo konsoles, įsitikinkite, kad išeinantis ir šaltinio kodas atitinka jūsų lūkesčius, jei ne taip, kaip tikėtasi, naudokite git remote add upstream <insert URL> , pvz. git remote add origin <insert URL of the forked GitHub repo> .

 git remote --verbose git checkout develop; git commit -m "Saving work."; git branch saved-work; git fetch upstream develop; git reset --hard upstream/develop; git clean -d --force 

„GitHub“ taip pat galite išgauti filialą, turintį tą patį pavadinimą kaip ir vietinis, kad išsaugotumėte darbą ten, nors tai nėra būtina, jei kilmės plėtra turi tuos pačius pokyčius kaip vietinis išsaugoto darbo padalinys. Kaip pavyzdį naudoju vystymosi filialą, bet tai gali būti bet koks esamas šakos pavadinimas.

 git add . git commit -m "Reset to upstream/develop" git push --force origin develop 

Tada, jei reikia sujungti šiuos pakeitimus su kitu filialu, kai yra konfliktų, taupydami pakeitimus, naudokite:

 git merge -s recursive -X theirs develop 

Naudojimo metu

 git merge -s recursive -X ours develop 

išsaugoti prieštaringus pakeitimus „branch_name“. Priešingu atveju naudokite mergetool su git mergetool .

Su visais pakeitimais:

 git commit -m "Saving work."; git branch saved-work; git checkout develop; git fetch upstream develop; git reset --hard upstream/develop; git clean -d --force; git add .; git commit -m "Reset to upstream/develop"; git push --force origin develop; git checkout branch_name; git merge develop; 

Atkreipkite dėmesį, kad vietoj „upstream“ ir (arba) kūrimo galite naudoti įvykdymą, kitą šakos pavadinimą ir kt Naudokite „CLI“ įrankį, pvz., „Oh My Zsh“, kad patikrintumėte, ar filialas yra žalias, nurodydamas, kad nieko nėra, ir darbo katalogas yra švarus (kaip patvirtinta arba patvirtinta git status ). Atkreipkite dėmesį, kad tai iš tikrųjų gali pridėti įsipareigojimus, lyginant su plėtra aukštesnėje grandinėje, jei kažkas automatiškai pridedama pagal įvykį, pvz., UML diagramas, licencijų antraštes ir tt, todėl šiuo atveju jūs galite ištraukti pakeitimus į origin develop , jei reikia, vėliau.

1
26 апр. James Ray atsakymas, pateiktas balandžio 26 d 2018-04-26 04:30 '18, 4:30 2018-04-26 04:30

Vienintelis sprendimas, kuris veikia visais atvejais, kuriuos aš mačiau, yra šalinimas ir pakartotinis naudojimas. Galbūt yra ir kitas būdas, tačiau, žinoma, tokiu būdu nesuteikiama galimybė likti ta pačia būsena, todėl norėčiau, kad tai būtų. Bash vieną linijinę liniją, kurią galite nustatyti kaip makrokomandą, jei dažnai pasitaiko dalykų:

 REPO_PATH=$(pwd)  GIT_URL=$(git config --get remote.origin.url)  cd ..  rm -rf $REPO_PATH  git clone --recursive $GIT_URL $REPO_PATH  cd $REPO_PATH 

* mano, kad jūsų .git failai yra nepažeisti

0
14 сент. atsakymas pateikiamas sudo 14 sep. 2017-09-14 22:28 '17 bent 22:28 pm 2017-09-14 22:28

Jei nenorite išsaugoti vietinių pakeitimų, bet vis tiek norite atnaujinti savo saugyklą, kad ji atitiktų kilmę / HEAD, galite tiesiog nukopijuoti vietinius pakeitimus ir vilkite:

 git stash git pull 
-3
10 сент. Atsakymas, kurį pateikė Micah Walter Sep 10 2014-09-10 16:49 '14 at 16:49 2014-09-10 16:49

Jei norite, kad dabartiniai pakeitimai būtų naudojami vėliau, tada paslėpti pakeitimus, kitus išmintingus, kuriuos galite naudoti šiomis dviem komandomis:

 git fetch origin git reset --hard origin/master 
-7
04 нояб. atsakymas pateikiamas Sarang A 04 Nov. 2014-11-04 14:13 '14, 14:13 2014-11-04 14:13

Kiti klausimai apie žymes arba Užduoti klausimą