Mithgol5 авг 2013 в 13:45

GitHub Flow: рабочий процесс Гитхаба

10 мин

130K

Git * GitHub *

Перевод

+99

Комментарии 47

kimrgrey 5 авг 2013 в 14:53

Ну, в целом как-то так большинство команд, в которых мне довелось работать, и используют Git. Разве что с немного меньшей степенью автоматизации. Канонический процесс git-flow, ИМХО, излишне тяжел для проектов стандартного и даже довольно большого размера (ведь Github маленьким точно не назовешь), да и правило «деплой как минимум раз в сутки» лично мне импонирует.

qnub 5 авг 2013 в 15:02

«Меньшею», а не «меньшей» — автор может не понять…

Mithgol 5 авг 2013 в 15:08

А мне, честно говоря, из всего вышеизложенного более всего импонирует знание о том, что команда Гитхаба отложила в сторону такой инструмент, как rebase. Напрочь отложила.

То есть у них методика в стиле «master обогнал нашу ветку — вливаем в ветку код мастера и поехали дальше», а не в стиле «master обогнал нашу ветку — судорожно пытаемся натянуть все N коммитов на новую голову его».

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

kimrgrey 5 авг 2013 в 15:16

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

Mithgol 5 авг 2013 в 15:23

А это потому что у каждого свой вкус.

Я-то и вот такого коммита не погнушаюсь.

starius 5 авг 2013 в 18:48

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

Бывает, в одном коммите с элегантным названием «a batch of small improvements and bug fixes» можно увидеть много не связанных между собой изменений без отдельного описания каждого из них. А потом находишь, что баг возник в таком коммите и не знаешь, где именно.

А вот rebase, если изменения не мешают друг другу, не повредит, чтобы историю было проще читать.

VolCh 5 авг 2013 в 19:44

Название коммита очень говорящее. Пришлось список коммитов смотреть чтобы его обнаружить :)

vintage 18 апр 2016 в 20:51

То есть во всём остальном код настолько идеален, что единственное, чего можно в нём улучшить, — это развесить ёлочные игрушки на концы веток кода?

SynteZZZ 5 авг 2013 в 15:02

Удивляет остуствие тестирования(не юнит).

DreamWalker 5 авг 2013 в 15:13

>> Каждая ветвь подвергается у нас тестированию, а итоги поступают в чат-комнату — так что, если вы не тестировали её локально, то можете запушить ветвь (даже с единственным коммитом) на сервер и подождать, пока Jenkins не сообщит, все ли тесты успешно пройдены.

SynteZZZ 5 авг 2013 в 15:15

Ничто не мешает написать тест говорящий ОК с ошибкой. Имеется в виду тестирование тестировщиками.

DreamWalker 5 авг 2013 в 15:26

Ну, я бы не стал говорить об отсутствии ручного тестирования, как такового. Нельзя просто так взять и запушить новый код в master, сперва его нужно «обсудить» с товарищами по команде. Это обсуждение вполне может включать тестирование. Скорее речь идёт об отсутствии именно отдела с тестеровщиками, которые основательно тестируют каждую сборку, прежде чем та попадёт в мастер. Я полагаю, что у разработчиков гитхаба хватает компетенции, чтобы совместными усилиями самостоятельно протестировать изменения.

pyatigil 5 авг 2013 в 15:14

я полагаю, что дженкинс гоняет и интеграционные тесты
а отсутствие «ручного» тестирование — это обязательный аттрибут сколько-н развитой группы разработки

kimrgrey 5 авг 2013 в 15:18

Не думаю, что так уж и «отсутствие». Просто относительно малый сегмент. Все таки полезно иногда и руками все опробовать бывает =)

Yan169 6 авг 2013 в 07:48

Пользователи тестируют. А они реагируют постфактум, как-то так: twitter.com/githubstatus

flomop 5 авг 2013 в 15:25

