Valerii Yevdochenko

git chery-pick - ты забираешь комиты из одной ветки в другую, это бывает полезно когда изменения сделаные другим разработчиком в его ветке, прямо сейчас нужны тебе в твоей ветке, и что бы не писать этот код заново, ты забираешь его комит себе в ветку

git rebase master - ты синхронизируешься с главной веткой в которую коммитят все разработчики проекта, это полезно когда кто-то изменил участок кода с которым ты сейчас работаешь в своей ветке, дабы через неделю ты смог без проблем смержиться с master веткой. Обычно делается каждое утро перед началом рабочего дня и в конце когда фича готова.

git merge - обычно используется когда у вас 2 и более master ветки (к примеру master и prototype) в этих ветках очень много комитов (и rebase здесь не подходит) и обчно через пару недель, maintainer репозитория наработки из prototype ветки "сливает" в master ветку по средствам этого самого git merge

P.S. Что бы легче предствить разницу между git merge и git rebase. Представь что merge как собачка на молнии у одежды - "сшивает" комиты по дате их создания.
В то время как git rebase как пожарная лестница - при применении твои коммиты крепится на конец родительской ветки

git merge используйте для мержа фич и фиксов в master ветку (как и делает это Github)
а git rebase используется для своей ветку в которой вы работаете над фичей что бы забрать последние изменения с master ветку (для этого есть очень удобная команда `git pull --rebase origin master`, аналог 3х команд (`git checkout master; git pull origin master; git checkout mybrach; git rebase master`)

Базу данных лучше обновлять через WP-CLI.
Установка:

$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ chmod +x wp-cli.phar
$ sudo mv wp-cli.phar /usr/local/bin/wp

Таск для экспорта-импорта и подмены домена в базе пишется за минуту:

desc('Export-import database');
task('database', function () {
runLocally('wp db export wp.sql');
upload('wp.sql', "{$deploy_path}/wp.sql");
run('wp db import wp.sql');
run('wp search-replace //example.dev //example.com');
});

Код накидал на скорую руку, естественно нужно добавить переменные путей, задать подменяемые домены и так далее. Предполагается что на серваке и на локалке WP-CLI установлен и откликается на аббревиатуру wp из командной строки. Ну и нельзя забывать, что WP-CLI работает только из корневой папки сайта с Wordpress. Можно задать другую папку, положив в корень сайта файлик: wp-cli.yml. Для автмоатического деплоя базы нужно выгружать в репу свежий wp.sql. Тогда команда экспорта отпадает за ненадобностью.
Проблема на самом деле только в загрузке папок с аплоадом. Автоматика предполагает, что деплой работает при наступлении некоего события в репозитории проекта, а сам процесс деплоя происходит на виртуальной машине, у которой нет доступа к аплоаду, так как его нет в репозитории. Если отправлять сразу с локалки, что назовем полуавтомат(пример таска выше), то задача упрощается в разы, но на Винде придется помучиться с загрузкой.

Ни в коем случае не ставить никаких ISP Manager / Vesta / CPanel, иначе никогда не научитесь тому, чему хотите научиться. Кроме того, они жрут ресурсы. Даже Vesta, которая самая легкая, их жрет прилично, а я сильно сомневаюсь, что у вас VPS c 8+ Gb памяти.

Изучать надо по урокам и статьям, читая мануалы и best practices по каждому package. Порядок, плюс-минус, таков:

- развернули ось
- сделали сразу апдейты
- создали и настроили swap
- поменяли пароль рута на что-нибудь супер-мега-сложное (его мы использовать все равно не будем)
- создали себе обычного юзера с паролем нормальной сложности (он будет использоваться для sudo)
- дали юзеру права sudo
- закрутили гайки по SSH - сменили порт, запретили вход руту и вход по паролю (только по ssh-ключам), разрешили вход только одному своему новому логину
- настроили UFW - простой, но эффективный firewall на основе iptables - default deny, allow http, https, свой кастомный ssh-порт. Если логиниться будете только из нескольких мест (офис, дом) - можно вообще ssh разрешить только на эти IP.
- sudo dpkg-reconfigure tzdata чтобы установить свою временную зону, так логи потом легче читать и понимать
- настроили logrotate
- настроили logwatch
- настроили Postfix, чтобы сервер вам письма мог слать (мы его настраиваем на внешний мейлер, например Mandrill, чтобы все письма точно в спам не падали)
- настроили fail2ban (потом, после установки и настройки веб-сервера и сайтов, в fail2ban можно дополнения писать, например мы на WordPress-сайтах мониторим попытки авторизации в админку и блочим тем же fail2ban)
- дальше ставим все что нужно - Git, Nginx, HHVM, PHP5-FPM, MariaDB, Memcached/Redis и так далее.

Регулярно заходите на сервер, делайте apt-get update && apt-get dist-upgrade.

p.s.: это по ubuntu/debian, для других систем все то же самое, но packages и команды могут немного отличаться

По поводу оптимизации Wordpress сайта.
1) Сверяйте данные не только по pagespeed, но и по gtmetrix (pagespeed). Иногда то чего не написано в гугле, видно в gtmetrix.
2) Если хотите получить 100% (хотя смысла в этом особого и нету), то установите следующий набор плагинов:
- WP Fastest Cache
- WP Fastest Cache Premium
- Autoptimize
В плагине WP Fastest Cache & Premium выставьте все, кроме сжатие CSS, суперсжатие CSS и объединение CSS
https://screenshots.firefox.com/NldB7mfjBaLXl6aj/b...
В плагине Autoptimizе включите сжатие CSS и в продвинутом режиме настройте необходимое
https://screenshots.firefox.com/AoeDjQZyKcLcdGF7/b...
3) Создайте критичный CSS и добавьте ее в Autoptimize. Ссылка на генератор
https://jonassebastianohlsson.com/criticalpathcssg...
4) все внешние скрипты (чтобы гугл не жаловался) отдавайте локально (не через CDN и т.д.). Т.е. Все скрипты, которые использует Метрика, Фейсбук, Рамблер Топ 100 и т.д. нужно скачать и залить в папку js в корне сайта.
5) Создайте рнр файл со следующим содержимым:
Например,

