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

Question

[Иван Пантелеев]

Появился один такой, но глобальный вопрос по поводу построения архитектуры 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, как было описано в этой статье.

Answer 1

[Vampiro]

Хотел набить длинный ответ, но забил. Все-таки идеального решения не бывает. Для двух разрабов я бы делал так:
dev.site.ru ->test.site.ru->www.site.ru
кажому разрабу локально ставить гит-репозитарий, и сначала работать в локале, потом коммититься в dev и там смотреть как работает на норм. данных. Ну и дальше миграцию по стрелкам.

Answer 2

[Mithgol]

Идеология DVCS предполагает, что у каждого разработчика есть свой репозиторий, в котором он создаёт ветки, проверяет их эффект, а затем заливает готовый код наверх (в upstream).

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

Если это не возможно, то уместно устроить дело так, чтобы у каждого разработчика на основной тестовой копии сайта была своя ветка и возможность там тестировать код. Эта-то ветка тогда и станет для него upstreamом, то есть тем местом, куда разработчик будет код заливать из своего личного репозитория. Там проверив свой код, разработчик станет делать merge оттуда в master.

Comments

[Mithgol]

Опечатка: слово «либо» лишнее, я позабыл убрать его при редактировании ответа.

[Иван Пантелеев]

Возникает вопрос как сделать привязку следующего типа:
dev1.example.com -> origin/dev1
dev2.example.com -> origin/dev2

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

[Mithgol]

Дык ить у Apache может ведь быть свой репозиторий в каждом таком каталоге, берущий данные из той или иной ветки основного репозитория.

Достаточно к основному репозиторию прицепить скрипт, который станет пинать клиентский git, пополняющий тот репозиторий, который Apache показывает.

[Иван Пантелеев]

А можно по подробнее, а то я смутно понял о чём идёт речь? Или где почитать может можно, чтобы уловить суть вашего ответа.

Answer 3

[Дмитрий Артеменко]

Если в кратце. То в GIT очень удобная система веток. У нас на проете используется такая методика веток:
1 — dev
2 — qa
3 — production
Тоесть разработчики работают напрямую с dev, а потом новые фичи с помощью склеивания веток кочуют в тестирование и уже от туда на продакшн.
У каждого развернута своя локальная версия сайта для удобства работы. На серверах доступных из вне тоже развернуты все три ветки.

Comments

[Иван Пантелеев]

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

[Иван Пантелеев]

вернее развернуть конечно можно, но проект довольно громоздкий и это будет затруднительно. Хотя при большом желании возможно наверное, тут надо оценить окупятся ли затраченные на это усилия.

[Дмитрий Артеменко]

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

[Александр]

Расскажите как у вас происходит merge из dev ветки в qa/production. Вы делаете полный merge всей dev ветки или при помощи cherry-pick?
Сам с гитом работаю относительно недавно, но вопрос merge части коммитов из дева меня смущает до сих пор.

[Дмитрий Артеменко]

У нас идет полный merge всей ветки. Это не совсем мое поле деятельности, поэтому тут я не все аспекты знаю.

Answer 4

[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.

Comments

[Иван Пантелеев]

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

[calg0n]

У вас на каждого разработчика по тестовому серверу, я верно понял?

2-3 тестовых. Не на каждого, но этого хватает. Если что кол-во легко увеличить.

Если так, то тогда на каждый такой сервер дожно быть по репозиторию, да?

Нет, репа одна. На тестовых как и на продакшене сделан git clone, git checkout feature-ветка/master-ветка/..., и когда надо делается git pull.

Answer 5

[Сергей Протько]

Как поступаю я в такой ситуации:
Есть master, там всегда только стабильный код, то бишь после каждого коммита перед пушем (в идеале перед коммитом) прогоняются тесты. Все фичи делаются в локальных ветках (если людей фичу делает несколько — эту ветку можно запушить). Когда фича закончена — она мерджится в master.

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

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

То бишь доделали фичу — смерджили в мастер. Прогнали тесты. Если все хорошо — пушим. Если нужно выкатить на лайв или куда еще — мерджим фичу/master в нужную ветку. После изменений в ветках отличных от master все должно быть замерджено в него, ибо ветки с фичами делаются от мастера.

Answer 6

[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

И автокомплит для этих механизмов легко нагугливается…

Comments

[Иван Пантелеев]

Тут у меня возникает вопрос, если master — это такой себе production, то developer ветка — это тот самый тестовый сервер (test.example.com) Как тестировать фичи которые будут ветвится от develop ветки? Ведь локальных серверов не будет и тестируется вся функциональность на удалённом сервере. Как быть?

[kirushik]

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

git flow feature publish ReadmeAdd

При этом на удалённом репозитории–ориджине появляется ветка origin/feature/ReadmeAdd. Соответственно, CI–сервер сам её подхватит и задеплоит.

Если вы деплоите ручками через Гит на тот же Хероку — то можно пошить для деплоя произвольную ветвь вручную командой типа

git push heroku feature/ReadmeAdd:master

И оно автоматически сбилдится и задеплоится на Хероку. (Обратите внимание на синтаксис ветвей — тут локальная и удалённая ветви имеют разные названия.)

Ну и последний вариант, для менее автоматизированных проектов — завести на сервере–ориджине post-receive хук, и из него решать, что делать с ветвью, опубликованной при помощи git flow feature publish. Капистраной там разворачивать сложный набор серверов, как пример.
Подробнее про хуки гита можно прочитать тут.

Answer 7

[amarox]

мне в аналогичном вопросе помогли эти две статьи
habrahabr.ru/post/75990/
habrahabr.ru/post/60347/