Как иметь текущий файл в git, но не историю файла? - PullRequest
1 голос
/ 15 апреля 2019

Я работаю над проектом и использую git и GitHub в качестве своего репозитория (на самом деле это книга, но вопрос будет иметь отношение и к коду). Как правило, как и в программных проектах, я сохраняю только источник и каждый раз, когда строю вывод (книгу PDF) из этого источника. Но так как я сотрудничаю с кем-то в этом вопросе, кто не будет строить вывод, просто посмотрите на текущий прогресс, мне нужно периодически проверять созданный PDF-файл - но он большой.

Мне на самом деле не нужна история PDF (вывод), мне просто нужна последняя версия в git. Есть какой-либо способ сделать это? Другими словами, я не хочу отслеживать историю, просто у кончика любой ветви есть фактический файл.

Исследуя это, я думаю, что единственный способ сделать это - периодически очищать историю файла от git, а затем проверять новый PDF. Есть ли более простой способ?

Ответы [ 3 ]

4 голосов
/ 15 апреля 2019

Вы находитесь на территории основной команды здесь.Вам не нужна история, вы просто хотите контент, так что используйте его ядро ​​контент-трекера.Вопрос только в том, сколько вы хотите, чтобы Git сделал для вас?

Самое простое процедурное действие - просто пометить BLOB-объект:

$ make book.pdf
$ git tag -f current-book `git hash-object -w book.pdf`

И все готово.Мало кто из команд управления исходным кодом будет иметь представление о том, что делать с этим тегом, это даже не дерево, а просто блоб, но основные команды Git будут работать просто отлично.

$ git fetch origin current-book
$ git show FETCH_HEAD >book.pdf
$ open book.pdf
3 голосов
/ 15 апреля 2019

Нет хорошего способа сделать это. Не делай этого. Сделай что-нибудь еще - см. Ответ Криса .

Если вы все равно настаиваете на этом

Есть несколько плохих способов сделать это. Вероятно, самое простое - создать потерянную ветвь, в которой нет файлов, зафиксировать PDF как один файл в этой ветви (чтобы при проверке этой ветви вы получили рабочее дерево только с одним файлом PDF, который вы затем необходимо скопировать куда-нибудь еще и затем git checkout ветку, которую вы действительно хотите, что немедленно удалит файл PDF из вашего рабочего дерева):

$ git status

Убедитесь, что вам нечего делать, и ваше дерево работы чистое, потому что вы собираетесь их временно уничтожить. Тогда:

$ cp built.pdf /tmp/built.pdf          # save the PDF somewhere
$ git checkout --orphan pdfbranch      # create branch for one commit holding PDF
$ git read-tree --empty -u             # clear index and work-tree
$ cp /tmp/built.pdf built.pdf          # restore PDF to work-tree
$ git add built.pdf                    # copy to otherwise-empty index
$ git commit -m 'create built pdf'     # make one commit on branch
$ git checkout master                  # or whatever - PDF file goes away again

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

(Вы можете упростить вышесказанное, используя git worktree add, если ваш Git не меньше 2,5: используйте git worktree add --detach ../pdf-worktree master, чтобы создать место, в котором нужно выполнить шаги git checkout --orphan и git read-tree --empty -u, после чего вы можете оставить добавлено рабочее дерево как место для следующего обновления. Но в целом это плохая идея.)

Вы можете использовать тег вместо имени ветви; эффект тот же. Тем не менее, имена тегов не должны перемещаться, поэтому этот метод сложнее.

Общая идея здесь и причина того, что это плохая идея, состоит в том, что история является коммитами; коммиты являются историей в репозитории. Чтобы иметь файл, который не имеет другой истории, этот файл должен быть точно в одном коммите.

Еще одним методом является git add pdf как одиночного объекта BLOB, а затем прикрепление тега (легкий или аннотированный) к объекту BLOB. Удалите тег, чтобы освободить объект (в конечном итоге он будет удален). Это имеет те же недостатки, что и раньше, плюс проблема с тем, что теги не должны перемещаться, плюс тот факт, что для извлечения файла вам нужно быть немного Git-гуру.

3 голосов
/ 15 апреля 2019

Я бы не включил его в хранилище вообще.Вместо этого я бы отнесся к этому как к артефакту сборки.Вы даже можете генерировать его, используя инструмент непрерывной интеграции каждый раз, когда вы нажимаете на GitHub.

Например, используя Travis CI, вы можете создать свой PDF-файл и загрузить его в виде GitHub.выпускать всякий раз, когда вы отмечаете новую версию.Вы также можете настроить запуск заданий CI, когда вы помещаете (или объединяете) код в определенную ветвь.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...