[Open source, Git, Резервное копирование, Хранение данных] Как и зачем хранить домашние каталоги пользователей в Git-репозиториях (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В этой статье расскажу, как с помощью Git я управляю файлами в своём домашнем каталоге и синхронизирую их на других устройствах.
У меня несколько устройств: лэптоп на работе, стационарный комп дома, Raspberry Pi, портативный компьютер Pocket CHIP, а также Chromebook с несколькими версиями Linux на борту. Давно хотел, чтобы на таких разных устройствах я мог выполнять примерно одинаковые действия для настройки окружений. Поначалу я просто не знал, как этого добиться. Например, команды Bash alias я чаще использовал на работе, а многие вспомогательные скрипты хорошо работали в моём домашнем окружении.
С годами грань между моими рабочими и домашними устройствами начала стираться. Задач стало больше, увеличился и объём разнородных неупорядоченных данных в домашних каталогах, с которыми надо было как-то разбираться. Я начал испытывать большие трудности — например, при работе над одним и тем же проектом на разных устройствах. Как ни странно, мою проблему решил Git.
Да, тот самый Git, который относится к классу распределённых систем управления версиями. Его широко используют крупные и мелкие open source проекты, а также компании, выпускающие проприетарный софт. Сначала я скептически смотрел на эту идею, потому что Git вроде бы создан для управления кодовой базой, а не домашним каталогом с кучей музыки, видео, фото, игр и прочего хлама. Я слышал, что кто-то из знакомых знакомых использует Git для управления файлами в домашнем каталоге. Но, всё же, я долго не решался попробовать. Думал, что таким образом гики просто развлекаются, а для задач обычных пользователей это не годится. Я ошибался.
Мне удалось добиться цели не сразу: пришлось учиться и искать решения по ходу дела. Но теперь я могу поделиться своим опытом, предложив готовые рецепты по управлению домашним каталогом с помощью Git.
1. Продумайте структуру и содержимое каталогов
Изображение: Seth Kenlon, CC BY-SA 4.0
С точки зрения Git ваш домашний каталог становится чем-то вроде слепой зоны для всего, кроме конфигурационных и других выбранных вами файлов. То есть, открыв вашу домашнюю директорию, вы не должны увидеть в корне ничего, кроме заранее сформированного списка каталогов. Там не должно быть никаких фото или документов. И никаких файлов, которые «просто полежат тут минутку».
Всё, что вы не коммитите, Git должен игнорировать. Поэтому очень важно, чтобы вы сохраняли эти файлы в подкаталогах, которые нужно добавить в свой файл .gitignore.
Многие Linux-дистрибутивы по умолчанию предлагают примерно такой список подкаталогов внутри /home/<имя пользователя>:
- Documents
- Downloads
- Music
- Photos
- Templates
- Videos
Пользователь, конечно же, может добавить туда и свои подкаталоги. Например, я разделил музыку, которую создаю (папка Music), и музыку, которую покупаю для прослушивания (папка Albums). Точно так же мой каталог Cinema содержит фильмы, которые я смотрю, а Videos — видеофайлы, которые мне нужны для монтажа.
Другими словами, моя структура каталогов более разнообразна, чем набор большинства дистрибутивов Linux по умолчанию. Я думаю, так же нужно сделать и вам. Без структуры каталогов, которая подходит именно вам, вы в какой-то момент просто начнёте скидывать файлы в корень домашнего каталога из-за отсутствия для них лучшего места. Поэтому постарайтесь заранее продумать это.
2. Продумайте содержимое файла .gitignore
Когда вы наведёте порядок в домашнем каталоге, перейдите в него и создайте репозиторий:
$ cd
$ git init .
Пока ваш репозиторий пуст, содержимое домашнего каталога не отслеживается. Поэтому сейчас вам нужно выбрать те файлы, которые так и останутся неотслеживаемыми. Посмотрите список файлов в вашем каталоге:
$ git status
.AndroidStudio3.2/
.FBReader/
.ICEauthority
.Xauthority
.Xdefaults
.android/
.arduino15/
.ash_history
[...]
Если вы долго пользуетесь домашним каталогом, этот список может быть длинным. Для начала добавьте подкаталоги из пункта 1 в скрытый файл с именем .gitignore. Тогда Git не будет отслеживать их:
$ \ls -lg | grep ^d | awk '{print $8}' >> ~/.gitignore
Далее решите, какие из оставшихся файлов будут неотслеживаемыми. Перебирая их, я обнаружил несколько устаревших конфигурационных файлов и каталогов, которые просто засоряли диск. Отдельного внимания заслуживают конфигурационные файлы, сгенерированные автоматически. Например, я оставляю неотслеживаемыми конфиги, которые генерирует KDE. Они хранят данные о недавно открытых документах и прочую информацию, которую имеет смысл хранить локально, только на одной машине.
Я принял решение коммитить мои собственные конфигурационные файлы, скрипты и профили, а также Bash-конфиги, мои конспекты и прочий текст, к которому я часто обращаюсь. Если вдруг я сомневаюсь по поводу какого-то файла, значит, ему место в списке неотслеживаемых. Ну и в любом случае файл .gitignore можно скорректировать позже.
3. Проанализируйте содержимое вашего диска
Для этой цели я использую сканер с открытым исходным кодом Filelight. Он рисует диаграмму, которая позволяет увидеть размер каждого каталога. Вы можете перемещаться по любому каталогу, чтобы понять, почему он столько весит. Если вы делаете такое исследование впервые, это изменит ваше представление о том, как и какие данные хранятся на вашем диске. И, опять же, вы увидите много мусора и сможете удалить его.
Изображение: Seth Kenlon, CC BY-SA 4.0
Если заметите, что некоторые приложения что-то кэшируют на вашем диске, вы сможете исключить эти данные из репозитория. Например, в KDE индексатор файлов Baloo хранит на диске достаточно много данных, которые востребованы лишь локально и совершенно не нужны в репозитории.
4. Делайте коммит .gitignore домашнего каталога
Серия закомиченных файлов .gitignore может многое рассказать о том, как формировалось Git-окружение моей мечты. Я храню его в репозитории вместе с другими важными файлами. Таким образом он доступен со всех моих устройств. И все мои окружения идентичны на уровне домашнего каталога: у них плюс-минус одинаковый набор папок по умолчанию и скрытых файлов конфигурации.
5. Не бойтесь коммитить бинарники
Я тестировал свой велосипед неделями и всё это время был уверен, что коммитить бинарники — плохая идея. Боялся, что из-за этого раздуется размер репозитория. У меня даже был скрипт, который вынимал XML из файлов LibreOffice и только после этого делал коммит. Другой скрипт восстанавливал файл LibreOffice из сохранённого XML. Вот так я изворачивался, чтобы экономить дисковое пространство.
В результате я понял, что можно не заморачиваться, если ты коммитишь небольшое количество бинарных файлов. Безусловно, если в репозиторий лить бинарники целыми гигабайтами, то он чрезмерно разрастётся. В моём случае боятся нечего: рост будет некритичным.
6. Используйте приватный репозиторий
Не размещайте свой домашний каталог в публичном Git-репозитории. У меня, например, есть SSH-ключи и цепочки ключей GPG, которые обеспечивают мне защищённый доступ.
На Raspberry Pi я развернул локальный Git-сервер, поэтому у меня полный контроль над моей системой. Особенно, когда я дома. Правда, работаю я удалённо, поэтому это удобно. На случай отъезда я сделал себе доступ через мой собственный VPN.
7. Не забывайте делать push
Особенность Git в том, что он отправляет изменения на ваш сервер только тогда, когда вы ему об этом скажете. Если вы давно пользуетесь Git, это для вас, вероятно, вполне естественно. Новым пользователям, которые, возможно, привыкли к автоматической синхронизации в Nextcloud или Syncthing, может понадобиться некоторое время, чтобы привыкнуть.
Git — друг человека
Управление моими файлами с помощью Git не только помогло наладить регулярную синхронизацию между устройствами. Сейчас, имея полную историю всех моих конфигураций и служебных скриптов, я могу смело пробовать новые идеи, потому что всегда легко откатить изменения, если что-то пойдёт не так.
Например, Git спас меня от проблем из-за неправильной команды umask в .bashrc, от неудачного ночного дополнения к моему скрипту управления пакетами и от многих других моих ошибок.
Маклауд предоставляет недорогие серверы, которые подойдут в том числе для хранения данных. Используем быстрое и надёжное дисковое хранилище на основе дисков NVMe.
Зарегистрируйтесь по вышеуказанной ссылке или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!
оригинал
===========
Источник:
habr.com
===========
===========
Автор оригинала: Seth Kenlon
===========Похожие новости:
- [Хранилища данных, Законодательство в IT, Сетевое оборудование, IT-компании] Владельцев технологических сетей связи предложили обязать хранить 3 года данные о действиях пользователей
- [Open source, Читальный зал] Изобретайте колесо (перевод)
- [Настройка Linux, Open source, *nix, Сетевые технологии, Беспроводные технологии] Настройка роутера с прошивкой DD-WRT на работу с L2TP на примере Билайна
- [Open source, GitHub] GitHub завёл однократные донаты в Sponsors
- [Настройка Linux, Open source, Видеотехника, DIY или Сделай сам] KODI: собираем удобный и функциональный медиацентр для дома. Часть 5. Яндекс.Музыка
- [Информационная безопасность, Управление проектами] Внедрение СЭД vs требования к ИБ
- [Open source, C++, GitHub, Звук, IT-компании] Google открыла исходный код кодека для сжатия голоса Lyra
- [Серверная оптимизация, Хранение данных, Хранилища данных, Энергия и элементы питания, Экология] Microsoft тестирует охлаждение серверов в ванне с жидкостью
- [Информационная безопасность, Криптография, Open source] Kleopatra: GnuPG в графической оболочке
- [Big Data, Хранение данных, Управление продуктом, Финансы в IT] Not so big data: как работать с небольшими, но очень ценными данными
Теги для поиска: #_open_source, #_git, #_rezervnoe_kopirovanie (Резервное копирование), #_hranenie_dannyh (Хранение данных), #_git, #_hranenie_dannyh (хранение данных), #_bekap (бэкап), #_sinhronizatsija_fajlov (синхронизация файлов), #_sinhronizatsija_dannyh (синхронизация данных), #_blog_kompanii_maklaud (
Блог компании Маклауд
), #_open_source, #_git, #_rezervnoe_kopirovanie (
Резервное копирование
), #_hranenie_dannyh (
Хранение данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:47
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В этой статье расскажу, как с помощью Git я управляю файлами в своём домашнем каталоге и синхронизирую их на других устройствах. У меня несколько устройств: лэптоп на работе, стационарный комп дома, Raspberry Pi, портативный компьютер Pocket CHIP, а также Chromebook с несколькими версиями Linux на борту. Давно хотел, чтобы на таких разных устройствах я мог выполнять примерно одинаковые действия для настройки окружений. Поначалу я просто не знал, как этого добиться. Например, команды Bash alias я чаще использовал на работе, а многие вспомогательные скрипты хорошо работали в моём домашнем окружении. С годами грань между моими рабочими и домашними устройствами начала стираться. Задач стало больше, увеличился и объём разнородных неупорядоченных данных в домашних каталогах, с которыми надо было как-то разбираться. Я начал испытывать большие трудности — например, при работе над одним и тем же проектом на разных устройствах. Как ни странно, мою проблему решил Git. Да, тот самый Git, который относится к классу распределённых систем управления версиями. Его широко используют крупные и мелкие open source проекты, а также компании, выпускающие проприетарный софт. Сначала я скептически смотрел на эту идею, потому что Git вроде бы создан для управления кодовой базой, а не домашним каталогом с кучей музыки, видео, фото, игр и прочего хлама. Я слышал, что кто-то из знакомых знакомых использует Git для управления файлами в домашнем каталоге. Но, всё же, я долго не решался попробовать. Думал, что таким образом гики просто развлекаются, а для задач обычных пользователей это не годится. Я ошибался. Мне удалось добиться цели не сразу: пришлось учиться и искать решения по ходу дела. Но теперь я могу поделиться своим опытом, предложив готовые рецепты по управлению домашним каталогом с помощью Git. 1. Продумайте структуру и содержимое каталогов  Изображение: Seth Kenlon, CC BY-SA 4.0 С точки зрения Git ваш домашний каталог становится чем-то вроде слепой зоны для всего, кроме конфигурационных и других выбранных вами файлов. То есть, открыв вашу домашнюю директорию, вы не должны увидеть в корне ничего, кроме заранее сформированного списка каталогов. Там не должно быть никаких фото или документов. И никаких файлов, которые «просто полежат тут минутку». Всё, что вы не коммитите, Git должен игнорировать. Поэтому очень важно, чтобы вы сохраняли эти файлы в подкаталогах, которые нужно добавить в свой файл .gitignore. Многие Linux-дистрибутивы по умолчанию предлагают примерно такой список подкаталогов внутри /home/<имя пользователя>:
Пользователь, конечно же, может добавить туда и свои подкаталоги. Например, я разделил музыку, которую создаю (папка Music), и музыку, которую покупаю для прослушивания (папка Albums). Точно так же мой каталог Cinema содержит фильмы, которые я смотрю, а Videos — видеофайлы, которые мне нужны для монтажа. Другими словами, моя структура каталогов более разнообразна, чем набор большинства дистрибутивов Linux по умолчанию. Я думаю, так же нужно сделать и вам. Без структуры каталогов, которая подходит именно вам, вы в какой-то момент просто начнёте скидывать файлы в корень домашнего каталога из-за отсутствия для них лучшего места. Поэтому постарайтесь заранее продумать это. 2. Продумайте содержимое файла .gitignore Когда вы наведёте порядок в домашнем каталоге, перейдите в него и создайте репозиторий: $ cd
$ git init . Пока ваш репозиторий пуст, содержимое домашнего каталога не отслеживается. Поэтому сейчас вам нужно выбрать те файлы, которые так и останутся неотслеживаемыми. Посмотрите список файлов в вашем каталоге: $ git status
.AndroidStudio3.2/ .FBReader/ .ICEauthority .Xauthority .Xdefaults .android/ .arduino15/ .ash_history [...] Если вы долго пользуетесь домашним каталогом, этот список может быть длинным. Для начала добавьте подкаталоги из пункта 1 в скрытый файл с именем .gitignore. Тогда Git не будет отслеживать их: $ \ls -lg | grep ^d | awk '{print $8}' >> ~/.gitignore
Далее решите, какие из оставшихся файлов будут неотслеживаемыми. Перебирая их, я обнаружил несколько устаревших конфигурационных файлов и каталогов, которые просто засоряли диск. Отдельного внимания заслуживают конфигурационные файлы, сгенерированные автоматически. Например, я оставляю неотслеживаемыми конфиги, которые генерирует KDE. Они хранят данные о недавно открытых документах и прочую информацию, которую имеет смысл хранить локально, только на одной машине. Я принял решение коммитить мои собственные конфигурационные файлы, скрипты и профили, а также Bash-конфиги, мои конспекты и прочий текст, к которому я часто обращаюсь. Если вдруг я сомневаюсь по поводу какого-то файла, значит, ему место в списке неотслеживаемых. Ну и в любом случае файл .gitignore можно скорректировать позже. 3. Проанализируйте содержимое вашего диска Для этой цели я использую сканер с открытым исходным кодом Filelight. Он рисует диаграмму, которая позволяет увидеть размер каждого каталога. Вы можете перемещаться по любому каталогу, чтобы понять, почему он столько весит. Если вы делаете такое исследование впервые, это изменит ваше представление о том, как и какие данные хранятся на вашем диске. И, опять же, вы увидите много мусора и сможете удалить его.  Изображение: Seth Kenlon, CC BY-SA 4.0 Если заметите, что некоторые приложения что-то кэшируют на вашем диске, вы сможете исключить эти данные из репозитория. Например, в KDE индексатор файлов Baloo хранит на диске достаточно много данных, которые востребованы лишь локально и совершенно не нужны в репозитории. 4. Делайте коммит .gitignore домашнего каталога Серия закомиченных файлов .gitignore может многое рассказать о том, как формировалось Git-окружение моей мечты. Я храню его в репозитории вместе с другими важными файлами. Таким образом он доступен со всех моих устройств. И все мои окружения идентичны на уровне домашнего каталога: у них плюс-минус одинаковый набор папок по умолчанию и скрытых файлов конфигурации. 5. Не бойтесь коммитить бинарники Я тестировал свой велосипед неделями и всё это время был уверен, что коммитить бинарники — плохая идея. Боялся, что из-за этого раздуется размер репозитория. У меня даже был скрипт, который вынимал XML из файлов LibreOffice и только после этого делал коммит. Другой скрипт восстанавливал файл LibreOffice из сохранённого XML. Вот так я изворачивался, чтобы экономить дисковое пространство. В результате я понял, что можно не заморачиваться, если ты коммитишь небольшое количество бинарных файлов. Безусловно, если в репозиторий лить бинарники целыми гигабайтами, то он чрезмерно разрастётся. В моём случае боятся нечего: рост будет некритичным. 6. Используйте приватный репозиторий Не размещайте свой домашний каталог в публичном Git-репозитории. У меня, например, есть SSH-ключи и цепочки ключей GPG, которые обеспечивают мне защищённый доступ. На Raspberry Pi я развернул локальный Git-сервер, поэтому у меня полный контроль над моей системой. Особенно, когда я дома. Правда, работаю я удалённо, поэтому это удобно. На случай отъезда я сделал себе доступ через мой собственный VPN. 7. Не забывайте делать push Особенность Git в том, что он отправляет изменения на ваш сервер только тогда, когда вы ему об этом скажете. Если вы давно пользуетесь Git, это для вас, вероятно, вполне естественно. Новым пользователям, которые, возможно, привыкли к автоматической синхронизации в Nextcloud или Syncthing, может понадобиться некоторое время, чтобы привыкнуть. Git — друг человека Управление моими файлами с помощью Git не только помогло наладить регулярную синхронизацию между устройствами. Сейчас, имея полную историю всех моих конфигураций и служебных скриптов, я могу смело пробовать новые идеи, потому что всегда легко откатить изменения, если что-то пойдёт не так. Например, Git спас меня от проблем из-за неправильной команды umask в .bashrc, от неудачного ночного дополнения к моему скрипту управления пакетами и от многих других моих ошибок. Маклауд предоставляет недорогие серверы, которые подойдут в том числе для хранения данных. Используем быстрое и надёжное дисковое хранилище на основе дисков NVMe. Зарегистрируйтесь по вышеуказанной ссылке или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!  оригинал =========== Источник: habr.com =========== =========== Автор оригинала: Seth Kenlon ===========Похожие новости:
Блог компании Маклауд ), #_open_source, #_git, #_rezervnoe_kopirovanie ( Резервное копирование ), #_hranenie_dannyh ( Хранение данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 13:47
Часовой пояс: UTC + 5