Hundredth question on git for web development by the team, is it really how everyone works?

Question

git

There is a small web studio in which development is carried out completely without versioning.
The guys work like this: there is a dev server, a prod server, and each developer edits files on the dev server via FTP and, after approving, they upload these files to prodaction.
When I mentioned git - I was asked how I imagine this system in this approach to development - and I stumbled.
The general principle of team development is described on the Internet as follows: each developer has a local copy of the site, from there they push to the dev branch, then merge with the master and pull to the production server. But the studio has a lot of support projects. And suppose a task flies in for 2 minutes, to fix something in the layout - for this you need to merge the entire site, with the base and content to the developer (suppose that the layout is bad on certain content)?
PS: forgive me for raising this question again, it has already been hobbled on the toaster more than once, but does everyone really work like that?

Answer 1

Ответ на все ваши вопросы - git flow
habrahabr.ru/post/106912
Ну а применительно к вашей ситуации, то все просто - начните с себя.
Получили новый проект - используйте git.
На ваш проект подключают нового специалиста - приучайте его к git.
Кто-то сделал правки и не внес их в git - безжалостно грохайте их и показывайте менеджеру, что судя по логу никаких правок этот человек не сделал.
После этого вас быстро уволят из этой студии и вы уже будете знать, что при собеседовании надо ОБЯЗАТЕЛЬНО узнавать, используют ли они git (ну или что там еще для вас важно).

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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