Является ли создание и удаление большого количества веток в git плохим?

Question

У меня есть основная ветвь master, которая содержит стабильный код. Каждый раз, когда я хочу создать что-то новое, я get checkout -b 'development', добавляю новый код, затем объединяю его с мастером и удаляю ветку разработки.

Однако, создает ли это большую базу данных репо, чем просто держать ветку разработки и объединять в ней мастер (так что разработка актуальна), прежде чем я добавлю что-то новое? Все эти временные ветки разработки занимают дополнительное место в репо?

Answer 1

Создание временных веток для отдельных тем / функций / задач хорошо . Ты делаешь это правильно. Не останавливайтесь только на «разработке» - «featureA», «bugX», «bugX-testing», всё, что вам нужно, сделайте это!

Ветвь практически не занимает места. Это указатель на коммит в его подсказке, поэтому он представлен в виде файла (.git/refs/heads/branch-name), содержимое которого является просто SHA1 этого коммита. Маленький крошечный. В конце концов они могут быть собраны в файл packed-refs, который представляет собой просто строку на ветку - имя и SHA1, даже меньше, чем оригинал! (Git делает это, чтобы избежать слишком большого количества файлов в репо, который имеет, скажем, 1000 тегов минорных / выпусков вспомогательных версий в своей истории.) Они также имеют рефлоги, которые записывают строку каждый раз, когда позиция изменений в ветке (попробуйте git reflog show, чтобы увидеть reflog для HEAD), но опять же, это довольно мало - и оно удаляется, когда вы удаляете ветку.

Answer 2

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

Учитывая то, как вы, похоже, используете ветки, я думаю, что вы выиграете от nvie GitFlow модель ветвления и вспомогательное расширение (ссылка на пояснительный пост в блоге) в виде простого, чистого способ максимально использовать ветвление для управления релизами. (В основном, более отточенный подход к тому, что вы, кажется, уже делаете)

Answer 3

Это неплохо и рекомендуется для экспериментального кода.

Если вас беспокоит размер вашего репо, используйте «git gc», чтобы собрать мусор и сжать его.