Скопировать файлы, а потом рестартануть сервис через ssh - это конечно мило, но хотелось бы какое-то универсальное/расширяемое/отраслевое решение. Да, часто проще - это лучше, но хочется открыть для себя какую-то новую область знаний...
PS: Кстати, на вашем месте я бы не устанавливал шесть соединений, а скопировал файлы во временную папку, потом запустил удаленный скрипт, который бы сразу остановил сервис, скопировал файлы из временной папки и запустил сервис снова.
Потому что не нужно
1. Устанавливать node на сервере
2. Следить за обновлением самого node, npm и т.п.
3. Обновлять пакеты.
Это не очень приятно, когда при компиляции оказывается что нужно обновить пакеты, а обновляя пакеты оказывается что они не ставятся, т.к. нужно обновить npm.
Александр, поэтому я и посоветовал вам делать merge, а не rebase. Это гораздо безопаснее (точнее проще отменить), хотя, если честно, git позволяет вернуться к любому коммиту, даже если он уже пропал.
Все правильно.
Еще раз: изменения происходят с той веткой, на который вы находитесь. Поэтому чтобы двигать dev_sasha, вы должны на ней находиться в момент выполнения rebase. Вот и все.
Первую и вторую команды можно поменять местами или даже удалить вторую (тогда будет двигаться текущая ветка).
Одной командой можно - используйте alias.
Кроме того, можно использовать параметризованный alias для перемещения любой ветки. https://githowto.com/ru/aliases https://stackoverflow.com/a/25915221/2295915
git pull стягивает все remote ветки, но именно потому что вы работаете один в своей ветке он вам не поможет разрешить конфликты. Посмотрите главу, на которую я дал ссылку, там именно об этом.
Вы должны понять главное, git pull - это стягивание и слияние отслеживаемой ветки (т.е. публичной, той, которая лежит удаленно). Эта команда никак не повлияет на вашу ветку dev_sasha, поэтому толку от нее для вас не будет. Подробнее: https://git-scm.com/book/ru/v2/%D0%92%D0%B5%D1%82%...
Имейте также в виду, что в подавляющем большинстве случаев изменение происходят с той веткой на которой вы находитесь. Остальные ветки при этом никак не затрагиваются. Т.о. на шаге 2 вместо merge вы можете передвинуть свою ветку на голову master командой git rebase master. Результат будет тот же, но история коммитов вытянется в прямую линию.
maiskiykot, это значит что в мире не менее 76000 идиотов, причем для большинства из них английский - родной.
Проверил "баг" на своих сайтах - как и полагается 404.
Я, кстати, иногда еще на .env ставлю права 660, чтобы левый ssh-пользователь не подсмотрел пароли.
переключаться на локальный мастер (стешить изменения)
Вы хотите трекать удаленный мастер в левую ветку, чтобы кодить в локальном мастере?
Мне кажется что вы делаете что-то не так... используйте локально другую ветку вместо master, если вы его меняете.
А какая разница сколько там коммитов? Сделайте описание в духе "добавил то-то и то-то" и забудьте.
Хорошо если вы один работаете, а если нет, то коллеги вас за git push --force должны без мыла отблагодарить.
Если вы через неделю опомнитесь что что-то забыли тогда как? Полный rebase всех исходников?
Кстати, рекомендую вам установить редактор SublimeText и плагин к нему GitSavvy - это самый наглядный и простой способ работы с git. Там наглядно можно добавлять в stage файлы как целиком, так и фрагментами (или даже построчно), смотреть что уже в stage и т.п.
GitSavvy - это самый крутой плагин для работы с гит. И главная крутость его в наглядности.
Да, я в том числе и об этом написал.