Як змусити перезаписати локальні файли на a git pull?

Сценарій такий:

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

Це помилка, яку я отримую:

Помилка: Файл "public / images / icon.gif" не відстежуваного робочого дерева буде замінено об'єднанням

Як змусити Git перезаписати їх? Людина є дизайнером - зазвичай я вирішую всі конфлікти вручну, тому сервер має найновішу версію, яку їм просто потрібно оновити на своєму комп’ютері.

Важливо: Якщо у вас є якісь локальні зміни, вони будуть втрачені. З --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

Спробуйте це:

git reset --hard HEAD
git pull

Він повинен робити те, що ти хочеш.

ПОПЕРЕДЖЕННЯ: git cleanвидаляє всі ваші непотрібні файли / каталоги і їх не можна скасувати.

Іноді просто clean -fне допомагає. У випадку, якщо у вас немає відібраних ДИРЕКТОРІЙ, також потрібен варіант -d:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull

ПОПЕРЕДЖЕННЯ: git cleanвидаляє всі ваші непотрібні файли / каталоги і їх не можна скасувати.

Спершу подумайте про використання прапора -n( --dry-run). Це покаже, що буде видалено, фактично нічого не видаляючи:

git clean -n -f -d

Приклад виводу:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...

Як і Їжак, я думаю, що відповіді жахливі. Але хоч відповідь Їжака може бути кращою, я не думаю, що це настільки елегантно, як могло б бути. Я знайшов це зробити, використовуючи "отримання" та "злиття" із визначеною стратегією. Що повинно зробити так, щоб ваші локальні зміни зберігалися до тих пір, поки вони не є одним із файлів, з якими ви намагаєтесь змусити перезаписати.

Спочатку виконайте свої зміни

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

Потім виберіть зміни та перезапишіть, якщо є конфлікт

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

"-X" - це назва опції, а "njihovo" - значення для цього параметра. Ви вирішили використовувати "їх" зміни, а не "ваші" зміни, якщо є конфлікт.

Замість того, щоб робити:

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

Я б радив зробити наступне:

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

Немає необхідності отримувати всі віддалені та гілки, якщо ви збираєтеся скинутись на початкову / головну гілку?

Схоже, найкраще спочатку зробити:

git clean

Щоб видалити всі незаймані файли, а потім продовжити звичайне git pull...

Попередження, якщо це буде назавжди видалено ваші файли, якщо у вашому файлі gitignore у вас є якісь записи каталогу / *.

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

Швидше (git> 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}

Ця команда може бути корисною для викидання локальних змін:

git checkout <your-branch> -f

А потім зробіть очищення (видаляє незатребувані файли з робочого дерева):

git clean -f

Якщо ви хочете видалити незатрековані каталоги на додаток до файлів, що не відслідковуються:

git clean -fd

Замість того, щоб зливатися git pull, спробуйте:

git fetch --all

далі:

git reset --hard origin/master.

Єдине, що для мене працювало:

git reset --hard HEAD~5

Це поверне вам п’ять комітетів і потім з

git pull

Я виявив, що, шукаючи, як скасувати об'єднання Git .

Проблема з усіма цими рішеннями полягає в тому, що всі вони або занадто складні, або, що ще більша проблема полягає в тому, що вони видаляють усі незатребувані файли з веб-сервера, чого ми не хочемо, оскільки завжди потрібні файли конфігурації, які перебувають на на сервері, а не у сховищі Git.

Ось найчистіше рішення, яке ми використовуємо:

# Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull

• Перша команда отримує новітні дані.

• Друга команда перевіряє, чи є якісь файли, які додаються до сховища, і видаляє ті незатребувані файли з локального сховища, які могли б викликати конфлікти.

• Третя команда перевіряє всі файли, які були локально модифіковані.

• Нарешті ми робимо тягнення до оновлення до новітньої версії, але на цей раз без будь-яких конфліктів, оскільки відслідковуваних файлів, які знаходяться в репо, вже не існує, а всі локально модифіковані файли вже такі, як у сховищі.

Перш за все, спробуйте стандартним способом:

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 (excempt .git/dir, де у вас є всі коміти) та знову витягніть їх.

Чому git reset HEAD --hardв деяких випадках може статися збій?

1. Спеціальні правила в .gitattributes file

   Маючи eol=lf владу в .gitattributes може привести до мерзотник , щоб змінити деякі зміни файлів шляхом перетворення CRLF завершень рядків в LF в деяких текстових файлах.

   Якщо це так, ви повинні здійснити ці зміни CRLF / LF (переглянувши їх у git status) або спробувати: git config core.autcrlf falseтимчасово їх ігнорувати.

2. Незмінність файлової системи

   Коли ви використовуєте файлову систему, яка не підтримує атрибути дозволу. У прикладі у вас є два сховища, одне на Linux / Mac ( ext3/ hfs+) та інше у файловій системі на базі FAT32 / NTFS.

   Як ви зауважуєте, існує два різних файлових системи, тому одна, яка не підтримує дозволи Unix, в основному не може скинути дозволи файлів у системі, яка не підтримує такі дозволи, тому незалежно від того, як --hardви намагаєтеся, git завжди виявляйте якісь "зміни".

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

