Вместе с Алексеем Ашурком мы расскажем о том, как проект «Фламп» релизится по 2n раз в неделю и комфортно себя при этом чувствует:
— Ветки - это хорошо или о переходе с SVN на Git.
— Чем плоха «классическая» модель релизов.
— Что такое модель пофичных релизов, в чём её плюсы и минусы.
— Почему она подходит для веб-сервисов.
— Как идти в ногу со временем или частые деплои.
— Как ловить ошибки и минимизировать их число.
Видео доклада: http://devday.2gis.ru/report/15
Презентация методологии git-flow для стабильной разработки
Текстовая версия: https://medium.com/ruopsdev/git-flow-presentation-b80643390888
Скачать презентацию в формате pptx: https://docs.google.com/presentation/d/1Bgx5GP9ykGYKUnAaD53Y0YIpPpHHSbvT/edit?usp=sharing&ouid=106302903983671723423&rtpof=true&sd=true
Антон Григорьев, Git-flow: как построить процесс разработки и быстро получать...ScrumTrek
Работаете над проектом втроем (вчетвером, впятером, вдесятером и тд) и у вас постоянные конфликты в системе контроля версий? - В спешке пытаетесь собрать проект, но не можете найти рабочую версию, а клиент просит здесь и сейчас? - Процесс тестирования и выпуск новой версии - стресс для вас и вашей команды? Решить эти и другие проблемы поможет git-flow. Вы узнаете, как git-flow связан с процессом непрерывной интеграции, как это поможет быстро доставлять вашим клиентам исправления критических ошибок и как эти изменения автоматически попадут в текущую версию продукта. Приходите, если даже просто интересно, причем тут git и подойдет ли SVN, Hg или TFS?
Вместе с Алексеем Ашурком мы расскажем о том, как проект «Фламп» релизится по 2n раз в неделю и комфортно себя при этом чувствует:
— Ветки - это хорошо или о переходе с SVN на Git.
— Чем плоха «классическая» модель релизов.
— Что такое модель пофичных релизов, в чём её плюсы и минусы.
— Почему она подходит для веб-сервисов.
— Как идти в ногу со временем или частые деплои.
— Как ловить ошибки и минимизировать их число.
Видео доклада: http://devday.2gis.ru/report/15
Презентация методологии git-flow для стабильной разработки
Текстовая версия: https://medium.com/ruopsdev/git-flow-presentation-b80643390888
Скачать презентацию в формате pptx: https://docs.google.com/presentation/d/1Bgx5GP9ykGYKUnAaD53Y0YIpPpHHSbvT/edit?usp=sharing&ouid=106302903983671723423&rtpof=true&sd=true
Антон Григорьев, Git-flow: как построить процесс разработки и быстро получать...ScrumTrek
Работаете над проектом втроем (вчетвером, впятером, вдесятером и тд) и у вас постоянные конфликты в системе контроля версий? - В спешке пытаетесь собрать проект, но не можете найти рабочую версию, а клиент просит здесь и сейчас? - Процесс тестирования и выпуск новой версии - стресс для вас и вашей команды? Решить эти и другие проблемы поможет git-flow. Вы узнаете, как git-flow связан с процессом непрерывной интеграции, как это поможет быстро доставлять вашим клиентам исправления критических ошибок и как эти изменения автоматически попадут в текущую версию продукта. Приходите, если даже просто интересно, причем тут git и подойдет ли SVN, Hg или TFS?
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...Badoo Development
В крупном интернет проекте при построении непрерывной интеграции возникает множество проблем и рутинной работы. Этот доклад о том, как мы избежали проблем и автоматизировали большую часть работы. Мы показали связь непрерывной интеграции со всеми стадиями разработки программного продукта.
А также вы узнаете из доклада:
1. Модель разработки каждой задаче в отдельной ветке, плюсы и минусы.
2. Как автоматизировать рутинные операции в системе контроля версий.
3. Организации работы с хуками в Git в условиях большого количества репозиториев.
4. Автоматизация работы с баг трекером, как у нас проходит ревью кода.
5. Построение непрерывной интеграции для компилируемых и не компилируемых компонентов.
6. Автоматизация сборок с зависимостями из веток релиза для компилируемых компонент.
7. Continuous delivery и почему большое количество веток не всегда плохое решение для данного подхода.
И конечно же Release engineering, как он влияет на разработку и качество продукта.
После доклады вы поймете все основные процессы при построении непрерывной интеграции и увидите как важна автоматизация в данном процессе.
Никита Шультайс. "Система управления версиями git"Egor Stremousov
Основные тезисы выступления:
- организация репозитория,
- ветвление,
- базовые команды,
- работа в одиночку и в команде.
После выступления прошла бурная дискуссия, обмен опытом и приятное общение с профессионалами.
Доклад Владислава Чернова & Олега Оямяэ на РИТ++ 2013. "AIDA. Непрерывная инт...Badoo Development
В крупном интернет проекте при построении непрерывной интеграции возникает множество проблем и рутинной работы. Этот доклад о том, как мы избежали проблем и автоматизировали большую часть работы. Мы показали связь непрерывной интеграции со всеми стадиями разработки программного продукта.
А также вы узнаете из доклада:
1. Модель разработки каждой задаче в отдельной ветке, плюсы и минусы.
2. Как автоматизировать рутинные операции в системе контроля версий.
3. Организации работы с хуками в Git в условиях большого количества репозиториев.
4. Автоматизация работы с баг трекером, как у нас проходит ревью кода.
5. Построение непрерывной интеграции для компилируемых и не компилируемых компонентов.
6. Автоматизация сборок с зависимостями из веток релиза для компилируемых компонент.
7. Continuous delivery и почему большое количество веток не всегда плохое решение для данного подхода.
И конечно же Release engineering, как он влияет на разработку и качество продукта.
После доклады вы поймете все основные процессы при построении непрерывной интеграции и увидите как важна автоматизация в данном процессе.
Никита Шультайс. "Система управления версиями git"Egor Stremousov
Основные тезисы выступления:
- организация репозитория,
- ветвление,
- базовые команды,
- работа в одиночку и в команде.
После выступления прошла бурная дискуссия, обмен опытом и приятное общение с профессионалами.
Гит, несмотря на то, что все им пользуются, напоминает айсберг и огромная часть его функционала загадочна для большинства разработчиков. Я попытаюсь дать обзор правильных практик работы с гитом в применении к Друпал-проектам, осветить некоторые тёмные, но интересные закоулки, предостеречь от ошибок, которые сам совершал.
Системы управления версиями (VCS). Знакомство с Git.Dmytro Olaresko
Данный доклад познакомит Вас с системой управления версиями файлов Git, которой пользуется Drupal-сообщество. Эта система может значительно упростить жизнь команды разработчиков, а также обезопасить Вас от потери файлов. В доклад также входит описание систем управления версиями в целом.
Видео доклада:
http://www.youtube.com/watch?v=3urk3xf79SM
2. Предпосылки
2
•Каждая команда, на сегодняшний день, использует Git-flow
•Часто встречаются ситуации когда появляются те или иные
проблемы из-за незнания инструментов
•Все его используют, но не всегда представляют как с ним
работать
3. О чем сегодня пойдет речь
3
•Git-flow
•Преимущества
•Проблемы
•Инструменты используемые в работе
•Merge
•Rebase
•Cherry-pick
•Stash
•Автоматизируем работу при помощи CI-систем
19. Преимущества такого подхода
19
•Легко отследить историю проекта
•Вся работа разделена на тематические ветки
•Очень гибкий подход, позволяющий расширять набор веток и
правил для больших команд
25. Проблемы
25
•Разработчики держат на вооружении команду merge для
получения изменений из любой ветки
•Если в команде используется код-ревью, то порой тянут с
проверкой, поскольку боятся использовать команду stash
26. Проблемы
26
•Разработчики держат на вооружении команду merge для
получения изменений из любой ветки
•Если в команде используется код-ревью, то порой тянут с
проверкой, поскольку боятся использовать команду stash
•Подход разрабатывался как решение для собственных проектов
33. 33
develop
feature
git checkout develop
git merge feature
1. Поиск общего предка
2. Поиск блоков изменившихся в обеих
версиях
3. Запись блоков оставшихся без
изменений
Merge, трехстороннее слияние
34. 34
develop
feature
git checkout develop
git merge feature
1. Поиск общего предка
2. Поиск блоков изменившихся в обеих
версиях
3. Запись блоков оставшихся без
изменений
4. Блоки измененные только в одном из
потомков записываются как
измененные
Merge, трехстороннее слияние
35. 35
develop
feature
git checkout develop
git merge feature
1. Поиск общего предка
2. Поиск блоков изменившихся в обеих
версиях
3. Запись блоков оставшихся без
изменений
4. Блоки измененные только в одном из
потомков записываются как
измененные
5. Блоки, измененные в обоих потомках
записываются только если изменения
идентичны, иначе — конфликт
Merge, трехстороннее слияние
36. Merge, трехстороннее слияние
36
develop
feature
git checkout develop
git merge feature
1. Поиск общего предка
2. Поиск блоков изменившихся в обеих
версиях
3. Запись блоков оставшихся без
изменений
4. Блоки измененные только в одном из
потомков записываются как
измененные
5. Блоки, измененные в обоих потомках
записываются только если изменения
идентичны, иначе — конфликт
6. Коммит!
43. Rebase
43
develop
feature
A B
C D E
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
44. Rebase
44
develop
feature
A B
C D E
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
𝛥AC
45. Rebase
45
develop
feature
A B
C D E
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
3. Дельта применяется к ветке develop,
C’ = B + 𝛥АС
𝛥AC
C’
46. Rebase
46
develop
feature
A B
C D E
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
3. Дельта применяется к ветке develop,
C’ = B + 𝛥АС
4. Вычисляется 𝛥CD, и наносится на C’
𝛥AC
C’
𝛥CD
D’
47. Rebase
47
develop
feature
A B
C D E
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
3. Дельта применяется к ветке develop,
C’ = B + 𝛥АС
4. Вычисляется 𝛥CD, и наносится на C’
𝛥AC
C’
𝛥CD
D’ E’
𝛥ED
48. Rebase
48
develop
feature
A B
git rebase develop
1. Поиск общего предка
2. Двигаясь к HEAD вычисляется разница
каждого коммита
3. Дельта применяется к ветке develop,
C’ = B + 𝛥АС
4. Вычисляется 𝛥CD, и наносится на C’
5. Устанавливается Head на E, ссылки на
старые коммиты удаляются
C D E
49. Некоторые особенности Rebase
49
•Необходимо помнить, что хэш переписывается
•Изменения, которые зафиксированы, откатить нельзя
•Необходимо проверять каждый шаг Rebase, если возникли
конфликты
50. Merge vs Rebase
50
•Применяйте Merge только для вливания изменений в Master или
Develop
•Применяйте Rebase для получения изменений в рабочие ветки
61. 61
Автоматизация работы при помощи CI
•Отслеживание актуального состояния вашего билда
•Оповещение о тех или иных изменениях в ветках
•Автоматизация сборки тестовых и релизных билдов
65. 65
Немного о “Правилах хорошего тона”
•Никогда не меняйте по одному символу в коммите
•Пиши сообщения к коммитам ясно и четко
66. 66
Немного о “Правилах хорошего тона”
•Никогда не меняйте по одному символу в коммите
•Пиши сообщения к коммитам ясно и четко
•Не делайте изменений в ветке на тысячи строк
67. 67
Напоследок о GUI инструментах для работы c Git
•Сокращение некоторых команд до одной кнопки
•Наглядно можно видеть все ветки
•Встроенные инструменты для решения конфликтов
•Удобный просмотр изменений сделанных в файле
•Легкое добавление изменений которые вы хотите закоммитить