Як прымусіць "git pull" перазапісаць лакальныя файлы?

Як прымусова перазапісаць лакальныя файлы ў git pull ?

Сцэнар наступны:

  • Член каманды мадыфікуе шаблоны для сайта, над якім мы працуем
  • Яны дадаюць некаторыя выявы ў каталог малюнкаў (але забываюць дадаць іх пад кантролем зыходнага кода)
  • Яны адпраўляюць выявы па пошце, пазней, мне
  • Я дадаю малюнка пад кантроль зыходнага кода і змяшчаю іх у GitHub разам з іншымі зменамі.
  • Яны не могуць атрымліваць абнаўлення з GitHub, таму што Git не жадае перазапісваць свае файлы.

Гэта памылка, якую я атрымліваю:

памылка: неотслеживаемый файл працоўнага дрэва 'public / images / icon.gif' будзе перазапісаны зліццём

Як прымусіць Git перазапісаць іх? Гэты чалавек дызайнер. Звычайна я дазваляю ўсе канфлікты ўручную, таму на серверы ўсталяваная самая апошняя версія, якую ім проста неабходна абнавіць на сваім кампутары.

5705
14 июля '09 в 17:58 2009-07-14 17:58 зададзены Jakub Troszok 14 ліпеня '09 ў 17:58 2009-07-14 17:58
@ 39 адказаў
  • 1
  • 2

Важна: калі ў вас ёсць якія-небудзь лакальныя змены, яны будуць страчаныя. З опцыяй --hard або без --hard ўсе лакальныя камітаў, якія не былі перададзеныя, будуць страчаныя. [*]

Калі ў вас ёсць файлы, якія не адсочваюцца Git (напрыклад, загружаны карыстацкі кантэнт), гэтыя файлы не будуць закрануты.


Я думаю, што гэта правільны шлях:

 git fetch --all 

Тады ў вас ёсць два варыянты:

 git reset --hard origin/master 

АБО Калі вы знаходзіцеся ў іншай галінцы:

 git reset --hard origin/<branch_name> 

тлумачэнне:

git fetch загружае апошнія дадзеныя з аддаленага кампутара, не спрабуючы аб'яднаць або перамясціць што-небудзь.

Затым git reset скідае асноўную галіну да таго, што вы толькі што атрымалі. Опцыя --hard змяняе ўсе файлы ў вашым працоўным дрэве ў адпаведнасці з файламі ў origin/master


Падтрымліваць бягучыя лакальныя камітаў

[*]: Варта адзначыць, што можна захаваць бягучыя лакальныя камітаў, стварыўшы галінку ад master да скіду:

 git checkout master git branch new-branch-to-save-current-commits git fetch --all git reset --hard origin/master 

Пасля гэтага ўсе старыя камітаў будуць захоўвацца ў new-branch-to-save-current-commits .

незавершаныя змены

Аднак незафіксаваных змены (нават паэтапныя) будуць страчаныя. Пераканайцеся, што вы схавалі і перадалі ўсе, што вам трэба Для гэтага вы можаце запусціць наступнае:

 git stash 

А затым паўторна ўжыць гэтыя незафіксаваных змены:

 git stash pop 
7980
17 янв. адказ дадзены RNA 17 студз. 2012-01-17 03:02 '12 у 03:02 2012/01/17 03:02

Паспрабуйце наступнае:

 git reset --hard HEAD git pull 
border=0

Ён павінен рабіць тое, што вы хочаце.

798
09 мая '10 в 22:45 2010-05-09 22:45 адказ дадзены Travis Reeder 09 мая '10 а 22:45 2010-05-09 22:45

УВАГА: git clean выдаляе ўсе вашыя неотслеживаемые файлы / каталогі і не можа быць адменены.


Часам проста clean -f не дапамагае. Калі ў вас няма адсочваных каталогаў, опцыя -d таксама неабходная:

 # WARNING: this can't be undone! git reset --hard HEAD git clean -f -d git pull 

УВАГА: git clean выдаляе ўсе вашыя неотслеживаемые файлы / каталогі і не можа быць адменены.

Паспрабуйце -n выкарыстоўваць -n ( --dry-run ). Гэта пакажа вам, што будзе выдалена, фактычна нічога не выдаляючы:

 git clean -n -f -d 

Прыклад высновы:

 Would remove untracked-file-1.txt Would remove untracked-file-2.txt Would remove untracked/folder ... 
