Git Branch против Git репозитория, какой из них мне следует использовать?

Question

Какой из них занимает больше места на диске? Как вы отслеживаете исправления ошибок (мы используем Jira)? Как узнать, в какой ветке или хранилище исправлена ​​ошибка? должны быть другие преимущества / недостатки в репозитории по сравнению с веткой?

Answer 1

Ваш вопрос не имеет большого смысла.Репозитории всегда содержат хотя бы одну ветку, и вы не можете иметь ветку без репозитория.Так что, конечно, ветка меньше, чем хранилище.Это не совсем сопоставимые вещи.

Итак, давайте немного поговорим о том, что на самом деле содержит репозиторий Git.Есть несколько основных вещей:

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

• objects - это внутренний способ, которым git хранит вещи - BLOB-объекты для представления содержимого файлов, деревья для представленияструктура каталогов, обязывает представлять снимки рабочего дерева.Это еще одна вещь, которая действительно занимает место.

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

Есть и другие вещи внутри.Каталог git, кроме объектов и ссылок, но не беспокойтесь о них сейчас.

Как вы отслеживаете исправления ошибок (мы используем Jira)?Как вы узнаете, в какой ветке или хранилище исправлена ​​ошибка?

Это зависит от вас.Обычно люди заканчивают тем, что встраивают некоторую информацию в свои сообщения фиксации, чтобы указать, что они обращаются к определенной ошибке / проблеме.Вероятно, у вас должен быть определенный рабочий процесс, в котором вы вносите свои исправления в их собственные ветви (или, возможно, ветку обслуживания поверх предыдущей версии), и объединяете их в свою текущую ветку разработки, тем самым делитесь исправлениями с будущей версией.Вы должны иметь возможность сказать что-то вроде: «В основной ветке и в ветке обслуживания всегда есть все исправления ошибок» - хотя, если вы хотите проверить, вы можете сделать что-то вроде git log --grep='bug 1234', предполагая, что вы поместили эту строку в ваше сообщение о коммите!

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

Answer 2

Создание ветки практически ничего не стоит для создания внутри одного репозитория (технически говоря, это зависит от того, что вы положили в ветку, но я уверен, что было понятно с самого начала).

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

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

Локально, вы можете клонировать репо практически без дополнительных затрат, потому что его можно жестко связать (то есть внутри одной файловой системы).Также можно избежать затрат, связанных с использованием другого рабочего дерева, путем клонирования в голое хранилище (например, с помощью git clone --mirror).

В РАМКАХ ПРОЕКТА

В моемПо мнению репо, репо соответствует «игроку» в распределенном рабочем процессе.Игроки могут быть «физическими лицами» или «ролями».У меня есть

• центральное репо (с возможностью подключения к сети, так что я могу работать из любого места, толкая и вытягивая)
• рабочее репо (по одному на рабочую станцию; с эфемерными и временными ветвями, которые связаны сProofOfConcept-ing, объединение, микрокоммитирование и т. Д.)
• резервное хранилище
• [возможно, клон github для pull-запросов, если восходящие разработчики находятся на github]

На практике только 3-4 типа ветвей распределяются между всеми репо (master, maint, testing, unstable).

ВНЕ ПРОЕКТА

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

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

• вы можете переключить ваше рабочее дерево на ветку из другого хранилища, добавив его в качестве удаленного
• , вы можете иметьотдельная (даже пустая) работа репо с «нелокальным» рабочим деревом путем переопределения переменных среды GIT_WORKTREE

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

Answer 3

Для меня в хранилище должен быть отдельный проект. Филиал - это «путь» развития проекта. Таким образом, у вас может быть ветка разработки, производственная ветка, несколько веток функций и несколько веток для исправления ошибок. При необходимости ветви могут быть объединены друг с другом и в конечном итоге объединены в разработку и производство.

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

Answer 4

Филиалы в репо имеют свои преимущества помимо других комментариев. Многие графические (или текстовые интерфейсы) инструменты могут показать вам информацию о коммитах / тегах / и т. Д. В ветках репо. Эти данные просто не будут доступны, если вы будете создавать новый репозиторий каждый раз, когда захотите сломать разработку.

Вам также будет легче выражать отношения ветвления при использовании внутреннего ветвления. Это просто естественно, тогда как с дополнительными репозиториями вы должны отслеживать и управлять отношениями извне.