Git за WordPress разработчици – понятия, команди и работен процес

Какво е Git и защо е от значение за WordPress

Git е разпределена система за контрол на версиите, създадена от Линус Торвалдс през 2005 г. за управление на Linux ядрото.

Всеки разработчик притежава пълно копие на хранилището, включително цялата история на промените. Това означава работа офлайн, бързи операции и липса на единична точка на отказ. За WordPress проекти Git дава възможност да проследявате всяка промяна в темата или плъгина, да се върнете към предишна версия при проблем и да координирате екипна работа без риск от презаписване на чужд код. Ако поддържате self-hosted WordPress инсталация, version control е задължителна част от работния процес.

Git записва моментни снимки (snapshots) на проекта, а не разлики между файлове. Всяка такава снимка се нарича commit и съдържа метаданни – автор, дата и съобщение, описващо промяната.

Инсталация и начална конфигурация

На повечето Linux дистрибуции Git идва предварително инсталиран.

# Проверка на версията
git --version

# Инсталация на Ubuntu/Debian
sudo apt-get install git

# Инсталация на macOS (чрез Homebrew)
brew install git

Задайте потребителско име и имейл веднага след инсталацията – Git ги записва във всеки commit:

git config --global user.name "Ivan Petrov"
git config --global user.email "[email protected]"

Тези данни се пазят в ~/.gitconfig. За конкретен проект махнете флага –global и конфигурацията ще важи само за текущото хранилище. Полезна настройка е и редакторът по подразбиране – ако предпочитате nano пред vim, изпълнете git config --global core.editor nano.

Repository – създаване и клониране

Хранилище (repository) е директория, в която Git следи промените.

# Инициализация на ново хранилище
git init my-theme
cd my-theme

# Клониране на съществуващо хранилище
git clone [email protected]:user/theme.git

git init създава скрита директория .git с цялата вътрешна структура – обекти, референции и конфигурация. git clone свежда копие на отдалеченото хранилище, включително пълната commit история. При WordPress проекти типичният подход е да инициализирате repository в директорията на темата или плъгина, а не в корена на цялата инсталация. Файлът .gitignore определя кои файлове Git да пропуска.

# .gitignore за WordPress тема
node_modules/
vendor/
*.log
.DS_Store
.env

Жизнен цикъл на файловете – status, add, commit

Файловете в Git минават през четири състояния: untracked, unmodified, modified и staged.

# Проверка на текущото състояние
git status

# Добавяне на конкретен файл в staging area
git add functions.php

# Добавяне на всички променени файлове
git add .

# Създаване на commit
git commit -m "Добавен custom post type за продукти"

staging area (или index) е междинна зона, която позволява да изберете точно кои промени влизат в следващия commit. Може да сте променили 10 файла, но да commit-нете само 3, ако останалите още не са готови. Commit съобщенията са критично важни – пишете ги кратко и конкретно на английски или български, но бъдете последователни. Добър формат е: глагол в повелително наклонение + описание на промяната, например „Fix header z-index on mobile“ или „Add WooCommerce cart fragment filter“.

Един commit трябва да съдържа логически свързани промени. Смесването на bug fix с нова функционалност в един commit затруднява code review и евентуален revert.

Branching – паралелна разработка без конфликти

Клоновете (branches) са най-ценният механизъм в Git.

Основният клон обикновено се казва main (или master в по-стари проекти). Всеки нов feature или bug fix започва в отделен branch, което изолира промените от production кода. Ако нещо се обърка, просто изтривате клона – main остава недокоснат. Тази стратегия е особено полезна при защитата на WordPress от непредвидени промени, защото позволява тестване преди deploy.

# Създаване и превключване към нов клон
git checkout -b feature/ajax-search

# Списък на всички локални клонове
git branch

# Превключване към съществуващ клон
git checkout main

# Изтриване на клон (след merge)
git branch -d feature/ajax-search

Именуването на клонове следва конвенция: feature/ за нови функции, fix/ за корекции, hotfix/ за спешни поправки в production. Тази структура помага при автоматизацията с CI/CD pipelines.

Merge и конфликти