406
19 марта '11 в 12:10 2011-03-19 12:10 адказ дадзены David Avsajanishvili 19 сакавіка '11 у 12:10 2011-03-19 00:10

Як Вожык, я думаю, што адказы жудасныя. Але хоць адказ Hedgehog можа быць лепш, я не думаю, што ён такі ж вытанчаны, як можа быць. Спосаб, якім я знайшоў гэта, - выкарыстоўваць "выбарку" і "зліццё" з пэўнай стратэгіяй. Гэта павінна зрабіць так, каб вашыя лакальныя змены захоўваліся да таго часу, пакуль яны не з'яўляюцца адным з файлаў, якія вы спрабуеце прымусова перазапісаць.

Спачатку зрабіце фіксацыю змяненняў

  git add * git commit -a -m "local file server commit message" 

Затым выміце змены і перезапишите, калі ёсць канфлікт

  git fetch origin master git merge -s recursive -X theirs origin/master 

"- X" - гэта імя опцыі, а "theirs" - значэнне для гэтай опцыі. Вы аддаеце перавагу выкарыстоўваць "свае" змены замест "вашых" змен, калі ёсць канфлікт.

347
11 апр. адказ дадзены Richard Kersey 11 крас. 2012-04-11 23:13 '12 у 23:13 2012-04-11 23:13

Замест гэтага:

 git fetch --all git reset --hard origin/master 

Я б параіў зрабіць наступнае:

 git fetch origin master git reset --hard origin/master 

Не трэба браць ўсе пульты і галінкі, калі вы ідзяце на reset у галінку origin / master справа?

248
26 апр. адказ дадзены Johanneke 26 крас. 2013-04-26 16:48 '13 у 16:48 2013/04/26 16:48

Падобна на тое, што лепш за ўсё зрабіць гэта:

 git clean 

Каб выдаліць усе невыкарыстоўваныя файлы, а затым працягнуць з звычайным git pull ...

125
14 июля '09 в 18:16 2009-07-14 18:16 адказ дадзены Jakub Troszok 14 ліпеня '09 ў 18:16 2009-07-14 18:16

Увага, гэта назаўжды выдаліць вашы файлы, калі ў вас ёсць якія-небудзь запісы каталога / * ў вашым файле gitignore.

Некаторыя адказы здаюцца жудаснымі. Жахліва у сэнсе таго, што здарылася з @Lauri, вынікаючы прапанове Давіда Авсаджанишвили.

Хутчэй (мярзотнік> v1.7.6):

 git stash --include-untracked git pull 

Пазней вы можаце ачысціць схованку гісторыі.

Ўручную, адзін за адным:

 $ git stash list stash@{0}: WIP on <branch>: ... stash@{1}: WIP on <branch>: ... $ git stash drop stash@{0} $ git stash drop stash@{1} 

Жорстка, усё адразу:

 $ git stash clear 

Вядома, калі вы хочаце вярнуцца да таго, што вы схавалі:

 $ git stash list ... $ git stash apply stash@{5} 
102
12 февр. адказ дадзены Hedgehog 12 февр. 2012-02-12 02:00 '12 ў 2:00 2012-02-12 02:00

Вы можаце знайсці гэтую каманду карыснай для выдалення лакальных змен:

 git checkout <your-branch> -f 

І затым выканаеце ачыстку (выдаляе неапрацаваныя файлы з працоўнага дрэва):

 git clean -f 

Калі вы хочаце выдаліць непатрэбныя каталогі ў дадатак да файлаў без следу:

 git clean -fd 
88
05 авг. адказ дадзены Vishal 05 жнів. 2010-08-05 21:06 '10 а 21:06 2010-08-05 21:06

Замест зліцця з git pull паспрабуйце гэта:

git fetch --all

з наступным:

git reset --hard origin/master .

81
22 нояб. адказ дадзены Lloyd Moore 22 лістапада. 2012-11-22 13:56 '12 у 13:56 2012/11/22 13:56

Адзінае, што спрацавала для мяне, было:

 git reset --hard HEAD~5 

Гэта верне вам пяць камітаў, а затым

 git pull 

Я выявіў, што, паглядзеўшы як адмяніць Git merge .

54
06 мая '11 в 0:53 2011-05-06 00:53 адказ дадзены Chris BIllante 06 мая '11 у 0:53 2011-05-06 00:53

