Есть ли варианты организации работы с git ветками для менеджера?
Всем привет.
Ситуация следующая: есть проект над которым я работаю я - программист, менеджер и есть еще заказчик. Часто бывает так что 2 задача поступив на выполнение затрагивают один и тот же компонент системы. Наиболее удобно сделать для отдельной задачи отдельную ветку, что я и делаю. Поработав над задачей, сделав коммит и переключив ветку:
1. на сервере остаются файлы из первой ветки, и если я начну править файлы то возможны ошибки и придется сливать в первую ветку во вторую.
2. вполне вероятно что по итогу одна из задач может быть отменена и в продакшн не пойдет, а из -за этого приходится откатывать все до момента создания веток переносить код кусками.
3. Задачи в целом могут конфликтовать друг с другом и их по любому придется делать в разных ветка, а после выливать в мастер веку только одну.
Надеюсь тут все понятно объяснил.
Поэтому возникает вопрос можно и как-нибудь организовать переключение между ветками у менеджера и заказчика через какой-нибудь интерфейс таким образом, чтобы ветка менялась на сервере и они могли тестировать задачи не зависимо друг от друга.
Конечно при подходе к решению проблемы конфликта задач через гит возникнет проблема в структуре бд (хотя это не сильно критично в виду ооочень редкого внесения изменений в бд). Но вот более важная проблема в том, что при таком подходе если один участник меняет веку, то у другого она тоже сменится. Поэтому получается что у каждого участника должен быть свой репозиторий чтоли.
На мой взгляд лучше всего сделать примерно такое:
1. У каждого кто затронут в проекте есть свой репозиторий. Т.е. например у разработчика dev.awesome-project.ru, у менеджера manager.awesome-project.ru и т.д.
2. При изменении хотя бы одного репозитория они синхронизируются (кроме чекаута веток).
3. Они даже могут работать с одной базой все вместе.
4. Ну а дальше уже надо определить права доступа так чтобы все могли просматривать, чекаутить ветки, а коммитить, создавать, сливать, удалять ветки мог только разработчик. т.е. подобие acl.
Менеджеров и прочих гуманитариев в гит нежелательно пускать. Максимум - чтоб баги мог оформлять, но только ПО ШАБЛОНУ а не просто "у меня не работает, разберитесь, быдло") Остальное менеджерское говно пусть кипит в 1С и прочих трекерах, не связанных с продуктом.
Вячеслав Шевченко, это вопрос не технический, а идеологический. Технологии помогают только там, где есть четко формализованные процессы, или есть возможность повлиять на них с целью четкой формализации. Конфликты возникают там, где формальные правила подменяются "понятийными" (напр.: он блатной ему можно), либо там, где нет четко обозначенных входных и выходных параметров, т.е. на стыке зон ответственности.
Ответ на ваш вопрос: пусть начальство решает, а вы дождитесь письменно оформленного решения (чтоб потом никто не мычал что он не в курсе), и сделайте как вам говорят руководители. Потому что, еще раз повторяю, это вопрос нетехнический.
На самом деле, тут нет начальства. Мне никто не указывает на то, что надо это решать.
Я вижу что конфликт задач есть в процессе работы, хочу найти варианты решения и вынести на обсуждение эти варианты.
Вячеслав Шевченко, если не знаете как решить нетехнический конфликт в команде - избавьтесь от его источника. Поверьте, лучше выстрелить, перезарядить, и еще раз выстрелить, чем тупо спрашивать в темноту "кто там?"
и еще: Ружъе - лучшее лекарство, если таблетки не помогают. Это мне дед говорил.
Менеджер и заказчик не имеют доступа на запись в гит
Задачи ставятся через issue/task tracker
Деплой - автоматизирован и изолирован. Менеджер/заказчик говорит какую ветку он хочет посмотреть. Вы стартуете скрипт и он получает изолированную версию для работы
Изменения в код на тестовом сервере не вносятся. Его убивают вместе с БД
