Перевод статьи «The most important git practice».
Как думаете, какой он — самый важный подход к работе с Git?
От редакции Techrocks. У нас на сайте есть статья «Мнение: пушить сразу в мастер — хорошо. Обсуждаем Trunk Based Development». В статье, которую мы предлагаем вам сегодня, приведено противоположное мнение. Возможно, вам будет любопытно почитать обе точки зрения.
Что такое подход?
Но прежде чем перейти к ответу на главный вопрос, скажите, а что такое подход? Как вы определите самые ценные подходы? Что для них характерно?
Определение, которое я использую, я почерпнул из книги «Emergent Design» Скотта Бейна. Самый ценный подход к работе имеет три отличительные черты:
- Это нечто, что мы можем делать всегда. Нам не нужно каждый раз принимать решение, делать так или нет.
- Эта практика каким-то образом очень помогает, польза от нее существенна.
- Применение этого подхода не требует дополнительной работы (или требует, но совсем чуть-чуть). Мы все выступаем за все хорошее и против всего плохого. Но мы жадные и хотим быть хорошими, не расплачиваясь за это. Конечно, своя цена есть у всего, но цена самых ценных подходов должна быть такой, чтобы ею можно было пренебречь.
Итак, что такого важного вы можете проделывать, работая с Git, не затрачивая на это дополнительных усилий, получая значительную выгоду и применяя это на автомате?
Скажите, вам случалось сохранять несколько клонов вашего форка? А создавать несколько форков одного репозитория?
Если вы ответили «да» на последние два вопроса, вероятно, вы уже знаете, что нужно…
Содержать основную ветку в чистоте и порядке!
Никогда не работайте в master (или как там вы называете свою основную ветку)!
Конечно, многие могут не согласиться, что это самый важный подход в работе с Git. А как же маленькие коммиты, написание осмысленных сообщений коммитов и прочие вещи? Все они важны и могут приносить большую пользу в долгосрочной перспективе, но применение этих подходом требует усилий. Немного больше подумать о структурировании коммитов, подобрать слова для сообщения коммита. Все это не бесплатно, если говорить об умственных усилиях.
А привычка не работать в главной ветке дополнительных усилий не требует и при этом приносит большую пользу. Особенно, если вы работаете с крупным проектом, где изменения могут вноситься параллельно.
Если только речь не идет о маленьком личном проекте, есть большая вероятность, что работа над несколькими разными изменениями будет происходить одновременно.
Но что может пойти не так, когда работаешь в master?
Если вы и ваши ревьюеры достаточно шустрые, то, может, и ничего.
Но когда в дело вмешивается суровая правда жизни, начинаются проблемы.
Смена приоритетов до того как удалось отправить изменения
Представьте такую ситуацию. Вы начали работать над чем-то, достигли определенного прогресса, сделали несколько маленьких коммитов, но еще не готовы создать пул-реквест. Вы еще даже не запушили изменения в свой форк. И тут приходит ваш менеджер и говорит, что возникла проблема, требующая срочного внесения правок в том же репозитории, с которым вы работаете. И теперь это ваш новый главный приоритет — он приоритетнее, чем остальные ваши 10 самых важных задач. Вам приходится все отложить и сместить фокус.
Что делать в такой ситуации?
Если вы не работали в главной ветке, после выполнения более приоритетной задачи вы просто вернетесь к своей работе, проверите, что в upstream ничего не изменилось, создадите новую ветку и продолжите работу.
Но если вы уже сделали коммиты в master…
Возможно, вы просто сделаете клон в новой папке, но где-то в душе будете знать, что это неправильно.
Или вам придется сначала создать новую ветку, разместить в ней свои уже сделанные коммиты, вернуться в master, удалить коммиты вручную или сделать принудительную перезапись из каждого вашего форка или прямо из upstream (в случае, если у вас нет автоматической синхронизации между вашим форком и upstream).
Это не то чтобы большое дело, но все же напрасная потеря времени. А люди, работающие в главной ветке, не всегда умеют удалять коммиты или делать принудительную перезапись.
И это еще простой пример.
Последующие пул-реквесты
Если работа в основной ветке для вас не табу, вы вполне можете попасть в следующую ситуацию.
Представьте, что вы закоммитили несколько изменений в ветку master, создали пул-реквест и отправились прогуляться. Возвращаетесь и понимаете, что никто никаких ревью не делал, ваш код пока так и не смержен. То, что приоритетно для вас, не обязательно приоритетно для других.
Но вы хотели бы начать работать над следующей задачей в том же репозитории. Как быть?
Вы продолжаете работать, как будто ничего не произошло. Работаете, работаете, вот уже пора сделать новый пул-реквест. И тут вы понимаете, что предыдущий все еще не смержен. Что делать?
Вы можете попробовать включить старые изменения в новый пул-реквест. Но скорее всего ничем хорошим это не обернется.
- Изменения могут не иметь отношения к новому пул-реквесту, и если их добавить, он потеряет свою цельность.
- Может, вы хотели бы создавать маленькие пул-реквесты, чтобы получать более осмысленный фидбэк.
- А может, вы уже получили несколько комментариев, над которыми нужно поработать. Предыдущий коммит попросту не готов к интеграции.
В общем, вам нужно как-то отправить свои новые коммиты без предыдущих, которые еще не интегрированы.
Этот процесс может быть похож на предыдущий, но здесь вы не можете просто перезаписать свои локальные коммиты другими из вашего форка, потому что ветка master в вашем форке уже нарушена.
Вы даже не можете просто сделать клон вашего форка, потому что он будет содержать коммиты, которые вам не нужны. Что ж, можно создать новый форк…
Но если вы не хотите новый форк, вам придется сделать пару дополнительных шагов (по сравнению с теми, которые я описывал в предыдущем разделе).
Вам придется добавить (если раньше не добавляли) форкнутый репозиторий (часто это upstream) в качестве удаленного и перезаписать вашу локальную основную ветку оттуда. Естественно, только после того как поместите все ваши локальные коммиты в новую ветку. Затем вам нужно будет создать новую feature branch (ответвление от главной ветки), после чего при помощи cherry-pick выбрать в нее те коммиты, которые вам нужны для второго пул-реквеста.
Насколько проще все могло бы быть, если бы вы сразу создали два ответвления от вашей ветки master и работали над разными вещами в разных местах?
А для этого вам всего-то нужно было бы выполнить команду git checkout -b myFeatureBranch.
Заключение
Мы рассмотрели два простых случая, когда работа в главной ветке может привести к проблемам. Эти проблемы, конечно, решаемы, и есть способы их обойти (кроме тех, которые я описал здесь). Но если вы знакомы с этими командами, умеете откатывать назад коммиты, работать с отдельными head, то, вероятно, ваши умения работать с Git выходят за пределы коммитов в главную ветку.
Начинать разработку каждой отдельной фичи с освежения главной ветки вашего локального репозитория и создания ответвления. Это, пожалуй, самый важный подход, который следует применять в работе. Его применение вам ничего не будет стоить, вам не нужно будет ничего дополнительно обдумывать или решать. Зато у вас будет важное преимущество: вам не придется использовать дополнительные команды для удаления нежелательных коммитов в случае параллельных изменений.
А как насчет вас? Какие подходы в работе с Git вы считаете самыми важными? Поделитесь в комментариях!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
