Git: Як видалити файл з індексу без видалення файлів із будь-якого сховища

Коли ви використовуєте

git rm --cached myfile

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

Чи є спосіб просто видалити файл з версії, не видаляючи його з жодної файлової системи?

Редагувати: Пояснено, сподіваюся.

Я не думаю, що фіксація Git може записати намір, наприклад "припинити відстежувати цей файл, але не видаляти його".

Якщо ввести такий намір, зажадає втручання поза Git в будь-які сховища, які об'єднують (або перезавантажують) комісію, яка видаляє файл.

Збережіть копію, застосуйте видалення, відновлення

Напевно, найпростіше зробити це сказати своїм нижчим користувачам зберегти копію файлу, витягнути видалення та відновити файл. Якщо вони перетягуються через ребазу та вносять зміни до файлу, у них виникнуть конфлікти. Щоб вирішити такі конфлікти, використовуйте git rm foo.conf && git rebase --continue(якщо суперечлива комісія має зміни, крім змін у вилученому файлі), або git rebase --skip(якщо суперечлива фіксація змінилася лише на видалений файл).

Відновіть файл як невиправлений після витягування комітету, який його видаляє

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

git show @{1}:foo.conf >foo.conf

Або з git checkout (за коментарем Вільяма Перселя; але не забудьте знову видалити його з індексу!):

git checkout @{1} -- foo.conf && git rm --cached foo.conf

Якщо вони виконали інші дії з моменту вилучення вашого видалення (або вони перетягуються з базою даних у відокремлену HEAD), їм може знадобитися щось інше, ніж @{1}. Їх можна було git log -gб знайти, перш ніж вони видалили ваше видалення.

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

Зберігайте файл як "за замовчуванням" і вручну / автоматично його активуйте

Якщо продовжувати зберігати вміст файлу конфігурації у сховищі не зовсім неприйнятно, можливо, ви зможете перейменувати відстежений файл з (наприклад) foo.confна, foo.conf.defaultа потім доручити вашим користувачам cp foo.conf.default foo.confпісля застосування перейменування. Або якщо користувачі вже використовують деяку існуючу частину репозиторію (наприклад, скрипт або якусь іншу програму, налаштовану вмістом у сховищі (наприклад, Makefileчи подібне)) для запуску / розгортання вашого програмного забезпечення, ви можете включити механізм дефолту в запуск / процес розгортання:

test -f foo.conf || test -f foo.conf.default &&
    cp foo.conf.default foo.conf

За наявності такого механізму дефолту користувачі повинні мати можливість взяти на себе зобов’язання, яке перейменовано foo.confнаfoo.conf.default без необхідності робити будь - які додаткові роботи. Крім того, вам не доведеться копіювати файл конфігурації вручну, якщо ви зробите додаткові установки / сховища в майбутньому.

Переписування історії вимагає ручного втручання в будь-якому випадку ...

Якщо неприпустимо підтримувати вміст у сховищі, ви, ймовірно, захочете повністю викорінити його з історії чимось подібним git filter-branch --index-filter …. Це означає історію перезапису, що вимагатиме вручну втручання для кожної гілки / сховища (див. Розділ «Відновлення з upstream Rebase» на сторінці сторінки git rebase ). Спеціальна обробка, потрібна для вашого конфігураційного файлу, - це ще один крок, який потрібно виконати під час відновлення з перезапису:

1. Збережіть копію файлу конфігурації.
2. Відновлення після перезапису.
3. Відновіть файл конфігурації.

Ігноруйте це, щоб запобігти рецидиву

Який би метод ви не використовували, ви, ймовірно, захочете включити ім’я файлу конфігурації у .gitignoreфайл у сховищі, щоб ніхто не міг ненароком git add foo.confзнову (це можливо, але вимагає -f/ --force). Якщо у вас є декілька файлів конфігурації, ви можете розглянути можливість "переміщення" їх усіх в єдиний каталог і ігнорування всього цього (маючи на увазі "переміщення", я маю на увазі зміну там, де програма розраховує знайти свої конфігураційні файли, та отримати користувачів (або механізм запуску / розгортання) для копіювання / переміщення файлів на їх нове місце; ви, очевидно, не хочете збирати файл mv у каталог, який ви будете ігнорувати).

У цьому ж тижні, коли я випадково зробив це, я намагався видалити файл збірки із спільного сховища, і це:

http://gitready.com/intermediate/2009/02/18/temporary-ignoring-files.html

добре працював для мене і досі не згадується.

git update-index --assume-unchanged <file>

Щоб видалити файл, який вас цікавить, з контролю версій, тоді використовуйте всі інші команди як звичайні.

git update-index --no-assume-unchanged <file>

Якщо ви коли-небудь хотіли повернути його назад.

Редагувати: дивіться коментарі від Chris Johnsen та KPM. Це працює лише локально, і файл залишається під контролем версій для інших користувачів, якщо вони також не роблять цього. Прийнята відповідь дає більш повні / правильні методи боротьби з цим. Також деякі примітки від посилання, якщо використовується цей метод:

Очевидно, існує досить багато застережень, які вступають у цю гру. Якщо ви git додайте файл безпосередньо, він буде доданий до індексу. Об’єднання комітету з цим прапором увімкнеться, що злиття вийде витончено, тому ви можете вручну обробити його.

Щоб видалити файл з індексу, використовуйте:

git reset myfile

Це не повинно впливати на вашу місцеву копію чи будь-кого іншого.

1. git rm --cached remove_file
2. додати файл до gitignore
3. git add .gitignore
4. git commit -m "Excluding"
5. Веселитися;)

Виконавши git rm --cachedкоманду, спробуйте додати myfileдо .gitignoreфайлу (створіть його, якщо його не існує). Це повинно сказати git ігнорувати myfile.

.gitignoreФайл версірован, так що ви повинні будете зробити його і штовхати його в віддалений репозиторій.

Моє рішення - натягнути на іншу робочу копію, а потім зробити:

git log --pretty="format:" --name-only -n1 | xargs git checkout HEAD^1

який говорить, що отримайте всі шляхи до файлу в останньому коментарі та перевірте їх у батьківської програми HEAD. Робота виконана.

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

Ось рішення, яке видаляє всі сліди файлу з усієї історії фіксації, як ніби він ніколи не існував, але зберігає файл на місці у вашій системі.

https://help.github.com/articles/remove-sensitive-data/

Насправді ви можете перейти до кроку 3, якщо ви перебуваєте у вашому локальному сховищі git, і вам не потрібно виконувати суху роботу. У моєму випадку мені знадобилися лише кроки 3 та 6, оскільки я вже створив свій файл .gitignore і знаходився у сховищі, над яким я хотів працювати.

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

Спочатку це виглядало залякано, але насправді було легко і працювало як принадність! :-)