astronit
/
oakazanin
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
oakazanin/content/posts/blog-part-4-git-workflow/index.md

14 KiB
Raw Blame History

title date draft description tags categories series series_order
Блог на Hugo в K3s: часть 4 - выбор Git workflow 2026-02-16 false Две папки или одна с переключением веток? Разбираем варианты организации работы с dev и production окружениями на практических примерах.
git
workflow
devops
hugo
Веб-разработка
DevOps практики
Блог на Hugo в K3s
4

В части 3 мы развернули два окружения - production и development. Один репозиторий, две ветки (main и dev), два пайплайна.

Теперь встаёт вопрос: как организовать работу локально?

Проблема

У нас есть:

  • Репозиторий в Gitea
  • Две ветки: main (production) и dev (development)
  • Необходимость постоянно переключаться между ними

Как это делать на локальной машине? Два варианта.

Вариант А: Две отдельные папки

Клонируем репозиторий дважды - в разные папки:

~/projects/
├── blog/        ← ветка main (production)
└── blog-dev/    ← ветка dev (development)

Логика: Хочу работать с dev - иду в blog-dev. Хочу что-то проверить в production - иду в blog. Без переключения веток.

Кажущиеся преимущества

Параллельная работа. Можно держать открытыми два терминала - в одном hugo server для dev, в другом смотреть production код.

Изоляция. Каждая папка - своя песочница. Изменения в одной не влияют на другую.

Простота навигации. cd blog-dev вместо git checkout dev. Меньше команд.

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

Реальные проблемы

Проблема 1: Рассинхронизация локальных ветокin

Работаю в blog-dev - пишу статьи, коммичу, пушу в origin/dev. Всё хорошо.

Но локальная ветка dev в папке blog при этом не обновляется. Она отстаёт от origin/dev.

Приходишь делать merge:

cd blog
git checkout main
git merge dev
# Already up to date.  ← НО есть НЮАНС!

Git говорит "всё актуально", имея в виду локальную ветку dev, которая отстала на три коммита. Статьи не попадают в production.

Приходится помнить делать git pull origin dev перед каждым merge. Забыл - публикуешь устаревшую версию.

Проблема 2: Конфликты при merge

Редактируешь config/params.toml в обеих папках независимо:

  • В blog-dev добавил Firebase конфиг
  • В blog изменил название сайта

При merge Git честно сообщает о конфликте:

CONFLICT (content): Merge conflict in config/params.toml

И это повторяется каждый раз когда трогаешь конфигурацию. Потому что две папки - это две независимые истории изменений одного файла.

Проблема 3: Работа не в той папке

Несколько раз ловил себя на том что редактирую статьи прямо в blog - папке production. Это нарушает весь смысл раздельных окружений.

Проблема 4: Умственная нагрузка

Постоянный вопрос "в какой папке я сейчас?" Для простого блога это лишняя когнитивная нагрузка.

Вариант Б: Одна папка с переключением веток

Один клон репозитория, работа через git checkout:

~/projects/
└── blog/    ← одна папка, две ветки: main и dev

Как это работает

Пишу статью:

cd ~/projects/blog

# Переключаюсь на dev
git checkout dev

# Проверяю что dev актуален
git pull origin dev

# Запускаю локальный сервер
hugo server -D --bind 0.0.0.0

# Создаю статью
hugo new content posts/название/index.md

# Коммичу и пушу
git add .
git commit -m "feat: новая статья"
git push origin dev

Публикую:

# Убеждаюсь что dev актуален
git checkout dev
git pull origin dev

# Переключаюсь на main и мержу
git checkout main
git pull origin main
git merge dev
git push origin main

Реальные преимущества

Никакой рассинхронизации. Все ветки в одном репозитории. git pull обновляет всё что нужно.

Нет конфликтов из-за независимых изменений. Когда работаешь в одной папке, params.toml существует в одном экземпляре. Все изменения делаются в dev, в main попадают только через merge.

Конфликт возможен только если кто-то редактирует main напрямую - а это нарушение workflow.

Невозможно ошибиться с веткой. git branch показывает где ты сейчас. Случайно отредактировать файлы в main - сложнее.

Меньше места на диске. Один клон вместо двух. Один .git вместо двух.

Сравнение на практических примерах

Пример 1: Обновление темы Blowfish

Две папки:

cd blog-dev
git submodule update --remote themes/blowfish
git add themes/blowfish
git commit -m "update: Blowfish theme"
git push origin dev

# Проверяешь на dev.blog.ru
# Если всё ок - мержишь
cd ../blog
git checkout dev
git pull origin dev  # ← ЛЕГКО ЗАБЫТЬ
git checkout main
git merge dev
git push origin main

Одна папка:

cd blog
git checkout dev
git pull origin dev
git submodule update --remote themes/blowfish
git add themes/blowfish
git commit -m "update: Blowfish theme"
git push origin dev

