Создание ветки только измененных файлов в GIT или SVN

#git #svn #контроль_версий #git_branch

Есть проект, в котором N - файлов. Периодически создается версия обновления, но в
обновление входят только измененные файлы. Хотим проект завести под систему контроля
версий, типа git или svn. 

Ищем решение, при котором можно было бы выделить все измененные файлы (например из
истории коммитов) автоматически вынесить их в отдельную ветку/branch. 

Подскажите, возможно ли такое?
    

Ответы

Ответ 1

о создании ветки — см. ниже

простое решение

если создавать ветку не требуется, а надо лишь получить список файлов, изменившихся
между коммитом1 и коммитом2, то можно сделать примерно так:

$ git log --name-only --pretty="format:" коммит1..коммит2 | grep -v '^$' | sort -u


пояснения:


--name-only — выводить ещё и имена изменённых файлов
--pretty="format:" — вся служебная информация будет выведена как пустые строки
grep -v '^$' — удалит эти пустые строки
sort -u — удалит дубликаты из списка




из получившегося списка можно сразу и архив получить. примерно так (сжатый архив
запишется в файл /tmp/archive.tgz):

$ tar -czf /tmp/archive.tgz $(git log --name-only \
 --pretty="format:" коммит1..коммит2 | grep -v '^$' | sort -u)




ещё про «красоту»: файлы в архиве будут иметь тот же путь, что и в репозитории:

dir1/file1
file2


чтобы файлы в архиве «лежали» в каталоге, например, proga-1.0:

proga-1.0/dir1/file1
proga-1.0/file2


можно команде tar добавить опцию --transform (поддерживается, насколько мне известно,
только версией tar из операционной системы gnu):

$ tar -czf /tmp/archive.tgz --transform "s,^,proga-1.0/," $(git log
 --name-only --pretty="format:" коммит1..коммит2 | grep -v '^$' | sort -u)


репозиторий со скриптами

предложенные выше «однострочники» я поместил в репозиторий под лицензией gplv3.

getfiles [ revision..range ] — выдаёт список всех файлов, изменявшихся в промежутке
revision..range. если аргумент пропущен, то скрипт выдаст список всех файлов.

createarchive revision..range /path/to/archive.tgz [ prefix ] — создаёт указанный
архив (см. выше). если указан prefix, он добавляется к именам файлов (слэш в конце
префикса автоматически добавляется при необходимости).

truncatehistory [ revision..range ] — удаляет из репозитория историю всех файлов,
кроме тех, что изменялись в указанный revision..range. используйте с осторожностью!
код этого скрипта базируется на вот этом ответе.

о создании ветки

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

а предлагаю я «обреза́ть» историю не в основном репозитории, а в отдельном его клоне.
если возникнет необходимость видеть «обрезанную» историю в своём же репозитории — можно
подключить «обрезанный» клон как второй remote. учтите, что история у всех файлов из
этого клона полностью отлична от истории файлов в основном репозитории — начиная с
самого первого коммита. поэтому вливать такой отдельно-стоящий набор коммитов в рабочий
репозиторий я бы не рекомендовал: теоретически могут возникнуть проблемы с последующей
жизнедеятельностью репозитория.


скачайте файлы или склонируйте мой репозиторий со скриптами. путь к скриптам обозначим
как /путь1
сделайте клон вашего репозитория в пустом каталоге:

$ git clone адрес-вашего репозитория .

запустите:

/путь1/truncatehistory revision..range

всё, история репозитория полностью переписана и включает только те файлы, которые
изменялись в промежутке revision..range


Ответ 2

Вариант действий для любой SCM неверен методологически - предлагается дублировать
информацию, и так имеющуюся в системе (коллекция измененных объектов между двумя метками
в истории)
Опять же любая SCM посредственно/плохо подходит для цели "хранилище коллекций артефактов",
для этого есть более другие системы


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

Ну и чисто рекомендация - не надо гнаться за модным и бежать на Git, хотя со ST уходить
все же разумное решение