Я вирішив це:

1. Видаліть усі файли. Залиште лише .gitкаталог.
2. git reset --hard HEAD
3. git pull
4. git push

Зараз це працює.

Бонус:

Говорячи про тягнення / отримання / злиття в попередніх відповідях, я хотів би поділитися цікавим і продуктивним трюком,

git pull --rebase

Ця вище команда - найкорисніша команда в моєму житті Git, яка зекономила багато часу.

Перед тим, як натиснути ваш щойно приєднаний сервер, спробуйте цю команду, і вона автоматично синхронізує останні зміни на сервері (з вилученням і злиттям) і помістить ваш комітет вгорі в журналі Git. Не потрібно турбуватися про ручне потягування / злиття.

Дізнайтеся деталі в тому, що робить "git pull --rebase"? .

У мене була схожа проблема. Мені довелося це зробити:

git reset --hard HEAD
git clean -f
git pull

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

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

Попередження : Цей сценарій дуже потужний, тому ви можете втратити свої зміни.

Виходячи з мого власного подібного досвіду, рішення, яке пропонував Страхіня Кустудіч вище, є на сьогодні найкращим. Як зазначали інші, просто виконувати жорсткий перезавантаження видалить усіх незафіксовані файли, які можуть включати багато речей, які ви не хочете видаляти, наприклад файли конфігурації. Що безпечніше - видалити лише ті файли, які збираються додати, і, з цього приводу, ви, ймовірно, також захочете перевірити будь-які локально модифіковані файли, які збираються оновити.

Маючи на увазі, я оновив сценарій Кустудіка, щоб зробити саме це. Я також виправив друкарську помилку (відсутній 'в оригіналі).

#/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull

Я вважаю, що існують дві можливі причини конфлікту, які треба вирішувати окремо, і наскільки я можу сказати, жодна з наведених відповідей не стосується обох:

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

• Місцеві комісії, які не знаходяться на віддаленій гілці, також потрібно видалити. IMO найпростіший спосіб досягти цього: git reset --hard origin/master(замініть "master" на будь-яку галузь, над якою ви працюєте, та запустіть git fetch originпершу)

Простішим способом було б:

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

Це замінить ваш локальний файл із файлом на git

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

На основі поєднання відповіді РНКА і відповідь Торека до подібного питання , я придумав це , який працює відмінно:

git fetch
git reset --hard @{u}

Запустіть це з гілки, і вона скине лише вашу локальну гілку до версії за потоком.

Це також можна вписати в git псевдонім ( git forcepull):

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

Або у вашому .gitconfigфайлі:

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

Насолоджуйтесь!

У мене була така ж проблема, і чомусь навіть це git clean -f -dне зробило б. Ось чому: З якоїсь причини, якщо ваш файл ігнорується Git (через запис .gitignore, я вважаю), він все ще турбується про те, щоб перезаписати це з наступним витягненням , але чистий не видалить його, якщо ви не додасте -x.

Я знаю набагато простіший і менш болісний метод:

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

Це воно!

Я просто вирішив це самостійно:

git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp

де остання команда дає список того, якими були ваші локальні зміни. Продовжуйте змінювати гілку "tmp" до тих пір, поки вона не стане прийнятною, а потім з’єднайтеся назад на головний з:

git checkout master && git merge tmp

Наступного разу ви, ймовірно, можете впоратися з цим більш чистим способом, переглянувши "гілку прихованої гілки", хоча приклад, ймовірно, спричинить вам проблеми в перші кілька спроб, тому зробіть перший експеримент на некритичному проекті ...

У мене дивна ситуація , що ні git cleanабо git resetроботи. Мені потрібно видалити конфліктуючий файл git index, використовуючи наступний скрипт у кожному нерозробленому файлі:

git rm [file]

Тоді я вмію тягнути просто чудово.

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

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

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

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.

Ці чотири команди працюють на мене.

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

Щоб перевірити / потягнути після виконання цих команд

git pull origin master

Я багато пробував, але нарешті мав успіх у цих командах.

Просто роби

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

Таким чином ви уникаєте всіх небажаних побічних ефектів, як-от видалення файлів або каталогів, які ви хотіли зберегти тощо.

Скиньте індекс та голову на origin/master, але не скидайте робоче дерево:

git reset origin/master

Вимоги:

1. Відслідковуйте локальні зміни, щоб ніхто їх ніколи не втрачав.
2. Зробіть так, щоб локальне сховище відповідало віддаленому сховищу.

Рішення:

1. Приховуйте локальні зміни.

2. Принесіть з чистим з файлів і каталогів , які ігнорують .gitignore і жорсткий скидання до походженням .

   git stash --include-untracked
   git fetch --all
   git clean -fdx
   git reset --hard origin/master