В Яндексе не только пишут код, но ещё и запускают его в виде сервисов. Из доклада вы узнаете, как мы обслуживаем наш код, какие процессы выстраиваем для правильного соблюдения релизного цикла и как нам в этом помогает Git и GitHub.

1. Яндекс
Менеджмент кода,
или почему SCM
Сергей Сергеев
руководитель группы разработки интерфейсов
Я.Субботник, Киев, 27 апреля 2013 года

2. Сегодня
я побуду
«капитаном
очевидность»

3. Git
Git — the stupid content tracker
Linus Torvalds
“
3

4. SCM —
source code
management

5. Регламент

6. А зачем нам регламент?
— ЗНАЕМ! что происходит
— понимаем когда релизим
— понимаем где брать свежий код
— понимаем куда изменения «вливать» и откуда «отпочковывать»
6

7. Git-Flow

8. Git-Flow — наш выбор
— как вести разработку и не бояться «закопаться» в процедуре
формирования релиза
— как и когда формировать релиз
— как внешнему (для проекта) пользователю понять где брать
стабильный релиз и релиз более старой версии
— как делать hotfix'ы тогда, когда основная ветвь разработки ушла уже
далеко
8

9. GitHub

10. GitHub и pull-request'ы
— pull-request для ревью
— один pull-request на одну задачу
— причёсываем историю до подачи pull-request'а
— простое правило — dev всегда стабилен!
10

11. «Гигиена»
коммитов

12. Базовые правила
— коммитим часто
— коммитим атомарно
— подробно описываем коммит
— помним, что это git
12

13. Анти-паттерны

14. Анти-паттерны регламента
— «меня попросили влить и я влил как есть»
— «нам нужно было быстро, поэтому мы никому не рассказали что…»
— «отдали всем одну ветку, а баги фиксили в другой»
— «я сосквошил всё в один коммит, т.к. это одна задача»
— «мне для этой задачи понадобилось поправить API…»
14

15. Журнал Капитана
abc2390 багфикс 2 [captain]
eec5401 багфикс [captain]
53aeex5 добавил файлы [captain]
04012ea минорные изменения [captain]
cade034 убрал ненужное [captain]
15

16. Анти-паттерны git'а
— git push --force
— git rebase [ -i ] public-branch
16

17. Вопросы?

18. Сергей Сергеев
руководитель группы разработки интерфейсов
gurugray@yandex-team.ru
@gurugray
Я