Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 17
На данный момент это самый странный способ использования гита, который я видел. Гит при температуре сорок.
Пусть фрилансеры по мере готовности вмерживают свои коммиты из своих веток в ветку test и она автоматически раскатывается на тестовом окружении.
Таким образом появится контроль кто и что сделал или кто всё сломал.
Так а на каком сервере они будут работать? Когда ты закончил задачу - тогда конечно, вмержил ветки, они раскатались и т.д. но пока ты в процессе выполнения задачи тебе же надо свой код запускать - фрилансеры это делают сразу на тестовом окружении напрямую и как раз это и создает проблемы. Если на тестовом окружении уже файлы вручную правились то ничего там автоматически не раскатается :)
А уж тем более такое понятие как "свои ветки" сразу требует однозначно иметь свой личный dev-сервер. Если бы он был у фрилансера то и проблем бы не было никаких.
Фрилансеры могут одновременно тестировать свои наработки на тестовом стенде?
Ага, они так и делают. Самое главное - это распределить задачи чтобы они не пересекались "ты пилишь новый виджет в карточке товара, а ты иди поправь скрипт обмена с 1С". А учитывая что на проекте есть несколько сайтов + CRM система коробочная то там могут и 5 человек параллельно работать над разными задачами не пересекаясь. А развернуть хотя бы одну лишнюю/новую копию этого монстра может целый день уйти.
Очень похожая ситуация! Часто приходится: срочно и многократно делать мелкие правки или проверять экспериментальные функции прямо на сервере. И когда всё устаканивается, хочется синхронизировать через git pull, ан нет. Не даёт, потому что на сервере были ручные правки. В таких случаях действительно не хватает опции "Сделать пулл принудительно". Приходится возиться руками (часто выручает git stash).
В качестве оправдания - я единственный разработчик системы :)
Да, такая проблема встречается в маленьких проектах и при работе с разными фрилансерами. Она возникает из-за того, что сервер одновременно используется, как рабочее место и как место для деплоя. В итоге там появляются ручные правки, незакоммиченные изменения и код из Git, и всё это начинает конфликтовать при git pull. Ваш скрипт в этом случае нормальное практическое решение. Он просто автоматизирует ручные шаги, которые иначе приходится делать каждый раз. Но по сути это не проблема Git, а проблема организации процесса. В более правильной схеме код не правят на сервере, а изменения попадают туда только через деплой из репозитория. Тогда никаких конфликтов при pull просто не возникает.
git stash && git pull && git stash pop ?
[root@test2 test]# git stash && git pull && git stash pop
(.....)
error: The following untracked working tree files would be overwritten by merge: gradlew
Please move or remove them before you can merge.
Aborting
А, я не учел, что еще и новые файлы создаются.
Корень проблемы в том, что изменения вносятся сразу в двух местах, и эти изменения надо как-то синхронизировать, а они могут различаться (и однажды не совпадут).
Я бы изменения на стейдже просто сбрасывал раз в сутки, и подтягивал dev ветку. Кто не успел закоммитить свою фичу, тот опоздал.
git reset --hard origin master && git pull
Сбрасываем изменения на сервере, потом пулим.
Вообще делать изменения на сервере очень и очень плохая практика, настройте автоматический деплой из гитхаба/гитлаба, это не так сложно
git reset сбросит все изменения на сервере. А там есть изменения которые еще не закомичены и которые не надо сбрасывать. В других скриптах над которыми еще ведутся работы.
Да, я полностью согласен с вами что это плохая практика о чем и написал в самом начале статьи. Чтобы иметь автоматический деплой нужно иметь где-то рабочую копию проекта на которой непосредственно будет работать разработчик (в идеале на локалке у самого разработчика) а тут такой нет (почему ее нет и в чем проблема ее сделать описал в статье)
Статью не читал, но по комментариям хочу спросить.
git pull --force --autostashЧем не выход?
Просто мысли в слух... Что если на тестовом сервере создать отдельные git worktree для каждого разраба, а девопс создаст отдельные сабдомены тестового сервера для каждого разраба и настроит их так, чтобы при обращении к ним сначала читались файлы из worktree соответствующего разраба, а если не найдены, то уже из папок сервера? Тогда у каждого разраба будет свое место для экспериментов. Так главный worktree будет всегда в нормальном состоянии, для тех, кто не хочет работать по вашей схеме.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Git pull force — такой команды нет в гите, но мне пришлось ее сделать