Праблема з усімі гэтымі рашэннямі заключаецца ў тым, што яны ўсё альбо занадта складаныя, альбо яшчэ больш сур'ёзная праблема заключаецца ў тым, што яны выдаляюць усё неапрацаваныя файлы з вэб-сервера, чаго мы не хочам, паколькі заўсёды патрабуюцца файлы канфігурацыі якія знаходзяцца на сэрвэры , а не ў рэпазітары Git.

Вось самае чыстае рашэнне, якое мы выкарыстоўваем:

51
06 нояб. адказ дадзены Strahinja Kustudic 06 лістапада. 2012-11-06 02:32 '12 у 02:32 2012/11/06 02:32

У мяне такая ж праблема. Ніхто не даў мне гэтае рашэнне, але яно спрацавала для мяне.

Я вырашыў гэта:

  1. Выдаліць усе файлы. Пакіньце толькі каталог .git .
  2. git reset --hard HEAD
  3. git pull
  4. git push

Зараз гэта працуе.

38
13 янв. адказ дадзены John John Pichler 13 студз. 2011-01-13 02:58 '11 у 02:58 2011-01-13 02:58

Перш за ўсё, паспрабуйце стандартны спосаб:

 git reset HEAD --hard # To remove all not committed changes! git clean -fd # To remove all untracked (non-git) files and folders! 

Папярэджанне: вышэйпаказаныя каманды могуць прывесці да страты даных / файлаў, толькі калі яны не зафіксаваныя! Калі вы не ўпэўненыя, спачатку зрабіце рэзервовую копію ўсёй вашай папкі рэпазітара.

Тады пацягніце гэта зноў.

Калі вышэйпералічанае не дапаможа і вам не патрэбныя вашы неотслеживаемые файлы / каталогі (на ўсялякі выпадак зрабіце рэзервовую копію спачатку), паспрабуйце выканаць наступныя простыя крокі:

 cd your_git_repo # where 'your_git_repo' is your git repository folder rm -rfv * # WARNING: only run inside your git repository! git pull # pull the sources again 

Гэта выдаліць усе файлы git (за выключэннем .git/ dir, дзе ў вас ёсць усе камітаў) і выме яго зноў.


Чаму git reset HEAD --hard можа не працаваць у некаторых выпадках?

  1. Прыстасаваныя правілы ў .gitattributes file

    Наяўнасць правілы EOL eol=lf ў .gitattributes можа прывесці да таго, што git зменіць некаторыя змены файлаў, пераўтварыўшы заканчэння радкоў CRLF ў LF ў некаторых тэкставых файлах.

    Калі гэта так, вы павінны зафіксаваць гэтыя змены CRLF / LF (прагледзеўшы іх у git status ) або паспрабуйце: git config core.autcrlf false каб часова ігнараваць іх.

  2. Несумяшчальнасць файлавай сістэмы

    Калі вы карыстаецеся файлавую сістэму, якая не падтрымлівае атрыбуты дазволаў. Напрыклад, у вас ёсць два рэпазітара, адзін для Linux / Mac ( ext3 / hfs+ ) і іншы для файлавай сістэмы на аснове FAT32 / NTFS.

    Як вы заўважылі, існуе два розных тыпы файлавых сістэм, таму тая, якая не падтрымлівае дазволу Unix, у асноўным не можа скінуць дазволу для файлаў у сістэме, якая не падтрымлівае такія дазволы, таму незалежна ад таго, як --hard вы паспрабуйце, git заўсёды выяўляе некаторыя "змены".

33
26 окт. адказ дадзены kenorb 26 каст. 2012-10-26 12:17 '12 у 12:17 2012/10/26 00:17

бонус:

Гаворачы аб pull / fetch / merge ў папярэдніх адказах, я хацеў бы падзяліцца цікавым і прадуктыўным прыёмам:

git pull --rebase

Гэтая каманда з'яўляецца самай карыснай камандай у маім жыцці ў Git, якая зэканоміла шмат часу.

Перад адпраўкай вашага новага камітаў на сервер, паспрабуйце гэтую каманду, і яна аўтаматычна сінхранізуе апошнія змены сервера (з выбаркай + зліццём) і змесціць ваш комм наверсе ў часопісе Git. Няма неабходнасці турбавацца аб ручным выманні / зліцці.

Знайсці дэталі ў Што робіць "git pull --rebase"? ,

31
23 дек. адказ дадзены Sazzad Hissain Khan 23 снеж. 2015-12-23 18:41 '15 у 18:41 2015/12/23 18:41