Плохой перевод какой-то:(

kimrgrey 5 авг 2013 в 15:35

Так читайте оригинал =) Я, например, в принципе технические статьи на русском тяжко воспринимаю, поэтому сразу отмотал к ссылке на исходный пост.

flomop 5 авг 2013 в 16:11

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

kimrgrey 5 авг 2013 в 16:54

Ой, как я не люблю вот это вот патетическое: «Зачем постить это на Хабре?» =) Во-первых, наличие перевода лучше, чем его отсутствие. Во-вторых, я знаю немало программистов, которые на любую англоязычную ссылку попросят перевод, и только в том случае, если перевода не существует, вздохнут и пойдут читать оригинал. В-третьих, наличие поста на Хабре дает возможность обсудить сабж, чем мы тут все и занимаемся.

sheknitrtch 5 авг 2013 в 16:52

Читая статью приходится переводить с мизгольного на русский =)

Yuego 5 авг 2013 в 18:32

Шутку юмора оценил, плюсанул. Но согласитесь, он, в отличие от многих, почти не делает ошибок в тексте.
Я только за это готов «терпеть» его язык :)

spacediver 5 авг 2013 в 21:10

не троньте мизгольный! Я к середине статьи уже твердо подозревал, кто автор перевода — и приятно не ошибся.

KirAmp 6 авг 2013 в 05:35

Сложночитаемые окончания на «ю» с первого раза безошибочно указывают на Мицгола :-)

int03e 5 авг 2013 в 16:49

От git-flow отказались, потому что не смогли вписать в процесс пул реквесты, и, соответственно, ревью кода… Так что как-то так и используем.

Krio 6 авг 2013 в 10:52

Разве нельзя делать пул реквесты в ветку feature или develop?

int03e 6 авг 2013 в 12:04

Я в подробностях не помню, но при вливании фичи в девелоп по git-flow во первых автоматически фича-бранч удаляется, а во вторых еще что-то происходит. То есть не так, если нажать «merge» на гитхабе. А делать пул реквест только ради код-ревью и потом его закрывать — ну это костыль какой-то.

iborzenkov 7 авг 2013 в 07:13

Не при вливании фичи, а при завершении — никто не заставляет делать flow feature finish — можно просто сделать мерж.

int03e 7 авг 2013 в 07:16

Окей, но git-flow тем и должен быть удобен — feature start, feature finish, etc. Если мне нужно мерджить бранчи на гитхабе, потом удалять удаленный и локальный бранчи — зачем мне git-flow? Я именно про инстумент, а не про концепцию. Она то нормальная.

iborzenkov 5 авг 2013 в 16:50

git flow удобен когда у вас скажем так не «сайт»
описанная здесь работа это в терминологии git-flow работа с ветками feature и develop
просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.

А git-flow — действительно удобный скрипт, если не напрягает тот факт что ветки по умолчанию называются по другому, то почему бы и нет, хотя это хороший аддон к скрипту — по сути rolling модуль.

VolCh 5 авг 2013 в 19:46

просто в случае сайта у вас нету нескольких поддерживаемых релизов, а в случае с десктопным приложением есть.

Разве обязательно есть? Очень часто встречается ныне поддержка в виде только «обновите версию».

aknizubr 5 авг 2013 в 18:00

A successful Git branching model

artch 5 авг 2013 в 19:47

Это и есть git-flow. В смысле, автор git-flow и автор этого поста — одно и то же лицо.

VolCh 5 авг 2013 в 20:08

То ли что-то не договаривается, то ли я что-то не понимаю. На каждый ветку, еще не влитую в мастер поднимаются отдельные дев- и тест- (для внутренних и внешних тестеров) сервера как-то? Как? автоматом или ручками? Или тестирование перед выкладыванием в продакшен ограничивается ревьюированием кода и автотестами? Ну и если дев сервер ещё как-то можно поднять локально или независимо от гита заливать на него код, то с тестом, на котором тестеры должны «кнопочки понажимать» перед тем как дать окончательной согласие на продакшен, как быть?

