Прямой ответ
Dotfiles-репозиторий превращает переезд на новую машину из выходных мучений в вечернюю задачу: конфиги shell, редактора, tmux, git хранятся в git, разворачиваются symlink-менеджером (проще всего GNU Stow) и bootstrap-скриптом, который ставит сам тулчейн. Минимальная структура:
dotfiles/
git/.gitconfig
tmux/.tmux.conf
zsh/.zshrc
nvim/.config/nvim/
vscode/settings-snippets/
bootstrap.sh # пакетные установки: brew/apt/winget
install.sh # stow-развёртывание ссылок
Что принципиально не кладётся в репозиторий: секреты и токены (.env, SSH-ключи, .aws/credentials) — их перенос описан в статье про секреты;машинно-специфичные пути выносите в локальный ~/.zshrc.local, которого нет в git.
Шаг 1. Инвентаризация: что вообще настраивать
Перед упаковкой составьте список того, что реально влияет на работу. Типовой набор разработчика: shell-конфиг (.zshrc/.bashrc + алиасы), git (.gitconfig с user.name/email и алиасами), редактор (VS Code: Settings Sync закрывает большую часть; Neovim — целиком каталог конфига), tmux, SSH-конфиг (без ключей — только ~/.ssh/config), списки пакетов (Brewfile, apt-mark show-manual, winget export), список глобальных утилит (npm ls -g, pipx list, go install-бинарники). Последний пункт чаще всего забывают — и именно он восстанавливается дольше всего.
Шаг 2. Stow: symlinks без самописных скриптов
GNU Stow раскладывает файлы из репозитория по домашнему каталогу ссылками:
git clone git@github.com:me/dotfiles.git ~/dotfiles
cd ~/dotfiles && stow git tmux zsh nvim
Механика: stow tmux берёт ~/dotfiles/tmux/.tmux.conf и создаёт ~/.tmux.conf → ~/dotfiles/tmux/.tmux.conf. Правите конфиг — правка сразу «в репозитории»; git status в папке dotfiles показывает дрейф конфигурации — недооценённая фича. Конфликты (файл уже существует) stow честно отказывается перезаписывать — это защита, а не баг.
Шаг 3. Bootstrap: тулчейн одной командой
bootstrap.sh ставит то, что нельзя symlink'нуть: пакетный менеджер, языковые тулчейны, глобальные утилиты:
#!/usr/bin/env bash
set -euo pipefail
command -v brew >/dev/null || /bin/bash -c "$(curl -fsSL )"
brew bundle --file="$HOME/dotfiles/Brewfile" # списочная установка
command -v rustup >/dev/null || curl --proto '=https' -sSf | sh -s -- -y
Для Windows-машины парный сценарий: winget export на старой машине → winget import на новой, плюс WSL-профиль внутри (ваш Linux-dotfiles разворачивается там же через stow). Принципы те же, что для любых скриптов автоматизации: идемпотентность, подтверждения на разрушительные шаги — в статье про скрипты рутины.
Чего в репозитории быть не должно
- Секреты: токены в
.gitconfig(credential.helper store!), API-ключи в алиасах, приватные ключи — частые случайные утечки; до первой публикации прогоните репозиторий gitleaks (инструмент и порядок действий при утечке — в той же статье про секреты). - Машинно-специфичное: пути к внешним дискам, корпоративные прокси — в
.local-файлы. - Гигантские бинарники: плагины и темы ставит bootstrap, не git.
- Личное и рабочее вперемешку: для рабочего профиля разумна отдельная ветка/репозиторий — при увольнении рабочая часть уходит чисто.
Переезд: порядок действий нового дня
Чек-лист вечера переезда: (1) система и обновления; (2) xcode-select --install / build-essential / Build Tools; (3) git и SSH-ключ — генерируете новый, старый не копируете (или копируете из зашифрованного бэкапа и сразу ротируете на сервисах, если старая машина выбывает); (4) clone dotfiles → bootstrap.sh → stow; (5) восстановление менеджера паролей и 2FA; (6) clone рабочих репозиториев; (7) Docker/СУБД и локальные сервисы. Первые четыре шага — час работы; остальное — данные, а не окружение. Развёрнутый чек-лист первой недели на новой машине — в статье про настройку нового ноутбука.
Привычка, которая окупается годами
Dotfiles живы, пока вы коммитите дрейф: поставили новую утилиту — добавьте в Brewfile/скрипт; поменяли алиас — закоммитьте. Раз в квартал прогоняйте мысленный тест «машина сгорела сегодня»: что не восстановится из git и бэкапов — то и есть ваши реальные дыры. Тест дешевле инцидента: практика показывает, что невосстановимым оказывается не код (он в remote), а именно окружение и доступы.
FAQ
Stow или chezmoi/yadm? Stow — минимализм без зависимостей; chezmoi добавляет шаблоны (одна конфигурация на macOS/Linux с различиями) и секреты через интеграции. Начните со stow, переходите при реальной потребности в шаблонах.
Что делать с Windows-конфигами (PowerShell, Terminal)?
Храните в том же репозитории: $PROFILE, settings.json терминала — раскладывайте скриптом вместо stow (на Windows-стороне); WSL-часть живёт по классической схеме.
Стоит ли держать dotfiles публичными? Публичный репозиторий — хорошая практика и портфолио, но только после gitleaks-проверки и вычистки корпоративных деталей (внутренние хосты, прокси).
Как быть с GUI-настройками (IDE, браузер)? Что синхронизируется штатно (VS Code Settings Sync, браузерные аккаунты) — оставьте штатным механизмам; в dotfiles кладите только экспортируемое (сниппеты, keymaps). Дублировать две системы синхронизации — источник конфликтов.
Структура, которая выдерживает годы
Практика показывает: dotfiles-репозиторий живёт годами, если соблюдены три принципа. Первый — одна программа = один каталог: git/, tmux/, zsh/ — stow-раскладка тривиальна, удаление инструмента = удаление каталога. Второй — секреты и машина снаружи: всё чувствительное через менеджер паролей и .local-файлы; репозиторий можно сделать публичным после gitleaks-проверки. Третий — bootstrap идемпотентен: повторный запуск скрипта на уже настроенной машине не ломает ничего — это же позволяет использовать его как документацию («что вообще стоит на моих машинах»).
Отдельный совет для владельцев нескольких машин (рабочая + личная): различия решайте условиями в скриптах и .local-оверлеями, а не ветками репозитория — ветки расходятся и гниют, условия видны сразу. И держите в репозитории короткий README: через год вы не вспомните, зачем нужен конкретный алиас, а подпись рядом с ним спасёт от удаления нужного.
Что делать с лицензиями софта при переезде? Часть коммерческих IDE и утилит привязана к машине: деактивируйте лицензию на старом ноутбуке до сброса, иначе слот лицензии сгорит. Составьте список платного софта заранее — это самый частый «сюрприз» переезда после SSH-ключей.
Как проверить, что dotfiles действительно работают? Прогоните установку на чистой VM или в контейнере с Ubuntu: bootstrap плюс stow должны поднять окружение без ручных правок. Такой тест раз в полгода ловит дрейф: устаревшие URL установщиков, удалённые пакеты, поломанные пути.
Нужно ли синхронизировать dotfiles между рабочей и личной машинами в реальном времени? Нет, и даже вредно: рабочая машина подчиняется политикам компании, личная — вашим привычкам. Общий репозиторий с выборочным stow по каталогам работает лучше любой синхронизации: каждая машина берёт то, что ей разрешено и нужно.
Источники: документация GNU Stow, git, Windows Terminal (ссылки в шапке).