Сливането (merge) обединява промените от един клон в друг.

# Превключване към main
git checkout main

# Сливане на feature клона
git merge feature/ajax-search

Ако един и същ ред от файл е бил променен и в двата клона, Git не може да реши автоматично кой вариант да запази. Това е конфликт. Git маркира проблемните участъци в самия файл:

<<<<<<set('posts_per_page', 12);
=======
$query->set('posts_per_page', 24);
>>>>>>> feature/ajax-search

Отворете файла, изберете правилния вариант (или комбинирайте двата), премахнете маркерите и завършете с git add и git commit. Конфликтите не са грешка – те са нормална част от екипната работа. Редовното сливане на main в работния клон (git merge main от feature branch-а) намалява обема на конфликтите.

Remote repository – push, pull, fetch

Отдалеченото хранилище (remote) е версията на проекта, която живее на сървър – GitHub, GitLab или Bitbucket.

# Добавяне на remote
git remote add origin [email protected]:user/theme.git

# Качване на промените
git push origin main

# Сваляне и сливане на промените
git pull origin main

# Сваляне без автоматично сливане
git fetch origin

git push изпраща локалните commit-и към remote-а. git pull е комбинация от fetch + merge – сваля новите данни и ги слива с текущия клон. git fetch е по-предпазлив вариант, който само сваля, без да променя работната директория. Проверявате какво е дошло с git log origin/main и решавате кога да слеете. При WordPress deploy от хакната или повредена инсталация възможността за бърз rollback чрез Git е критична.

.gitignore за WordPress проекти

Правилният .gitignore спестява проблеми от първия ден.

# WordPress core (ако следите само темата)
/wp-admin/
/wp-includes/
wp-*.php
index.php
xmlrpc.php
license.txt
readme.html

# Uploads и cache
wp-content/uploads/
wp-content/cache/
wp-content/upgrade/

# Конфигурация
wp-config.php
.htaccess
.env

# Dependencies
node_modules/
vendor/

# OS файлове
.DS_Store
Thumbs.db

wp-config.php съдържа пароли за базата данни и криптографски ключове – никога не го добавяйте в repository. Ако файлът вече е бил commit-нат, премахнете го от Git с git rm --cached wp-config.php, добавете го в .gitignore и направете нов commit. Историята все още ще го съдържа, така че при публични хранилища е необходимо допълнително внимание към сигурността на credentials.

Полезни команди за ежедневна работа

Няколко команди, които ускоряват рутинните задачи.

# Преглед на commit историята (компактен формат)
git log --oneline --graph --decorate -20

# Разлики спрямо последния commit
git diff

# Разлики за staged файлове
git diff --staged

# Отмяна на промените в конкретен файл
git checkout -- style.css

# Временно запазване на незавършена работа
git stash
git stash pop

git stash е изключително полезен при WordPress разработка – правите промени по темата, но трябва спешно да превключите към hotfix клон. Stash запазва текущото състояние без commit. След приключване на спешната задача git stash pop възстановява всичко. git log --oneline --graph визуализира branching структурата директно в терминала, което помага при разследване на проблеми след обновяване на PHP версията или друга инфраструктурна промяна.

Git workflow за WordPress екипи

За малки екипи (2-5 разработчици) работи добре опростен Git Flow модел.

main клонът винаги отразява production състоянието. Всяка задача започва от main като нов feature branch. След приключване на работата се създава Pull Request (PR) в GitHub или Merge Request (MR) в GitLab. Друг член на екипа прави code review, оставя коментари и одобрява. Едва тогава промените се сливат в main.

# Типичен работен цикъл
git checkout main
git pull origin main
git checkout -b fix/woo-checkout-validation
# ... работа по корекцията ...
git add .
git commit -m "Fix checkout field validation for Bulgarian phone format"
git push origin fix/woo-checkout-validation
# -> Създаване на Pull Request в GitHub

Автоматизираният deploy след merge в main (continuous deployment) премахва ръчното качване на файлове по FTP – подход, който при стартиране на нов проект може да изглежда излишен, но бързо се изплаща при растящ екип и чести промени.

Често задавани въпроси