Есть ли способ сохранить файл в репозитории GIT и удалить его локально без фиксации удаления?

Question

У меня есть особое требование c для проекта, чтобы сохранить папку с именем install в удаленном репозитории, которая была добавлена ​​в .gitignore после фиксации. Эта папка требуется только для установки приложения и должна быть удалена после установки. Можно ли удалить этот каталог install из локального репозитория без подтверждения удаления? Папка должна быть доступна в удаленном репозитории, но после первой настройки ее необходимо удалить.

Answer 1

Назначение git - управлять версией для артефактов. Это может быть код, изображения, двоичные файлы. Это могут быть даже артефакты выпуска, хотя это немного сложнее и Git не обязательно лучше всего подходит для этого.

Проблема здесь в том, что у вас, похоже, выполняются два разных действия

1. Потяните вниз и установите последнюю версию чего-то
2. Работайте над этим или используйте его постфактум

Мой отказ от этого требования, если бы оно было мне дано то, что два разных действия, приведенных выше, требуют разных подходов и не должны находиться в одном репо. Разработка и выпуск разделены, и их необходимо обрабатывать с помощью разных процессов (а иногда и разных инструментов).

Как правило, вы создаете какой-то установочный пакет или дистрибутив из репозитория разработки, который строится из данных в репо. Для распространения вы должны где-нибудь сохранить дистрибутив пакета, например, репозиторий пакетов npm для Node.JS или PyPi для Python. Кроме того, вы можете распространять пакет с помощью метода выпуска, такого как страница Release на Github для вашего репо, или специального репо, созданного для выпусков, например Artifactory или Docker Trusted Repo (больше для Docker контейнеров ...).

Вы также можете сохранить дистрибутив, как вас просят, но тогда обычно у вас будет отдельный репозиторий для его хранения, поэтому вашим разработчикам не нужно загружать последний дистрибутив при получении последней версии. совершить. Каждый раз, когда создается дистрибутив, вы помещаете установочные файлы в папку для этого репо (например, в локальную папку install) и pu sh новую фиксацию. Затем люди могут клонировать это или установить прямо из репозитория (т.е. загрузить файл (ы) прямо со страницы Github репозитория удаленной установки).

Однако это возможно, хотя это все еще немного взломано, чтобы потенциально иметь отдельную ветку, где существуют папки выпуска, но в основной ветке dev или master их нет. Если у вас нет выбора или возможности предложить лучшее решение, я бы выбрал go.

Answer 2

Уже есть еще один хороший ответ, но я хотел бы обратиться к этому конкретному вопросу напрямую:

Можно ли удалить этот установочный каталог из локального репозитория без подтверждения удаления?

Нет - и легко увидеть почему именно так, если учесть, что Git на самом деле хранит.

Каждая фиксация со своим уникальным ha sh Идентификационный номер, на самом деле сохраняет все ваших файлов в виде снимка в специальном, доступном только для чтения (замороженном на все время) формате Git только с дедупликацией. ¹ Эти коммиты, таким образом, действуют сами по себе: вам на самом деле не требуется предыдущий коммит, поэтому Git позволяет существовать мелким клонам. ²

Чтобы сделать новую фиксацию, вам нужно Git повторно сохранить каждый файл (дедупликация, поэтому все неизмененные файлы просто повторно используют предыдущий). Чтобы сделать фиксацию, в которой нет некоторого набора файлов (install/*), вы должны сделать фиксацию, в которой нет файлов. То есть вы должны зафиксировать удаление. Коммиты, что do имеют файлы, оставшиеся в репозитории, и если кто-либо в любое время в будущем сделает коммит, содержащий файл, который точно соответствует одному из этих install/* файлов, Git будет

См. Light CC ответ , чтобы указать, что вы можете сделать вместо того, что вы делаете сейчас, что вызывает некоторую боль.

¹ Технически это либо свободные объекты, , которые являются Git объектами типа blob, которые представляют собой просто сжатую zlib-форму файла с префиксом - вы можете читать их на разных языках, используя zlib-декомпрессор и затем пропуская заголовок, или упакованные объекты , которые затем используют дельта-сжатие и поэтому их гораздо труднее читать. Git оставляет за собой право изменять формат внутреннего хранилища в будущем, поэтому обычно лучше всего Git извлечь объект, превратив его обратно в обычный повседневный файл.

² Мелкие клоны все еще сложны, и, в частности, когда выталкивает из мелкого клона, Git может не осознавать, что какой-то другой Git уже имеет много файлов, и отправит их повторно. и заставьте другой Git дублировать их.