Есть ли вред тому, что ветка git "стареет"?

Question

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

Мой реальный вопрос заключается в следующем: если я разрабатываю только небольшую функцию (например, простой анализатор времени регулярных выражений), после объединения этой ветви обратно в ствол, что происходит (или должно происходить) с этой веткой? Он просто сидит там? Поскольку я создал его для этой очень специфической функции, я не могу вспомнить причину, по которой мне пришлось бы вернуться и использовать ветку. Должен ли я как-то пометить эту ветку как несуществующую, или я просто продолжаю и забываю об этом?

Спасибо

Answer 1

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

Именно поэтому при слиянии я намеренно отключаю ускоренную пересылку с помощью git merge --no-ff. Это сохраняет структуру отрасли в истории. Затем я могу удалить метку ветви (git branch -d branch_name), точка слияния содержит имя ветви и очистить набор ветвей.

Напротив, при работе с веткой я предпочитаю перебазировать ветку восходящего потока. Это делает историю ветки красивой и чистой, свободной от большого количества слияний и разрешения конфликтов. Как правило, перед слиянием я делаю перебазирование вверх по течению, чтобы упростить работу по интеграции (как автор ветки я могу исправить конфликты и неработающие тесты) и полученного в результате очистителя слияния.

Этот подход сохраняет историю ветвей, в то же время предотвращая засорение старых веток, которые больше не разрабатываются. Это делает визуализацию истории с помощью gitk или GitX очень полезной.

Я согласен с основными пунктами в статье, которую вы связали, так как вы получаете все больше и больше крупных ветвей функций, над которыми работают одновременно, появляется все больше и больше шансов на конфликт и интеграционные проблемы. Изоляция, которая делает их такими полезными, становится пассивом. Одним из решений является отсутствие больших старых ветвей функций. Если вы можете разбить ветвь объекта на более мелкие части, которые можно завершить и интегрировать, то вы избежите этой проблемы. Это часто полезно по многим другим причинам, например, из-за плохого слуха, который должен просматривать код.

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

Я свободно признаю, что, может быть, слишком много читаю в этом, но один из, возможно, существенных недостатков в статье заключается в том, что ветви названы по имени people , а не features . Это подразумевает, что каждая ветвь предназначена для «того, над чем работает Джим», а не для «добавления синих виджетов». Это подразумевает ряд проблем развития ...

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

Во многом это не техническая проблема, а социальная проблема. Многое из этого может быть решено сильным использованием хорошего трекера, тесно связанного с контролем версий, такого как Github. Основное изменение:

• ветви должны быть для определенных функций
• разработчики должны сообщить о проблеме до того, как уйдет и сделает кучу работы
• никто не "владеет" функцией (хотя они могут нести ответственность за нее)

Этот второй, к сожалению, не одобряется политиками отслеживания ошибок большинства проектов. Желание подготовить патч перед сообщением об ошибке очень сильное.

Хорошее управление филиалами требует хорошей социализации, чему способствует хороший трекер проблем с сильной интеграцией контроля версий и приветливой политикой.

Answer 2

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

                                  your branch
                                    main
                                      |
  (main)  -------x----x----x-x---x----x
                  \                  /
  (your branch)    \--x--x-x--x-x---/

На этом этапе, если вы удалите свою ветку с помощью "git branch -d", у вас останется:

                                    main
                                      |
  (main)  -------x----x----x-x---x----x
                  \                  /
  (your branch)    \--x--x-x--x-x---/

Как видите, коммиты из вашей ветки все еще в безопасности. Все, что изменилось, это то, что указатель под названием «ваша ветка» был удален.

Обратите внимание, что если бы вы не слились с main, то "git branch -d" потерпел бы неудачу. Если вы принудительно удалите его в этот момент, у вас останется:

                                  main
                                    |
  (main)  -------x----x----x-x---x--x
                  \
  (your branch)    \--x--x-x--x-x

Поскольку на этом этапе указатель ветки отсутствует, коммиты "висят" и будут удалены в следующий раз, когда git выполнит сборку мусора.

Короче говоря, если ваша ветвь была объединена, вы можете и должны удалить ее. Если оно не было объединено, вы не должны.

Answer 3

Удалите его, если он вам больше не нужен.Если позже вы поймете, что вам это нужно снова, вы можете создать его снова.И поскольку вы объединили изменения обратно в «ствол», ничего не потеряно.

Answer 4

Две вещи, на которые следует обратить внимание:

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

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

Вы можетеиспользуйте некоторую смесь этих техник, например всегда перебазируйте, затем переименуйте ветку foo в landed-foo, а затем через заданный интервал (скажем, один выпуск или 30 дней) удалите ветку landed-foo.

Примечаниечто если вы не перебазируете (и не выполните какие-либо тесты для перебазированной версии), у вас нет возможности быть уверенным в том, что ошибка, обнаруженная после ее появления, фактически была в коде, как разработано, а не вызвана влиянием ее слияния после разработкив этом случае вы можете сохранить ветку на некоторое время.Это будет происходить чаще с инвазивными / очень большими изменениями, не так, как в сценарии вашего вопроса.

Answer 5

Единственные причины, которые я вижу, вы хотели бы сохранить это:

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