Я абагульніў іншыя адказы. Вы можаце выканаць git pull без памылак:

 git fetch --all git reset --hard origin/master git reset --hard HEAD git clean -f -d git pull 

Папярэджанне. Гэты script вельмі магутны, таму вы можаце страціць свае змены.

27
07 авг. адказ дадзены Robert Moon 07 жнів. 2015-08-07 06:03 '15 у 06:03 2015/08/07 06:03

У мяне была аналагічная праблема. Я павінен быў зрабіць гэта:

 git reset --hard HEAD git clean -f git pull 
27
14 янв. адказ дадзены Ryan 14 студз. 2011-01-14 18:18 '11 у 18:18 2011-01-14 18:18

Грунтуючыся на маіх уласных падобных досведах, рашэнне, прапанаванае Strahinja Kustudic вышэй, з'яўляецца безумоўна лепшым. Як адзначалі іншыя, проста выкананне жорсткага reset выдаліць усё не правераныя файлы, якія могуць ўключаць у сябе мноства рэчаў, якія вы не хочаце выдаляць, напрыклад, файлы канфігурацыі. Што больш бяспечна, трэба выдаліць толькі файлы, якія павінны быць дададзены, і, у гэтых адносінах, вы, верагодна, таксама захочаце праверыць любыя лакальна мадыфікаваныя файлы, якія павінны быць абноўлены.

Менавіта таму я абнавіў Kustudic script, каб зрабіць менавіта гэта. Я таксама выправіў памылку друку (адсутнічае ў арыгінале).

26
27 февр. адказ дадзены Rolf Kaiser 27 февр. 2013-02-27 17:43 '13 у 17:43 2013/02/27 17:43

Я лічу, што ёсць дзве магчымыя прычыны канфлікту, якія трэба вырашаць асобна, і наколькі я магу судзіць, ні адзін з вышэйпералічаных адказаў не мае дачынення да абодвух:

  • Лакальныя файлы, якія не адсочваюцца, павінны быць выдаленыя ўручную (бяспечней) або, як прапанавана ў іншых адказах, на git clean -f -d

  • Лакальныя камітаў, якiя не знаходзяцца ў выдаленай галінцы, таксама павінны быць выдаленыя. ИМО - самы просты спосаб дамагчыся гэтага: git reset --hard origin/master (заменіце "майстар" любы галінкай, над якой вы працуеце, і спачатку запусціце git fetch origin )

23
12 дек. адказ дадзены tiho 12 снеж. 2011-12-12 22:54 '11 а 22:54 2011-12-12 22:54

Больш просты спосаб:

 git checkout --theirs /path/to/file.extension git pull origin master 

Гэта перавызначыць ваш лакальны файл з файлам на git

20
05 мая '15 в 11:03 2015-05-05 11:03 адказ дадзены maximus 69 05 мая '15 у 11:03 2015/05/05 11:03

Здаецца, што большасць адказаў тут засяроджана на галінцы master ; аднак часам бываюць выпадкі, калі я працую над адной і той жа галіной функцый у двух розных месцах, і я хачу, каб у адной з іх адна з іх адбівалася ў іншы, без вялікай колькасці скачкоў праз абручы.

Грунтуючыся на спалучэнні адказу РНК і адказ torek на аналагічнае пытанне , я прыйшоў з цудоўнай працай:

 git fetch git reset --hard @{u} 

Запусціце гэта з галінкі, і яна будзе толькі reset вашай лакальнай галіной у ўзыходзячую версію.

Гэта можа быць зручна змешчана ў псеўданім git ( git forcepull ):

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

Або ў файле .gitconfig :

 [alias] forcepull = "!git fetch ; git reset --hard @{u}" 

Атрымлівайце асалоду ад!

19
25 февр. адказ дадзены JacobEvelyn 25 февр. 2014-02-25 20:19 '14 у 20:19 2014/02/25 20:19

У мяне была такая ж праблема, і па нейкай прычыне нават git clean -f -d не зрабiў бы гэтага. А вось чаму: Па нейкай прычыне, калі ваш файл ігнаруецца Git (праз запіс .gitignore, я мяркую), ён па-ранейшаму турбуецца аб тым, каб перазапісаць гэта з наступным адключэннем, але чысты не выдаліць яго, калі толькі вы дадайце -x .

19
03 авг. адказ дадзены Tierlieb 03 жнів. 2011-08-03 12:23 '11 у 12:23 2011-08-03 00:23

Я проста вырашыў гэта сам:

18
03 дек. адказ дадзены Simon B. 03 снеж. 2010-12-03 18:00 '10 а 18:00 2010-12-03 18:00

У мяне дзіўная сітуацыя, што ні git clean ні git reset працуюць. Я павінен выдаліць канфлікт файлаў з git index , выкарыстоўваючы наступны скрыпт для кожнага неотслеживаемого файла:

 git rm [file] 

Тады я магу цягнуць проста выдатна.

17
19 сент. адказ дадзены Chen Zhang 19 сент. 2011-09-19 17:18 '11 у 17:18 2011-09-19 17:18

Я ведаю значна больш просты і менш балючы метад:

 $ git branch -m [branch_to_force_pull] tmp $ git fetch $ git checkout [branch_to_force_pull] $ git branch -D tmp 

Гэта!

16
05 сент. адказ дадзены ddmytrenko 05 сент. 2015-09-05 21:23 '15 а 21:23 2015/09/05 21:23

Гэтыя чатыры каманды працуюць для мяне.

 git reset --hard HEAD git checkout origin/master git branch -D master git checkout -b master 

Каб праверыць / выцягнуць пасля выканання гэтых каманд

 git pull origin master 

Я шмат спрабаваў, але, нарэшце, дамогся поспеху ў гэтых камандах.

13
20 марта '14 в 7:24 2014-03-20 07:24 адказ дадзены vishesh chandra 20 сакавіка '14 у 07:24 2014/03/20 07:24

Нягледзячы на ​​зыходны пытанне, верхнія адказы могуць выклікаць праблемы для людзей, у якіх ёсць аналагічная праблема, але не хочуць страціць свае лакальныя файлы. Напрыклад, гл. Каментары Al-Punk і crizCraig.

Наступная версія фіксуе вашы лакальныя змены ў часовай галінцы ( tmp ), правярае зыходную галіна (якая, як я мяркую, master ), і аб'ядноўвае абнаўлення. Вы можаце зрабіць гэта з дапамогай stash , але я знайшоў, што звычайна прасцей проста выкарыстоўваць падыход branch / merge.

 git checkout -b tmp git add *; git commit -am "my temporary files" git checkout master git fetch origin master git merge -s recursive -X theirs origin master 

дзе мы мяркуем, што іншы рэпазітар - origin master .

12
22 окт. адказ дадзены Snowcrash 22 каст. 2014-10-22 20:31 '14 у 20:31 2014/10/22 20:31

проста зрабі

 git fetch origin branchname git checkout -f origin/branchname // This will overwrite ONLY new included files git checkout branchname git merge origin/branchname 

Такім чынам, вы пазбягаеце усіх непажаданых пабочных эфектаў, такіх як выдаленне файлаў або каталогаў, якія вы хацелі захаваць, і г.д.

12
19 окт. адказ дадзены user2696128 19 каст. 2015-10-19 12:54 '15 у 12:54 2015/10/19 00:54

Reset ўказальнік і head на origin/master , але не reset працоўнае дрэва:

 git reset origin/master 
11
15 февр. адказ дадзены user811773 15 февр. 2013-02-15 16:41 '13 у 16:41 2013/02/15 16:41

патрабаванні:

  • Адсочвайце лакальныя змены, таму ніхто не губляе іх.
  • Зрабіць лакальны рэпазітар сумесным з рэпазітаром аддаленага крыніцы.

рашэнне:

  • Схаваць лакальныя змены.
  • Атрымаць з чыстай файламі і , Ігнаруючы .gitignore і жорсткі reset ў паходжанне.

     git stash --include-untracked git fetch --all git clean -fdx git reset --hard origin/master 
9
02 сент. адказ дадзены vezenkov 02 сент. 2015-09-02 02:00 '15 ў 2:00 2015/09/02 02:00

Я прачытаў усе адказы, але я шукаў адну каманду для гэтага. Вось што я зрабіў. Дададзены псеўданім git ў .gitconfig

 [alias] fp = "!f(){ git fetch ${1} ${2}  git reset --hard ${1}/${2};};f" 

запусціце каманду

 git fp origin master 

эквівалентна

 git fetch origin master git reset --hard origin/master 
9
08 июля '16 в 16:11 2016-07-08 16:11 адказ дадзены Venkat Kotra 08 ліпеня '16 ў 16:11 2016/07/08 16:11
  • 1
  • 2

Іншыя пытанні па пазнаках або Задайце пытанне