<?php
function downloadJs($file_url, $save_to)
{
    $content = file_get_contents($file_url);
    file_put_contents($save_to, $content);
}
// Yandex Metrika
downloadJs('https://mc.yandex.ru/metrika/watch.js', realpath("./js") . '/watch.js');
// Yandex Share
downloadJs('https://yastatic.net/es5-shims/0.0.2/es5-shims.min.js', realpath("./js") . '/es5-shims.min.js');
downloadJs('https://yastatic.net/share2/share.js', realpath("./js") . '/share.js');
// Google Analytics
downloadJs('https://www.google-analytics.com/analytics.js', realpath("./js") . '/analytics.js');
// Googla Adsense
downloadJs('http://pagead2.googlesyndication.com/pagead/show_ads.js', realpath(".js") . '/show_ads.js');
downloadJs('https://pagead2.googlesyndication.com/pagead/osd.js', realpath("./js") . '/osd.js');
downloadJs('https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js', realpath("./js") . '/adsbygoogle.js');
// VK
downloadJs('http://vk.com/js/api/openapi.js?139', realpath("./js") . '/openapi.js');
// Google Plus Widget
downloadJs('https://apis.google.com/js/plusone.js', realpath("./js") . '/plusone.js');
// Google Recaptcha
downloadJs('https://www.google.com/recaptcha/api.js', realpath("./js") . '/api.js');
downloadJs('https://www.google.com/recaptcha/api2/webworker.js', realpath("./js") . '/webworker.js');
// Rambler Top100
downloadJs('http://st.top100.ru/top100/top100.js', realpath("./js") . '/top100.js');
//Mail.ru
downloadJs('https://top-fwz1.mail.ru/js/code.js', realpath("./js") . '/code.js');
//Facebook Pixel
downloadJs('https://connect.facebook.net/en_US/fbevents.js', realpath("./js") . '/fbevents.js');
?>

6) После этого измените пути в подключаемых скриптах на локальные, скачанные вами ранее.
7) Чтобы скрипты корректно работали, создайте CRON задачу и обновляйте вышеуказанные скрипты (путем запуска созданного вами рнр файла ежедневно или еженедельно).
Результат: 99/99
https://screenshots.firefox.com/eDaB6gUb9DD2szZj/d...
https://screenshots.firefox.com/PuzE8P0EN1sKvEVg/d...

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

Ах да, "ненужные" скрипты и стили плагинов можете отключить через functions.php, А некоторые скрипты и стили плагинов можете агружать избирательно на нужно странице, категории и т.д. Тоже помогает.

Ну и конечно же CDN никто не отменял. Например, cloudflare (бесплатно) или maxCDN

Ставьте linux (ubuntu, mint - хорош для первого знакомства после винды) и docker. Я когда пересаживался с винды искал аналоги openserver, пробовал vagrant, phpbrew - всё крайне не удобно. Потом рассказали про docker и сразу влюбился. Чуть позже написал небольшой скриптик, с помощью которого одной командой можно развернуть любое веб-окружение: php 5.6-7.3, apache/nginx, mysql 5.6-5.7 и через несколько минут появится рабочий локальный сайт. Если заинтересует могу дать ссылку на github