Обновление (19 сен, 2020)
Наконец-то появился свой сайт! Я переместил все свои статьи на ajmalsiddiqui.me/blog и в процессе этого понял, что сильно вырос с тех пор, как написал эти статьи. Поэтому я буду обновлять статьи, чтобы отражать то, что я узнал, исправлять ошибки и улучшать качество, насколько это возможно. Но все эти обновления будут в первую очередь на моем сайте, поэтому, пожалуйста, прочтите там эту статью. Чао!
В первой статье я представил точечные файлы. В этой статье мы рассмотрим их развитие и управление.
Примечание. Это вторая статья из серии, в которой обсуждаются более сложные аспекты управления точечными файлами. Чтобы узнать, что такое точечные файлы и самые основы управления точечными файлами, прочтите первую статью.
В прошлой статье мы добавили несколько псевдонимов и функций в файлы .bash_profile
и .bashrc
. Мы также узнали, что это не единственные файлы точек, которые мы можем настроить.
Эта статья посвящена тому, чтобы сделать наш подход к управлению точечными файлами более сложным и масштабируемым. На этом этапе есть одна важная вещь, о которой вы должны помнить с этого момента. Точечные файлы - это вопрос личных предпочтений, как и управление ими. Вы должны управлять ими по-своему. В этой статье представлены только общие рекомендации и общие способы решения повторяющихся задач в управлении точечными файлами.
Настройка вашей среды
Начните с создания каталога для ваших точечных файлов и cd
в него. Мне нравится, когда мой находится в папке Projects
в моем домашнем каталоге, но это зависит от вас:
$ mkdir ~/Projects/dotfiles $ cd ~/Projects/dotfiles
Здесь у нас будут все наши точечные файлы. Начнем с создания репозитория git.
$ git init
Начнем с перемещения .bash_profile
из каталога HOME
в наш новый каталог точечных файлов.
$ mv ~/.bash_profile ~/Projects/dotfiles/.bash_profile
Давайте зафиксируем этот файл.
$ git commit -am "Added .bash_profile"
И вот оно! Именно так вы бы работали над любым другим проектом, и именно так вы должны управлять своими точечными файлами.
Можно спросить, зачем нужен контроль версий. Людям нравится передавать свои точечные файлы в систему контроля версий по нескольким причинам:
- Отправка точечных файлов в удаленное репо позволяет людям делиться своими точечными файлами с другими или получать к ним удаленный доступ, когда они им нужны. Это также безопасный способ резервного копирования ваших точечных файлов.
- Контроль версий позволяет вам видеть, как ваши точечные файлы развиваются с течением времени.
Но если вы запустите другой экземпляр терминала, вы заметите, что ваша установка не работает! Терминал не получает ваши .bash_profile
или .bashrc
из пользовательской папки, поскольку предполагается, что эти файлы находятся в домашнем каталоге.
Итак, нам нужен способ синхронизировать наши точечные файлы в каталоге dotfiles
с нашим домашним каталогом. Вы можете делать это как хотите, даже если это так же просто, как копирование всех файлов из вашего dotfiles
каталога в домашний каталог с помощью сценария. Но есть более элегантные подходы. Давайте посмотрим на два из них.
rsync
подход
Один из способов справиться с проблемой наличия ваших точечных файлов в каталоге, отличном от домашнего, - это скопировать файлы с помощью сценария. Но есть гораздо лучший способ сделать это, чем использовать команду cp
: команду rsync
.
Rsync, что означает удаленная синхронизация, представляет собой средство удаленной и локальной синхронизации файлов. Он использует алгоритм, который сводит к минимуму объем копируемых данных, перемещая только те части файлов, которые были изменены. Таким образом, этот подход является более эффективным и более масштабируемым, когда дело доходит до синхронизации точечных файлов. Эта статья посвящена rsync более подробно.
Выполните эту команду, чтобы синхронизировать каталог dotfiles с вашим домашним каталогом:
$ rsync . ~
Команда работает точно так же, как команда cp
. Он копирует содержимое источника (текущий каталог: .
) в место назначения (домашний каталог: ~
).
Однако у вас могут быть служебные сценарии в каталоге точечных файлов, которые вы, возможно, не захотите копировать в домашний каталог. В этом случае вы можете исключить эти файлы с помощью флага --exclude
. Фактически, вы бы предпочли не синхронизировать каталог .git
в папке dotfiles с вашим домашним каталогом. Итак, вот обновленная команда:
$ rsync --exclude ".git/" . ~
Вы можете использовать флаг --exclude
несколько раз, чтобы исключить несколько файлов. Этот подход используется mathiasbynens в его точечных файлах.
Символьные ссылки
Другой подход к синхронизации точечных файлов - это создание символических ссылок из точечных файлов в вашем каталоге точечных файлов на домашний каталог. Если вы не знаете, что такое символические ссылки, я предлагаю вам прочитать об этом здесь.
Это подход, который я использую в моих точечных файлах, и я делаю это из-за одного большого преимущества перед подходами, основанными на копировании файлов - автообновлением. Символические ссылки в каталоге по сути являются псевдонимами исходных файлов в вашем каталоге dotfiles, поэтому любые внесенные вами изменения автоматически отражаются в нем. Это означает, что вам не нужно запускать команду / сценарий синхронизации каждый раз, когда вы вносите изменения. Это очень полезно.
Вы можете символически связать свой .bash_profile
с домашним каталогом, используя команду ln
с флагом -s
(и флагом -v
, чтобы сделать его подробным):
$ ln -sv ~/Projects/dotfiles/.bash_profile ~
Теперь всякий раз, когда вы сохраняете изменения, внесенные в ваш .bash_profile
, они автоматически отражаются в домашнем каталоге, и вы можете запустить новый терминал или source .bash_profile
, чтобы увидеть их в действии.
Создание служебных скриптов для синхронизации и начальной загрузки
На этом этапе вы выполняете команды терминала для синхронизации файлов точек с домашним каталогом. Этот подход практически невозможно масштабировать, если вам нужно иметь дело с более чем 2–3 файлами.
Следовательно, лучше написать пару служебных скриптов, которые помогут держать ваши точечные файлы под контролем. У вас должен быть хотя бы один скрипт в вашем репозитории точечных файлов, который вы используете для синхронизации. Ваш сценарий синхронизации должен по существу использовать ваш механизм синхронизации для синхронизации ваших точечных файлов с домашним каталогом. Он также должен иметь механизм, исключающий синхронизацию определенных файлов. Такие файлы, как сценарий синхронизации, сценарий начальной загрузки, каталог .git
, файл README.md и т. Д., Должны быть исключены.
В настоящее время у меня есть функция sync
в моем сценарии bootstrap.exclude.sh
, которая обрабатывает синхронизацию и исключает любые файлы с .exclude
в имени файла в дополнение к указанным выше. Это довольно безотказный механизм. Вы можете проверить это здесь".
Настоятельно рекомендуется иметь другой сценарий для загрузки новой системы с вашими точечными файлами и настройки среды разработки.
Одна важная вещь, для которой вы можете использовать свой сценарий начальной загрузки, - это установка пакетов и инструментов, которые вы обычно используете.
Например, я разработчик Node.js и использую Mac, поэтому я могу использовать диспетчер пакетов homebrew для установки инструментов и утилит, которые я обычно использую. Я могу включить что-то вроде этого в свой сценарий начальной загрузки:
# Make sure we’re using the latest Homebrew brew update # Upgrade any already-installed formulae brew upgrade # NodeJS brew install node # Heroku brew install heroku # Yarn - an alternative to npm brew install yarn # Docker for containerization brew install docker
Этот скрипт устанавливает Node, Heroku, yarn и Docker на мой Mac. Скажем, я в конечном итоге форматирую свой Mac или покупаю новый. Мне не нужно устанавливать все, что я использую вручную. Вместо этого я могу клонировать свои точечные файлы из удаленного репозитория и запустить сценарий начальной загрузки, который настраивает все за меня. Поскольку у вас может быть много вещей, которые вы используете, лучше всего выделить это в отдельный файл. Посмотрите мой brew.exclude.sh
файл для примера.
Ваш сценарий начальной загрузки должен обрабатывать следующие вещи:
- Создание любых соответствующих каталогов, которые вы используете (например, каталог
~/Projects
). - Вызовите свой сценарий синхронизации, чтобы синхронизировать ваши точечные файлы с домашним каталогом.
- Установите все инструменты, утилиты, языки и т. Д., Которые вы обычно используете.
Мой сценарий начальной загрузки довольно минимален и обрабатывает все эти вещи, так что это может быть хорошим местом для начала.
Разделение вашего .bash_profile
По мере добавления множества псевдонимов и функций мы начинаем понимать, что .bash_profile
становится довольно большим и громоздким в управлении. Давайте исправим эту проблему.
Команду source
можно использовать в сценарии для выполнения команд в файле, заданном в качестве аргумента команды. Таким образом, мы можем создавать дополнительные файлы для хранения наших функций и псевдонимов и передавать их в наш .bash_profile
. Обычно эти файлы называют .functions
и .aliases
соответственно.
Создайте .functions
и .aliases
с помощью этой команды (находясь в каталоге dotfiles):
$ touch .functions .aliases
Теперь вырежьте и вставьте все функции из вашего .bash_profile
в .functions
и все псевдонимы в .aliases
. Наконец, добавьте в свой .bash_profile
следующие строки:
source .functions source .aliases
Вот что происходит, когда вы открываете новое окно терминала:
.bash_profile
оценивается.- Команда
source .functions
выполняется, и теперь вы можете использовать свои функции. - Команда
source .aliases
выполняется, и теперь вы можете использовать свои псевдонимы.
Вы можете разделить содержимое вашего .bash_profile
любым удобным вам способом и просто source
соответствующие файлы. Обратите внимание, что вам потребуются файлы .functions
и .aliases
в вашем домашнем каталоге, поэтому убедитесь, что вы синхронизировали папку dotfiles с домашним каталогом, чтобы изменения вступили в силу.
Теперь, когда у нас есть рабочий процесс управления точечными файлами с репозиторием точечных файлов, механизмом синхронизации содержимого репо с домашним каталогом и возможностью разбивать наш код на управляемые файлы, мы можем с радостью взломать нашу среду разработки.
Хотя этого достаточно, чтобы поиграть с вашими точечными файлами, есть еще один важный аспект точечных файлов, на который следует обратить внимание: совместное использование.
Добавление поддержки для настройки
Размещение ваших точечных файлов в общедоступном репозитории редко бывает достаточно для того, чтобы ими можно было делиться. Если вы хотите, чтобы другие поэкспериментировали с вашими точечными файлами, вам следует сделать несколько вещей:
- Убедитесь, что есть документация по установке и использованию ваших точечных файлов. Обычно это находится в README.md вашего проекта. Механизм, который вы используете для исключения файлов из синхронизации с домашним каталогом, также должен исключать этот файл. Вам также следует взглянуть на файлы README популярных репозиториев точечных файлов, чтобы понять, что люди туда кладут. Вот ссылка на мою.
- Если возможно, поддержите механизм, позволяющий людям легко настраивать ваши точечные файлы, не углубляясь в них. Этот механизм полностью ваш выбор, хотя я поделюсь своим ниже.
Примечание. В остальной части этого раздела обсуждается мой подход к безболезненной настройке моих точечных файлов. Мне лично нравится мой подход (и именно поэтому я его использую, да), но у каждого человека есть свой способ делать что-то. Я предлагаю вам проверить другие репозитории точечных файлов для вдохновения. Буду рад услышать о ваших подходах в разделе комментариев.
Для поддержки настройки все мои основные точечные файлы заканчиваются примерно так (вы можете найти пример моего .functions
файла здесь).
# This should be the last line of the file # For local changes # Don't make edits below this [ -f ".functions.local" ] && source ".functions.local"
По сути, каждый файл с именем .filename
(например) заканчивается чем-то вроде:
[ -f ".filename.local" ] && source ".filename.local"
Эта команда проверяет, существует ли файл с таким же именем файла, но с расширением .local
, и, если это так, создает его источник.
Поскольку это последняя строка файла, файл .filename.local
будет получен последним, поэтому все настройки и конфигурации, определенные в нем, сохраняются и могут отменять те, которые были помещены в другие файлы.
Это позволяет людям, экспериментирующим с моими точечными файлами, настраивать их, вообще не изменяя мой код! Аккуратно, а?
Кроме того, в моем .gitignore
игнорируются все .local
файлы.
Следующие шаги
На данный момент вы знаете почти все, что вам нужно знать об управлении точечными файлами, но есть несколько вещей, которые упускаются в этой и предыдущей статье:
- Настройка подсказки (это действительно искусство, и вы должны потратить на это время)
- Использование диспетчера файлов с точками, такого как dotty (или autodot, что я придумал)
Я бы порекомендовал изучить эти вещи, когда сможете.
Заключение
Это все, что касается этой серии статей по управлению точечными файлами. Мне бы хотелось услышать ваше мнение об этой статье и даже более того, чтобы увидеть, насколько творчески вы, ребята, подойдете к своим файлам точек. Напишите мне в комментариях, чтобы рассказать, как вам понравилась эта статья, и поделитесь любыми другими известными вам приемами управления точечными файлами. Кроме того, я буду очень рад, если вы уделите минуту, чтобы оставить отзыв о моих файлах точек или предложить улучшения с помощью проблем с GitHub.
Мне настолько понравилась идея файлов точек, что она вдохновила меня на создание базовой структуры управления файлами точек - autodot. Фреймворк находится в зачаточном состоянии, поэтому я ищу энтузиастов, которые могут дать мне отзывы о фреймворке, внести свой вклад в него, рассказав мне об ошибках и запросить функции, а также внести свой вклад в код и документацию. Выделите для этого немного времени! :)
Также свяжитесь со мной на GitHub и Twitter.
Удачи и удачного программирования! :)