Как удалить все вхождения файла в индекс, из всех git совершает

Question

Первый раз, используя git здесь. Я случайно использовал «git init» без файла .gitignore, поэтому у меня есть куча gradle/и build/files в моих коммитах. Я использую «git ls-tree -r master», чтобы показать все файлы в индексе. Вместо того, чтобы проверять каждый предыдущий фиксатор и использовать «git rm --cached» для удаления всех ненужных файлов сборки и градиента, как удалить все его вхождения во все предыдущие коммиты?

Редактировать: Есть ли способ удалить все каталоги и файлы во всех коммитах и ​​сохранить только каталог src?

Answer 1

Возможно, вам действительно нужна команда filter-branch, а не rebase. В любом случае есть несколько пунктов, чтобы быть в курсе:

• Вы не можете изменить любых существующих коммитов, когда-либо.
• Таким образом, как rebase, так и filter-branch нет. Вместо этого они копия коммиты. Теперь у вас в два раза больше коммитов! Чего ждать?!
• Но Git может и в конце концов удалит то, что он называет unreferted объектов (фиксирует и их соответствующие файлы), и вы можете ускорить это различными способами, если это необходимо.

Таким образом, это как rebase, так и filter-branch: они копируют коммиты, а перед выполнением копии допускают некоторые изменения. Затем, совершив (немного отличающиеся) копии, они переместили ссылки - имена ветвей и тегов - на копии.

Имея это в виду, есть еще несколько пунктов, чтобы рассмотреть следующие вопросы:

• только фильтр-ветви копирует и перемещает теги, и это только делает это, если вы предоставляете --tag-filter. (Если у вас нет тегов, это, разумеется, не имеет значения.) И, когда копии фильтров подписывают аннотированные теги, они выгружают свои подписи: они становятся беззнаковыми. В противном случае вам придется приказать вам вручную переписать их все, а фильтр-ветвь будет полностью автоматизирована.
• Поскольку ветвь фильтра спроектирована так, чтобы быть автоматизированной, и поскольку она предназначена для работы при каждом фиксации в репозитории, она (a) имеет тенденцию быть медленной и (b) имеет множество сложных вариантов, предназначенных для ускорьте это. Если у вас не так много коммитов, это не такая уж большая сделка. Если вы это сделаете, то окупится, чтобы изучить, как использовать множество вариантов, чтобы ускорить его.
• Поскольку обе команды копируют коммиты, если у кого-то еще есть копия репозитория, вы также создаете для них кучу работы: им нужно переключиться на копии. Если они этого не сделают, они могут повторно ввести все первоначальные коммиты, а затем вы вернетесь к тому, чтобы иметь в два раза больше.

Теперь вы готовы к the linked question и ответу ответчика на фильтр. См. Также this other answer на соответствующий вопрос, однако, за инструкциями по использованию --tag-name-filter и некоторыми вариантами ускорения.

Обратите внимание, что git rm -f --cached --ignore-unmatch работает с именами каталогов (или «папками»), а также с именами простых файлов.--tree-filter (упомянутый в других ответах на странице со ссылками) можно использовать вместо --index-filter, и это более удобно для сложных операций, но это много медленнее (точное замедление зависит от ОС, размера репо, SSD против хранения прядения и т. д., но «примерно на 100x медленнее» является хорошей стартовой оценкой), чем с использованием --index-filter.