↓ Перейти к основному содержимому
Олег Казанин

Git Workflow для Hugo блога

·5 минут· loading · loading ·
Шпаргалки Git Workflow Hugo Cheatsheet
Олег Казанин
Автор
Олег Казанин
Строю полезную инфраструктуру на Open Source стеке. Документирую грабли, чтобы вы на них не наступали.
Оглавление

Структура проекта
# 

~/projects/blog/              ← одна папка, две ветки
  ├── main                    ← production (blog.ru)
  └── dev                     ← development (dev.blog.ru)

Принцип: Одна папка, две ветки. Переключение через git checkout, не через разные директории.

Золотые правила
#

✅ ВСЕ изменения только через dev
✅ В main попадает только через git merge dev
✅ Никогда не редактировать находясь на main
✅ Всегда git pull перед началом работы
✅ Проверяй на dev окружении перед публикацией

❌ Не редактировать на ветке main
❌ Не делать git push --force в main
❌ Не забывать git pull перед merge

Префиксы для commit сообщений
#

Основные
#

feat: - новая функциональность

feat: новая статья про Kubernetes
feat: добавил комментарии

fix: - исправление ошибки

fix: опечатка в статье
fix: сломанная ссылка

style: - форматирование, стили

style: настроил CSS для тёмной темы
style: исправил отступы

docs: - изменения в документации

docs: обновил README

refactor: - рефакторинг без изменения функций

refactor: упростил структуру конфигов

chore: - рутинные задачи

chore: обновил зависимости
chore: удалил старые файлы

revert: - откат коммита

revert: "feat: добавил комментарии"

Дополнительные
#

perf: - улучшение производительности
test: - тесты
build: - изменения сборки
ci: - изменения CI/CD

Создание новой статьи
# 

cd ~/projects/blog

# Переключаемся на dev
git checkout dev
git pull origin dev

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

# Локальный предпросмотр
hugo server -D --bind 0.0.0.0

# Редактируем, сохраняем, проверяем в браузере

# Коммитим
git add .
git commit -m "feat: новая статья про X"
git push origin dev
# → Автосборка → dev.blog.ru

Публикация в production
# 

cd ~/projects/blog

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

# Переключаемся на main и мержим
git checkout main
git pull origin main
git merge dev --no-edit
git push origin main
# → Автосборка → blog.ru

Исправление опечатки
# 

cd ~/projects/blog

# ВСЕ изменения через dev!
git checkout dev
git pull origin dev

# Исправляем
nano content/posts/статья/index.md

# Коммитим
git add .
git commit -m "fix: опечатка в статье"
git push origin dev

# Проверяем на dev, если ОК - публикуем
git checkout main
git merge dev --no-edit
git push origin main

Обновление темы (Git submodule)
# 

cd ~/projects/blog

git checkout dev
git pull origin dev

# Обновляем тему
git submodule update --remote themes/название-темы

# Коммитим
git add themes/название-темы
git commit -m "chore: обновил тему"
git push origin dev

# Проверяем на dev, если ОК - публикуем
git checkout main
git merge dev --no-edit
git push origin main

Откат изменений
#

Когда откатывать vs когда делать fix
#

ОТКАТ → Эксперимент провалился:

  • Функция не работает
  • Стили сломали дизайн
  • Тестировал - не зашло

НОВЫЙ КОММИТ → Исправление правильного:

  • Опечатка в статье
  • Обновление информации
  • Улучшение формулировок

Вариант 1: Git revert (безопасный)
# 

# Смотрим последние коммиты
git log --oneline -5

# Создаём коммит который отменяет изменения
git revert HEAD
git push origin dev

Плюсы: История сохранена
Минусы: Создаёт дополнительный коммит

Вариант 2: Git reset (жёсткий откат)
# 

# Откатываемся на предыдущий коммит
git log --oneline -5
git reset --hard HEAD~1

# Принудительно пушим
git push origin dev --force

Плюсы: Чистая история
Минусы: Опасно, нужен --force

Откат несохранённых изменений
# 

# Откатить один файл
git checkout -- путь/к/файлу

# Откатить всё
git reset --hard HEAD

Проверка статуса
# 

# На какой ветке?
git branch
# * dev  ← текущая ветка

# Что изменилось?
git status

# История коммитов
git log --oneline -10

# Разница между dev и main
git diff main..dev

# График веток
git log --oneline --graph --all -10

Типичные ошибки и их решения
#

Случайно начал работать на main
# 

# Отменяем все изменения (НЕ коммитили)
git checkout -- .

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

Случайно сделал git add на main
# 

# Убираем из staging
git reset

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

# Добавляем правильно
git add .
git commit -m "feat: ..."
git push origin dev

Случайно закоммитил в main
# 

# Откатываем коммит (изменения остаются)
git reset --soft HEAD~1

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

# Коммитим правильно
git add .
git commit -m "feat: ..."
git push origin dev

Случайно запушил в main
# 

# Откатываем на main
git checkout main
git reset --hard HEAD~1
git push origin main --force

# Переключаемся на dev и делаем правильно
git checkout dev
git add .
git commit -m "feat: ..."
git push origin dev

Быстрые команды
# 

# Переключиться на dev и подтянуть изменения
git checkout dev && git pull origin dev

# Опубликовать dev в main
git checkout main && git pull origin main && git merge dev --no-edit && git push origin main

# Проверить доступность сайта
curl -I https://blog.ru
curl -I https://dev.blog.ru

Полезные алиасы для ~/.gitconfig
# 

[alias]
  st = status
  co = checkout
  br = branch
  ci = commit
  unstage = reset HEAD --
  last = log -1 HEAD
  visual = log --oneline --graph --all -10
  dev = checkout dev
  prod = checkout main

После этого можно:

git dev        # → git checkout dev
git prod       # → git checkout main
git visual     # → git log --oneline --graph --all -10

Стандартный workflow
# 

# 1. Начало работы
cd ~/projects/blog
git checkout dev
git pull origin dev

# 2. Создаём/редактируем контент
hugo new content posts/название/index.md
hugo server -D --bind 0.0.0.0

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

# 4. Проверяем на dev окружении

# 5. Публикуем в production
git checkout main
git pull origin main
git merge dev --no-edit
git push origin main

Помни: Dev для экспериментов, main для проверенного контента. Всегда тестируй перед публикацией.

Статьи по теме