Какой из них занимает больше места на диске? Как вы отслеживаете исправления ошибок (мы используем Jira)? Как узнать, какая ветка или репозиторий имеет исправление ошибки? должны существовать другие преимущества/недостатки репозитория против филиала?git branch vs. git репозиторий, который я должен использовать?
Ваш вопрос не имеет большого смысла. Хранилища всегда содержат хотя бы одну ветку, и вы не можете иметь ветку без репозитория. Так что, конечно, ветвь меньше репозитория. Эти две вещи не совсем сопоставимы.
Итак, давайте поговорим о том, что на самом деле содержит репозиторий Git. Есть несколько основных вещей:
работа дерево - это текущее состояние всех ваших файлов, те, что вы работаете. Это может занимать приличное пространство.
объектов - это внутренний путь Git хранит вещи - сгустки представляют содержимое файлов, деревьев, чтобы представить структуру каталогов, обязано представлять снимки рабочего дерева. Это другое, что действительно занимает пространство.
refs - сокращенно для справок: ветви или метки. Они очень, очень легкие - они просто указывают на определенные фиксации. Они занимают немного места, но это так мало, что вы должны думать о них как о совершенно свободных. Теги - фиксированные ссылки; они указывают на одну фиксацию навсегда и используются для таких вещей, как маркировка версий. Филиалы являются подвижными ссылками; с одним проверенным, он продвигается вперед, когда вы совершаете. Это то, что вы будете использовать для представления линий разработки - стабильной ветви, ветви для определенного исправления или функции, которую вы называете.
В каталоге .git есть другие объекты, кроме объектов и ссылок, но теперь они не затрагивают их самих.
Как вы отслеживаете исправления ошибок (мы используем Jira)?Как узнать, какая ветка или репозиторий имеет исправление ошибки?
Это зависит от вас. Как правило, люди вставляют некоторую информацию в свои сообщения о фиксации, чтобы указать, что они затрагивают определенную проблему/проблему. Вероятно, у вас должен быть определенный рабочий процесс, где вы делаете свои исправления в своих филиалах (или, возможно, ветви обслуживания поверх предыдущей версии), и объедините их в свою текущую ветку развития, тем самым разделив исправления с будущей версией. Вы должны иметь возможность сказать что-то вроде «у ветвей мастера и обслуживания всегда есть все исправления ошибок» - хотя, если вы хотите проверить, вы можете сделать что-то вроде git log --grep='bug 1234', предполагая, что вы поместили эту строку в сообщение фиксации!
В общем, нет необходимости иметь несколько клонов одного и того же репозитория проекта. У вас, вероятно, будет центральный, и каждый разработчик будет иметь свои собственные, но когда разработчик опубликует свою работу, они будут помещать его в центральную, и в этом все должно быть важно.
Для меня в репозитории должен быть отдельный проект. Филиал - это «путь» развития проекта. Таким образом, у вас может быть филиал разработки, производственная ветвь и несколько ветвей функций, а также некоторые ветви исправления ошибок. Филиалы могут быть объединены друг с другом по мере необходимости и в конечном итоге объединены в разработку и производство.
Место на диске: весь репозиторий больше, чем создание ветви, поскольку ветка является фактически просто указателем при ее первом создании, а целому репозиторию необходимо сохранить все файлы git снова и снова.
От ветка всегда стоит практически ничего не создавать внутри одного и того же репо (технически говоря, это зависит от того, что вы положили в ветку, но я уверен, что было ясно, что начать).
При клонировании репо, вы мог кончают двукратно требованиям хранения (как для пакетов и для рабочего дерева). Однако это может привести к тому, что клонирование репозиториев обязательно является субоптимальным. Позвольте мне рассказать вам, почему это не всегда верно/
Репо на самом деле всего лишь коллекция ссылок refs. Филиал на самом деле (как при глубоком копировании) занимает столько же, сколько репо, за исключением блоков в уникальных для конкретной ветви единицах. (Обычно там не так много различий).
Локально вы можете клонировать репо практически без дополнительной оплаты, поскольку оно может быть жестко привязано (в пределах той же файловой системы, то есть). Также можно избежать затрат, связанных с использованием другого рабочего дерева, путем клонирования в непокрытое репо (например, с использованием git clone --mirror).
в рамках проекта
На мой взгляд, репо соответствует «игроком» в распределенном процессе. Игроки могут быть «физическими лицами» или «посредниками». У меня есть
на практике только 3-4 типы ветвей являются общими ACROS все репо (master, maint, тестирование, нестабильность).
ВНЕ ПРОЕКТА
Конечно, проект Виль есть это собственный репозиторий (большую часть времени). Я начинаю склоняться к использованию подмодулей, потому что он кажется более гибким, чем гетерогенные ветви (т.разные проекты в отдельных филиалах одного и того же репо)
Одним из больших преимуществ единственного репо является то, что будет очень легко переключать связанное с ним рабочее дерево из одной ветки в другую. Чтобы быть справедливыми эта разница может быть разработана arounnd в двух направлениях:
вы видите, когда вы смотрите на это таким образом, репо начинает быть коллекцией ветвей, с более или менее convential ассоциации к одному рабочему дереву. Соглашения заключаются в том, где возникают реальные различия: вы обычно используйте repo для управления наборами ветвей и различным рабочим деревом.
Ветвь занимает столько же, сколько репо? Вы использовали git? – Cascabel
Как и вы: tyvm, я использую git исключительно; почему бы вам сказать это по-другому? Во всех смыслах и целях в локальной файловой системе не существует большой разницы между 'git branch bla' или' git clone. ../ blo', за исключением рабочих деревьев в не-голых репозиториях; почему вы хотели бы по-разному формулировать это? – sehe
Er, разве рабочее дерево не имеет разницы? И если по какой-либо причине репозитории не находятся в одной файловой системе, вы также удваиваете остальные. (И это просто дисковое пространство - это также займет человеческое время, чтобы синхронизировать их!) Я думаю, что, учитывая тот факт, что ОП задал этот вопрос, вы должны быть немного осторожнее. Создание ветки в основном всегда бесплатно; клонирование репо - нет. Если вы можете настроить это первое предложение, я с удовольствием заберу свой нижний план - остальная часть вашего ответа будет велика, я просто обнаружил, что открытие чрезвычайно вводит в заблуждение. – Cascabel
Филиалы в пределах репо имеют преимущества помимо других комментариев. Многие графические средства (или текстовые интерфейсы) могут показывать вам информацию о коммитах/тегах/etc в ветвях в рамках репо. Эти данные просто не будут доступны, если вы создадите новый репозиторий каждый раз, когда хотите разложить разработку.
У вас также будет более легкое время выражения ветви ответвлений, когда используется внутреннее разветвление. Это просто естественно, тогда как с дополнительными репозициями вы должны отслеживать внешние отношения и управлять ими.
Причина, по которой я спрашиваю, заключается в том, что недавно я учился в какой-то гит-тренировке, и инструктор показывал рабочий процесс, где есть 2 репозитория. Один для dev на главной ветке. Это репо построено и проверено, а затем коммиты будут переведены в «золотое» репо для использования QA. Мы пытаемся выявить причины использования этой модели, а также использовать ветви. Спасибо за комментарии каждого. Я учусь как обычно. :-) – user561638
Если ваше клонированное репо находится на одном диске и использует жесткие ссылки, оно может не использовать гораздо больше места. Больше, чем просто указатель, который использует все ветви, но не обязательно копии всех файлов. – bstpierre
Причина, по которой я спрашиваю, заключается в том, что недавно я учился на некоторых тренировках git, и инструктор показывал рабочий процесс, где есть 2 репозитория. Один для dev на главной ветке. Это репо построено и проверено, а затем коммиты будут переведены в «золотое» репо для использования QA. Мы пытаемся выявить причины использования этой модели, а также использовать ветви. Спасибо за комментарии каждого. Я учусь как обычно. :-) – user561638