0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: devops, git, trunk-based development, git-flow, инструменты разработчика, качество кода, контроль изменений, система контроля версий</p>
1
<p>Теги: devops, git, trunk-based development, git-flow, инструменты разработчика, качество кода, контроль изменений, система контроля версий</p>
2
<p>В процессе разработки кода программистам не обойтись без инструмента по версионности и контролю изменений. Одна из наиболее известных и популярных систем контроля версий -<strong>git</strong>(изменение кода можно зафиксировать и у этого изменения будет специальная метка). В результате вся история процесса разработки видна программистам, что очень удобно.</p>
2
<p>В процессе разработки кода программистам не обойтись без инструмента по версионности и контролю изменений. Одна из наиболее известных и популярных систем контроля версий -<strong>git</strong>(изменение кода можно зафиксировать и у этого изменения будет специальная метка). В результате вся история процесса разработки видна программистам, что очень удобно.</p>
3
<p>Однако когда команда ведёт работу над одним и тем же кодом, рекомендовано придерживаться следующих правил: - "не ломать" текущий рабочий код; - не мешать друг другу, работая в одной ветке.</p>
3
<p>Однако когда команда ведёт работу над одним и тем же кодом, рекомендовано придерживаться следующих правил: - "не ломать" текущий рабочий код; - не мешать друг другу, работая в одной ветке.</p>
4
<p>Для решения проблем взаимодействия разработчиков друг с другом в<strong>git</strong>есть различные подходы, например,<strong>git-flow</strong>. Работа с ветками является одной из основных в<strong>git-flow</strong>и это один из главных его недостатков. Постоянные<strong>merge</strong>и конфликты при слиянии, а также сама суть в долгосрочных ветках могут сыграть злую шутку против разработчиков. И если говорить об итеративной разработке, то при больших промежутках времени между релизами с<strong>git-flow</strong>можно подружиться, но когда речь идёт о более частых релизах, всё становится гораздо сложнее.</p>
4
<p>Для решения проблем взаимодействия разработчиков друг с другом в<strong>git</strong>есть различные подходы, например,<strong>git-flow</strong>. Работа с ветками является одной из основных в<strong>git-flow</strong>и это один из главных его недостатков. Постоянные<strong>merge</strong>и конфликты при слиянии, а также сама суть в долгосрочных ветках могут сыграть злую шутку против разработчиков. И если говорить об итеративной разработке, то при больших промежутках времени между релизами с<strong>git-flow</strong>можно подружиться, но когда речь идёт о более частых релизах, всё становится гораздо сложнее.</p>
5
<p>В данной ситуации предпочтительнее выглядит<strong>Trunk-based Development</strong>- подход, который сегодня широко используется такими крупными компаниями, как Google и Facebook. Он также основан на ветвлении, однако второстепенные ветки имеют короткий срок жизни: от нескольких часов до нескольких дней. Из этого нюанса и вытекает<strong>концептуальная идея Trunk-based Development</strong>, которая заключается в том, что в конце работы с кодом в рамках временной ветки все изменения так или иначе должны попасть в основную<strong>master</strong>-ветвь.</p>
5
<p>В данной ситуации предпочтительнее выглядит<strong>Trunk-based Development</strong>- подход, который сегодня широко используется такими крупными компаниями, как Google и Facebook. Он также основан на ветвлении, однако второстепенные ветки имеют короткий срок жизни: от нескольких часов до нескольких дней. Из этого нюанса и вытекает<strong>концептуальная идея Trunk-based Development</strong>, которая заключается в том, что в конце работы с кодом в рамках временной ветки все изменения так или иначе должны попасть в основную<strong>master</strong>-ветвь.</p>
6
<p>Кроме того: - есть требования к контролю качества кода (в master-ветку попадает уже протестированный рабочий код, что повышает его стабильность, детали -<a>здесь</a>); - все релизы делаются только из<strong>master</strong>-ветки.</p>
6
<p>Кроме того: - есть требования к контролю качества кода (в master-ветку попадает уже протестированный рабочий код, что повышает его стабильность, детали -<a>здесь</a>); - все релизы делаются только из<strong>master</strong>-ветки.</p>
7
<p>При этом взаимодействие между разработчиками в рамках временной ветки - вполне нормальное явление (можно делать<strong>brunch</strong>нашей задачи, получать комментарии, выполнять изменения и дополнения, возвращать исправленные фрагменты кода в мастер-ветку). Вот, пожалуй, и всё на сегодня. Если хотите получить более глубокие знания по инструментам синхронизации, записывайтесь на курсы OTUS по DevOps!</p>
7
<p>При этом взаимодействие между разработчиками в рамках временной ветки - вполне нормальное явление (можно делать<strong>brunch</strong>нашей задачи, получать комментарии, выполнять изменения и дополнения, возвращать исправленные фрагменты кода в мастер-ветку). Вот, пожалуй, и всё на сегодня. Если хотите получить более глубокие знания по инструментам синхронизации, записывайтесь на курсы OTUS по DevOps!</p>
8
8