В общем как-то не получается у меня простая и понятная схема, когда есть два общих сервера (продакшен и тест) и у каждого разработчика дев-сервер, доступный остальным (то есть он не локальным должен быть). С дев ладно — можно прямо в /var/www/<dev-name> на сервере работать по ssh или примонтировав по sshfs, держа её под контролем git. А вот как с тестовым быть? Деплоить его с мастера, а после приемки деплоить на продакшен? Тогда, получается нельзя вливать фичи в мастер пока тестирование идет. Ответвить тест от мастера? Похожая проблема. Фиксировать версию на тесте и деплоить продакшен с мастера не с головы, а с этой версии? Ограничения на разработчиков — не могут в любой момент залить на тест, пока там тестируется что-то другое.

Кто как выходит?

Devgru 5 авг 2013 в 20:23

Автоматизированный CI.

vvnick 5 авг 2013 в 20:43

Чуть более развернутый вариант ответа «Автоматизированный CI»:
автор упоминает что у них Дженкинс запускает все тесты, значит для каждой ветки Дженкинсом автоматически создается/обновляется новая инстанция приложения (веб-сайта), на которой запускается набор каких-нибудь Селениум + J(php)unit тестов.
Вполне себе стандартный подход, ну а то что сразу руками специально обученные тестеры не тестируют — судя по тому что написано что правила у них не жесткие, то крупные изменения — тестируют, а мелкие — уже в продакшне вместе с пользователями ;)

Хорошо настроенный и прокачаный Дженкинс — вполне справляется с автоматизацией и поднятия копий приложения (деплоя) и тестирования, и общения с гитом и багтрекером.

organium 6 авг 2013 в 01:00

Я думаю, что имеется в виду именно CI + ревью кода + ручное тестирование одного из разработчиков (или нескольких). Разработчик делает git fetch + git checkout <нужная ветка> и проверяет изменения, сделанные в пулл реквесте на баги. Ну а для простых веток достаточно ревью кода, по тестам видно покроют они или нет функционал из пулл реквеста, а CI скажет прошли ли сами тесты.

VolCh 6 авг 2013 в 07:57

Для дев-сервера или внутреннего тестирования (по инициативе тестировшика) git fetch + git checkout подходит более-менее. Но вот как только начинается внешнее тестирование, то начинаются организационные проблемы. Коммит с фичей или фиксом прошел внутренне тестирование, все изменения с master (то есть продакшена) влиты. И таких коммитов, ожидающих внешнего тестирования (в удобное для внешнего тестировщика время) несколько. Вливать их в master нарушает принцип «в master должен быть production код». Давать на тестирование каждую фиче/фикс ветку отдельно не разумно из-за малой оперативности взаимодействия с внешним тестировщиком (заказчиком). Видится как-то как создание ветки test от master куда вливаются все коммиты, прошедшие локальное тестирование на конкретную подзадачу, и заказчику передается «дифф» (на человеческом языке) отличий (список как бы выполненных подзадач) от текущего продакшена (или прошлого теста?), но непонятно как быть если часть коммитов заказчик принял, одобрил их размещение на продакшене, и, мало того, требует срочного размещения, а часть нет и переделка займёт долгое время.

organium 6 авг 2013 в 08:15

Скорее всего, раз задача описана грамотно и создана с участием заказчика, то не может такого быть, чтобы заказчик сказал — «Этого не должно быть в продакшене и точка!». Заказчик может найти баг, но переделывать целиком он вряд ли заставит. А код ревью и проверка другим разработчиком должны уменьшить риск. Ну и иногда можно сделать revert. Так что думаю, что это осознанно принятый риск для ускорения процесса разработки.

VolCh 6 авг 2013 в 13:25

не может такого быть

может :(

truezemez 6 авг 2013 в 07:30

Возможно, Вы найдете ответ здесь: Continuous Deployment at Github

Все, кому интересен GitHub workflow, могут почитать ответы и задать вопросы тут: holman/feedback/issues