Командная работа в Git

Появился один такой, но глобальный вопрос по поводу построения архитектуры git для командной работы 2-х людей над сайтом.

Суть такая, есть сайт у которого имеется рабочая копия (test.example.ru), с которой работают 2 программиста. Они пишут новые фичи и заливают на example-test.ru для тестирования там функционал и если всё ок, это потом перекидывается в продакшн (example.com).

Так вот такой вопрос по поводу архитектуры, как её лучше организовать, чтобы избежать багов и глюков и сделать максимально прозрачной?

У меня такие варианты:

1. Разработчики подключаются к репозиторию тестовой копии сайта, клонируют его и дальше уже работают непосредственно с master веткой, делая commit и push чтобы увидеть изменения и проверить функциональность, в случае, если что-то поломалось в плане функциональности, программист это чинит и делает ещё раз commit, push и вновь проверяет всё ли ок.
— У такого подхода мне видятся несколько сложностей, во-первых вообще никак не используется ветвление, а во вторых, если один из программистов что-то поломал, сам того не подозревая, и залил изменения, то у второго программиста, тестовой копии сайта всё поломается тоже.

2. Сделать 2 тестовых копии сайта (по каждой на разработчика). Тут уже каждый сможет на своё усмотрение ломать, и ветвить как ему заблагорассудится. Но я смутно себе представляю такую архитектуру.

3. Делать ветки, например fix_35 и работать непосредственно с веткой. Но тут вот я не знаю, можно ли как-то дать понять удалённому репозиторию (который работает как hub-live) что нужно на тестовой копии сайта показывать файлы не из master ветки, а из fix_35? Ну и вроде как одновременно при таком раскладе работать не получится.

В общем буду оч признателен, за советы т.к. сам с этим сталкиваюсь впервые и возможно что некоторые или почти все из предложенных мной решений окажутся полнейшим бредом.

P.S. Git настроен по принципу hub-live, как было описано в этой статье.
  • Вопрос задан
  • 10433 просмотра
Пригласить эксперта
Ответы на вопрос 7
@Vampiro
Хотел набить длинный ответ, но забил. Все-таки идеального решения не бывает. Для двух разрабов я бы делал так:
dev.site.ru ->test.site.ru->www.site.ru
кажому разрабу локально ставить гит-репозитарий, и сначала работать в локале, потом коммититься в dev и там смотреть как работает на норм. данных. Ну и дальше миграцию по стрелкам.
Ответ написан
Комментировать
Mithgol
@Mithgol
Идеология DVCS предполагает, что у каждого разработчика есть свой репозиторий, в котором он создаёт ветки, проверяет их эффект, а затем заливает готовый код наверх (в upstream).

Логично поэтому либо дать каждому разработчику заодно и возможность поднять собственную тестовую копию сайта.

Если это не возможно, то уместно устроить дело так, чтобы у каждого разработчика на основной тестовой копии сайта была своя ветка и возможность там тестировать код. Эта-то ветка тогда и станет для него upstreamом, то есть тем местом, куда разработчик будет код заливать из своего личного репозитория. Там проверив свой код, разработчик станет делать merge оттуда в master.
Ответ написан
SpectraL
@SpectraL
Вэб разработчик (php, nodejs, js), тим лид.
Если в кратце. То в GIT очень удобная система веток. У нас на проете используется такая методика веток:
1 — dev
2 — qa
3 — production
Тоесть разработчики работают напрямую с dev, а потом новые фичи с помощью склеивания веток кочуют в тестирование и уже от туда на продакшн.
У каждого развернута своя локальная версия сайта для удобства работы. На серверах доступных из вне тоже развернуты все три ветки.
Ответ написан
calg0n
@calg0n
У нас были такие ветки:
1. master. Стабильная ветка разработки. Девелоперы не могут коммитить в нее. develop вливается в master.
2. develop. Более менее стабильная ветка разработки, которую можно в любой момент слить с master'ом.
3. feature-somefeature, feature-onemore… Ветки девелоперов в которых они работают, реализуют фичи. Как только бранч оттестирован, он вливается в develop.
4. hotfix-hotfixname, hotfix-onemore… Когда был найден критичный баг и его надо срочно пофиксить но develop пока не готов для слива в master, из мастера создается хотфикс-ветка, делается фикс, хотфикс заливается в master и develop (с правкой конфликтов, если такие возникают).

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

Ну а продакшн-сервер смотрит на master и когда надо на нем делается git pull.
Ответ написан
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Как поступаю я в такой ситуации:
Есть master, там всегда только стабильный код, то бишь после каждого коммита перед пушем (в идеале перед коммитом) прогоняются тесты. Все фичи делаются в локальных ветках (если людей фичу делает несколько — эту ветку можно запушить). Когда фича закончена — она мерджится в master.

dev версия сайта обычно клонится с master, в редких случаях создается ветка dev (хотя на моей памяти никогда это не нужно было).

А дальше, если работаете итерациями и у вас несколько версий должно быть задеплоено — все разносится по своим веткам. На сервере же делается просто checkout нужной ветки.

То бишь доделали фичу — смерджили в мастер. Прогнали тесты. Если все хорошо — пушим. Если нужно выкатить на лайв или куда еще — мерджим фичу/master в нужную ветку. После изменений в ветках отличных от master все должно быть замерджено в него, ибо ветки с фичами делаются от мастера.
Ответ написан
Комментировать
kirushik
@kirushik
По опыту (уже пяток команд на Гит посадил, теперь наблюдаю за результатами) вот это — самая удобная и безболезненная модель из всех чего я пробовал за 5 лет пользования гитом:
nvie.com/posts/a-successful-git-branching-model/

Дополнительной приятностью к ней идёт набор готовых скриптов git-flow (https://github.com/nvie/gitflow), которые позволяют ветвиться и мёрджиться с абсолютно волшебным синтаксисом:

git flow feature start superauth
git commit ...
git commit ...
git flow feature finish superauth
git flow release start v0.1
git commit ...
git commit ...
git flow release finish v0.1


И автокомплит для этих механизмов легко нагугливается…
Ответ написан
amarox
@amarox
мне в аналогичном вопросе помогли эти две статьи
habrahabr.ru/post/75990/
habrahabr.ru/post/60347/
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы