В январе 2012 г. Рэндал Шварц выступил под названием Введение в Git что мне очень понравилось, но меня смутило его предостережение не использовать git для отслеживания отдельных файлов с несвязанной или отдельной историей.
Страница 4 его слайдов содержат следующие пункты. . .
Но не для ...
- Отслеживание прав доступа и владения файлами
- Отслеживание отдельных файлов с отдельной историей
- Делать вещи болезненными
. . . и вот что он говорит примерно через 4 минуты:
Он не оптимизирован для каких-либо метаданных о файлах. Это не, это не, отслеживать права доступа к файлам или право собственности на файлы. Это не его работа. Он управляет исходными файлами, а источники не имеют владельцев, источники не имеют разрешений. Исходники используются в рецептах для создания реального объекта, который вы собираетесь развернуть. Так что у git нет технологий по этому поводу. Люди пытались построить на нем структуры, чтобы сделать это, с некоторой степенью успеха, но на самом деле давайте посмотрим на то, для чего предназначен git, а не на то, что люди строят на нем.
Он также не предназначен для отслеживания отдельных файлов с несвязанной или отдельной историей. Например, вы можете подумать: «О, мне это очень нравится. Я хочу отслеживать все мои и т. Д. С его помощью. Но и т. Д., На самом деле, это набор отдельных, не связанных между собой файлов. Вы не будете выполнять ветвление и слияние. . Добавьте это изменение к этому изменению и в конечном итоге захотите отменить их оба одновременно. На самом деле это не работает. Так что это не подходит для отдельных файлов.
Я все еще использую RCS для отслеживания отдельных файлов в моем каталоге / etc. Это действительно быстро, дешево, и я могу вернуться к нужным мне данным. Он также не оптимизирован для того, чтобы делать вещи болезненными. ОК? Он разработан, чтобы быть простым и прочим.
Лично у меня нет планов отслеживать мои / etc с помощью git, но я недавно начал использовать git для отслеживания / var / named (конфигурации BIND). Учитывая то, что сказал Рэндал выше, следует ли мне прекратить использовать git для этой цели? Есть ли обратная сторона, проблема, о которой я не предвижу? Пока все работает так, как я ожидал, и у меня не было проблем, но я действительно не решился начать использовать git для отслеживания / var / named из-за предупреждения выше.
Я нахожусь под влиянием scm_track_enabled особенность Сапожник в котором говорится: «включает триггер, версия которого контролирует все изменения в / var / lib / cobbler при выполнении событий добавления, редактирования или синхронизации. Это можно использовать для возврата к предыдущим версиям базы данных, создания RSS-каналов или для другого аудита или резервного копирования. git - это SCM, рекомендуемый для использования с этой функцией ". Мое использование git с / var / named очень похоже на это.
(Кстати, я никогда не использовал RCS и не могу себе представить, чтобы я потрудился изучить его, даже если это легко, когда у меня уже есть приличное понимание git.)
В частности, мне интересно использовать git для отслеживания / var / named, но я приветствую ответы о лучших методах использования git для отслеживания подобных каталогов.
Действительно субъективная территория. Мне не нравится etckeeper, он создает очень запутанную историю / etc. Теперь для / var / named (я предполагаю, что здесь определены ваши зоны) это могло бы быть лучше, особенно если у вас всего несколько зон, но это все равно будет уродливым взломом.
Я считаю, что "правильный" способ сделать это - использовать Кукольный или аналогичное другое программное обеспечение для управления конфигурацией. Вместо того чтобы настраивать серверы, вы пишете код Puppet, который настраивает ваши серверы. Я использую mercurial (но вы можете использовать git) для управления репозиторием кода Puppet. Разветвление и слияние полезно (например, вы работаете над новой конфигурацией, которая, как вы не уверены, достаточно протестирована, и затем вы должны срочно исправить проблему на производственном сервере; в этом случае вы переходите от стабильной версии, а позже вы объединить). Комбинация Puppet + DVCS очень полезна и очень чиста, но Puppet - это маленький зверь, которого нужно немного времени, чтобы приручить, и связать с Puppet особенно сложно из-за порядковых номеров зон.
Обновить:
Я думал об этом и склонен заключить, что нет ничего плохого в использовании git для отслеживания / var / named, и что это не уродливый взлом. Да, файлы связаны. Да, вы можете захотеть клонировать, чтобы сделать серьезную ревизию вашей конфигурации, ветки, чтобы сохранить вашу производственную конфигурацию при ревизии, и слияние, когда вы закончите ревизию (хотя все это может быть необычным).
Немного не по теме, но в конфигурации bind есть две вещи, которые мне не нравятся. Во-первых, чтобы добавить зону, мне нужно добавить / изменить два файла: named.conf и файл зоны. Это излишне сложно. Я бы предпочел установку, аналогичную apache, с файлами зон в / etc / bind / zone-available, с символической ссылкой из / etc / bind / zone-enabled, без необходимости касаться named.conf. Во-вторых, мешают серийные номера. В основном мы автоматизируем их обслуживание; на машинах, управляемых Puppet, у меня есть сценарий оболочки, который их исправляет, а на других я использую плагин vim. Тот факт, что мы их автоматизируем, означает, что они вполне могут отсутствовать. Вместо этого можно использовать временные метки файлов. Серийные номера создадут некоторую уродливость в истории репозитория, но это проблема привязки, а не проблема git или практики использования git для отслеживания конфигурации привязки.
Это уход на «весьма субъективную» территорию. Но...
Я не вижу ничего плохого в использовании git для отслеживания подобных вещей. Да, он был создан для отслеживания больших и сложных коллекций взаимосвязанных исходных файлов. Это не значит, что он не так хорошо подходит для отслеживания небольших коллекций не связанных файлов.
Лично я использую etckeeper выслеживать /etc на моих серверах, используя серверную часть git. Прекрасно работает. При установке из репозитория apt Ubuntu он поставляется с хорошими перехватчиками в apt, поэтому он автоматически запускает фиксацию, совпадающую с каждой новой установкой пакета. Довольно удобно.
В любом случае, попробуйте, это ничего не повредит, и если вы в конечном итоге захотите переключиться на другую систему контроля версий в будущем, существует множество доступных инструментов миграции.
Спроси себя...
Смогу ли я когда-нибудь «вернуться» к конкретному коммиту в git, если он будет охватывать все / etc?
Смогу ли я когда-нибудь «объединить» коммит с моим текущим состоянием, если он будет охватывать все / etc?
Я предполагаю, что ответ - НЕТ, НЕТ, НЕТ.
В таком случае git - неподходящий инструмент. Git отслеживает дерево файлов, а не отдельный файл. Вот почему я выступаю за RCS для отдельных файлов.