Блог

Я продолжаю читать о том, что всегда следует работать над веткой, отличной от основной. Как только я выполняю работу, я объединяю их. Почему это лучше, чем просто работать с основной веткой?

Единственное преимущество, которое я вижу на первый взгляд, заключается в том, что тогда есть несколько безопасный способ всегда знать, какая «последняя известная рабочая версия» — основная ветка. В этом причина?

Основное преимущество работы в ветке заключается в том, что вы можете делать коммиты для изолированной функции, сохраняя при этом возможность вносить исправления в master. Вы также можете выполнять такие вещи, как коммиты «squash» с rebase -i , если чувствуете, что несколько коммитов должны отображаться как один коммит для других пользователей.

Вы также можете работать над несколькими экспериментальными функциями одновременно. Позже вы можете решить отказаться от этой функции или реализовать ее другим способом, и вы можете просто удалить эту ветку, не загромождая свою основную историю.

У меня часто есть несколько экспериментальных ветвей функций в любом данном проекте. Даже для того, чтобы просто быстро записать некоторые мысли в виде кода, они очень полезны.

Вот один пример, который часто встречается у меня:

Допустим, вы работаете над функцией, она обширная, поэтому для ее выполнения потребуется много коммитов. Вы примерно на полпути к завершению, поэтому код нестабилен, но продвигается неплохо.

Теперь в рабочей версии кода обнаружена критическая ошибка (предположительно, в вашей основной ветке). Если вы совершали коммит в отношении главной ветки, как вы это исправляете и выталкиваете исправление, не выталкивая сломанный незавершенный код?

Если вы работали над своей новой функцией в ветке, которая не является главной, вы можете легко просто переключиться на главную ветку, исправить ошибку и запустить код. Затем переключитесь обратно на свою функциональную ветку и продолжайте работать.

Мне достаточно одной этой возможности, чтобы создавать ветку в любое время, когда я над чем-то работаю.

В других ответах есть несколько хороших моментов, но есть еще один важный: что, если вы опубликуете работу в центральном репозитории, к которому также будут иметь доступ другие? Возможно, путем нажатия, возможно, с помощью запросов на извлечение, но в результате все, что вы делаете, выходит наружу. Действительно помогает соблюдение соглашения о публикации работы только из вашей главной ветки.

Как вы сказали, вы можете думать о master как о «последней известной рабочей версии», но вы также можете думать о ней как о «моей новейшей стабильной версии». Если это единственная ветка, из которой вы публикуете, то вы знаете, что никогда не сможете сделать с ней ничего безумного, но также и то, что вы можете делать эти безумные вещи с любой другой веткой. У вас есть свобода изменять коммиты, сжимать их, перебазировать ветки — все те способы, которые предоставляет Git для исправления неизбежных оплошностей, которые мы допускаем при разработке. И вам никогда не придется думать: «хм, я уже запустил эту работу?» — вы этого не делали, поскольку ее еще нет в вашей главной ветке. Вы также можете попробовать что угодно, с точки зрения кодирования — взломать, зафиксировать частично законченную работу, переключаться между идеями, что угодно — и быть уверенным, что вы никогда случайно не покажете это кому-либо еще, пока не скажете «Я закончил» и не объедините это с master.

Ключевой частью здесь является идея публикации вашей работы. Если бы это был ваш собственный частный репозиторий, если бы вы поняли, что ваша главная ветка каким-то образом была сломана, это доставило бы вам только неудобства. Но как только подключаются другие люди, вы тоже можете возиться с ними.