Сотый вопрос по git для web разработки командой, неужели все так работают?

Question

[L0k1]

Есть небольшая веб студия, в которой разработка ведется совершенно без версионности.
Работают ребята так: есть dev сервак, prod сервак и каждый разработчик по фтп правит файлы на dev серваке и после апрува - выливают эти файлы на prodaction.

Когда я заикнулся про git - меня спросили как я представляю эту систему при данном подходе к разработке - и я запнулся.
Общий принцип командной разработки описан в интернетах так : у каждого разработчика локальная копия сайта, оттуда пушат в дев ветку, потом мердж с мастером и pull на прод сервак. Но у студии очень много проектов на саппорте. И предположим влетает таска на 2 минуты, поправить что-нибудь в верстке - для этого надо сливать разработчику весь сайт, с базой и контентом(предположим, что верстка бажит на определенном контенте)?

PS: простите, что я опять поднимаю этот вопрос, на тостере его уже мурыжили не раз, но неужели действительно все так работают?

Comments

[lexnekr]

В вашем случае можно ведь для каждого проекта завести свой репо. Для каких-то старых проектов с устоявшимся процессом и тугими людьми в начале не использовать вовсе.

Ставите гит на прод, дев и на локальные машины тем, кто разрабатывает.

Появилась большая задача - делаете локально, потом пулл на дев, там тестируете, апрувите, пулл на бой.
Если кто-то другой работает с этим же проектом (и внёс правки уже локально) и пытается сделать пулл, то получит сообщение о необходимости мерджа. Мердж делаете силами того, кто аппрувит изменения, например (чтобы был ответственный за это).

Появилась мелкая СРОЧНАЯ задача - делаете её на бою. Потом делаете пуш на дев с боя (а так же на локальные машины).

Так же периодически разработчики пушат себе на локальные машины изменения с дева/боя.

Процесс пуша/пулла пересылает только изменения. Поэтому если вы поправили 1 файл в вёрстке, то проходит фактически мгновенно и безболезненно.

ЗЫ если в разных коммитах правились разные файлы, то мердж может вообще происходить автоматически. Но поскольку они могут влиять на общий функционал, то лучше всё же чтобы был ответственный за мердж.

[L0k1]

lexnekr: Спасибо. Становится немного яснее.

Answer 1

[smanioso]

Ответ на все ваши вопросы - git flow
habrahabr.ru/post/106912

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

После этого вас быстро уволят из этой студии и вы уже будете знать, что при собеседовании надо ОБЯЗАТЕЛЬНО узнавать, используют ли они git (ну или что там еще для вас важно).

Comments

[L0k1]

Спасибо за ссылку. Я ее находил, но мне хотелось бы, чтобы мне разжевали. Я бы с удовольствием начал с себя, по-этому и обратился с вопросом.

Бэкендщик запилил функционал на тесовом движке, там используется в качестве шаблонизатора smarty. По-этому фронтендщик по фтп работает на том же сервере и пилит *.tpl`ки.. Нельзя локально у себя шаблоны верстать в отрыве от движка, что опять возвращает к тому, что надо выкачивать весь проект.

[smanioso]

L0k1: и как это связано с git? Если надо весь - выкачивайте весь.

[L0k1]

smanioso: Так вот в этом и есть мой изначальный вопрос: Можно ли как-то работать, без полной локальной копии проекта? Или нельзя и у компаний, у которых по 200 проектов на поддержке - у каждого разработчика по 200 проектов развернуто на локалках, включая базу и контент (база и контент, опять же, если нужно для конкретной правки)?

[smanioso]

L0k1: ну вот в этом и проблема - вы под тегом git задаете вопросы по архитектуре.
Решений масса:
- разворачивать все локально,
- работать на одном dev-серваке удаленно,
- запускать на удаленном, но править на локальном только 1 каталог и синхронизировать средствами IDE,
- ....

Но это уже никак не связано с git.

Answer 2

[Максим Гречушников]

2 минутные правки делаю на продакшне и пушу с него

Answer 3

[Евгений]

Что за бред, зачем базу-то сливать? Как шаблон в котором верстка от нее зависит?

Comments

[L0k1]

ну это был абстрактный пример, пусть это будет 8 пункт меню который не влазит, а меню зависит от базы или еще что-нибудь, не цепляйтесь к конкретике - меня сама суть интересует

Answer 4

[asd111]

В веб студиях обычно не используют git.

Answer 5

[Станислав Задирака]

Тоже работаю в студии, несколько раз пробовал работать с гитом.
Пока он не ликвиден в нашей работе, но интерес есть.
Пока мысли примерно такие - для проекта на поддержке, с мелкими правками, гит не применим. А вот для проектов полной разработки до момента окончательного релиза вполне себе интересен.
По поводу выкачивания всего проекта...
Вопрос ядра, если вы развиваете проекты на определенных фреймворках или CMS, то ядра можно хранить отдельно на компах разработчиков и подгружать только то что вы меняете.
Для бд - оно в Гите не участвует и обычно задача программиста не сильно пострадает если в бд окажутся данные прошлого месяца, а один раз за большую задачу загрузить к себе дамп не оч сложно, можно и скриптом. Если в бд были изменены настройки проекта, а не просто контент, можно заставлять программистов делать миграции (скрипт, который меняет эти опции через АПИ). Если cms предполагает статичные страницы с контентом, их из Гита лучше исключить , пусть контентщик на бою их правит вместе с контентом в бд.