# Проверяешь на dev.blog.ru
# Если всё ок - мержишь
git checkout main
git pull origin main
git merge dev
git push origin main

Меньше команд, меньше переходов между папками, меньше шансов забыть git pull.

Пример 2: Правка опечатки в production

Нашёл опечатку на blog.ru. Нужно исправить быстро.

Две папки:

Опасность: хочется исправить прямо в blog (ветка main). Это нарушает workflow - все изменения должны идти через dev.

Правильно:

cd blog-dev
git checkout dev
# Исправляешь
git commit -m "fix: опечатка"
git push origin dev
cd ../blog
git checkout main
git pull origin dev  # ← опять легко забыть
git merge dev
git push origin main

Одна папка:

cd blog
git checkout dev
git pull origin dev
# Исправляешь
git commit -m "fix: опечатка"
git push origin dev
git checkout main
git merge dev
git push origin main

Проще, меньше команд, понятнее.

Пример 3: Долгая работа над статьёй

Пишешь большую статью несколько дней. Между сеансами работы кто-то (или ты сам) запушил другие изменения в dev.

Две папки:

cd blog-dev
# День 1: пишешь
git add .
git commit -m "wip: статья"

# День 2: продолжаешь
git pull origin dev  # Подтягиваешь чужие изменения
# Пишешь дальше
git add .
git commit -m "feat: закончил статью"
git push origin dev

Всё так же как и с одной папкой. Разницы нет.

Одна папка:

cd blog
git checkout dev

# День 1: пишешь
git add .
git commit -m "wip: статья"

# День 2: продолжаешь
git pull origin dev  # Подтягиваешь чужие изменения
# Пишешь дальше
git add .
git commit -m "feat: закончил статью"
git push origin dev

Идентично. Этот пример работает одинаково в обоих вариантах.

Что выбрать?

Если ты только начинаешь - сразу делай одну папку.

Две папки кажутся удобными, но создают проблемы которые регулярно прерывают работу:

  • Рассинхронизация веток
  • Конфликты при merge
  • Когнитивная нагрузка

Одна папка с переключением веток - стандартный Git workflow, проверенный миллионами разработчиков. Требует чуть больше дисциплины (git checkout dev вместо cd blog-dev), но избавляет от всех проблем выше.

Золотое правило: Никогда не редактировать файлы находясь на ветке main. Все изменения - через dev. Всегда.

Миграция: если начал с двух папок

Если уже работаешь в двух папках - переход простой.

Шаг 1: Убеждаемся что всё запушено

# Проверяем обе папки
cd ~/projects/blog-dev
git status
git push origin dev

cd ~/projects/blog
git status
git push origin main

Шаг 2: Синхронизируем ветку dev в основной папке

cd ~/projects/blog

# Обновляем локальную ветку dev из remote
git checkout dev
git pull origin dev

# Проверяем что всё актуально
git log --oneline -5

# Возвращаемся на main
git checkout main

Шаг 3: Удаляем вторую папку

# Убеждаемся что в blog-dev нет несохранённых изменений
cd ~/projects/blog-dev
git status
# Должно быть: nothing to commit, working tree clean

# Удаляем папку
cd ~/projects
rm -rf blog-dev

Шаг 4: Проверяем что всё работает

cd ~/projects/blog

# Переключаемся на dev и запускаем сервер
git checkout dev
hugo server -D --bind 0.0.0.0

# Открываем http://localhost:1313/
# Видим dev версию сайта

Новый workflow: шпаргалка

Создаю статью

cd ~/projects/blog

git checkout dev
hugo new content posts/название/index.md

# Пишу, сохраняю, проверяю в hugo server
git add .
git commit -m "feat: название статьи"
git push origin dev  # → dev.blog.ru

Публикую статью

git checkout dev
git pull origin dev  # Убеждаюсь что dev актуален

git checkout main
git pull origin main  # Убеждаюсь что main актуален
git merge dev
git push origin main  # → blog.ru

Меняю конфигурацию

git checkout dev  # ВСЕ изменения только через dev!
nano config/params.toml
git add .
git commit -m "feat: изменил конфиг"
git push origin dev  # Проверяю на dev.blog.ru

# Если всё ок
git checkout main
git merge dev
git push origin main

Что дальше

Workflow выбран, окружения работают. Можно писать статьи.

Но есть ещё одна тема которую стоит разобрать - что делать когда что-то сломалось. Как диагностировать проблемы когда сайт вдруг начал отдавать 503, или SSL перестал работать, или webhook не срабатывает.

В следующей части покажу процесс диагностики на реальном примере - как я чинил blog.ru когда он внезапно стал недоступен из интернета.

Рекомендация этой части:

  • Одна папка ~/projects/blog
  • Переключение веток через git checkout
  • Все изменения через dev → merge в main
  • Никогда не редактировать находясь на main