Контроль версий: как работает разветвление хранилища на хостинге исходного кода?
Мне просто немного интересно, как средства размещения исходного кода, такие как Bitbucket, GitHub и Launchpad, на самом деле управляют процессом разветвления из основного репозитория и как им удается сэкономить дисковое пространство сервера, когда эти репозитории разветвляются на стороне сервера.
например, если я выполняю ветвление из репозитория на GitHub: занимает ли скопированный код в моем репозитории дополнительное дисковое пространство (я имею в виду, вызывает ли оно двойственность хранилища) от основного на сервере GitHub?
Заранее спасибо.
2 ответа
Основываясь на этом ответе, кажется, что Github, по крайней мере, не копирует хранилище, когда оно разветвлено. Вместо этого он создает новые ветви с добавленными именами пользователей (например, вместо masterмоя разветвленная основная ветка будет указана как lightcc.master).
Это имеет смысл в контексте того, как Git хранит файлы и ссылается на них, и почему он может так эффективно хранить репозитории. Если разветвление является идеальной копией репо, то все, что нужно сделать, - это создать новые ветви (отслеживание ссылок) и отслеживать, у кого есть права на их просмотр, и выдвигать / извлекать из них. Если я разветвляю репо, но никогда не вносю в него изменений, то мои отслеживающие ссылки могут находиться за вышестоящим репо, но они всегда будут такими же, как эти старые коммиты (если исходное репо не выполнит некоторые очень плохие вещи [tm] и переписывает свою историю с помощью перебазирования, сквоша и т. д. в существующие коммиты).
Другими словами, во время первоначального разветвления ни одно из исходных репозиториев не нужно было копировать, поэтому единственная стоимость - это байты, необходимые для создания новых ссылок отслеживания, что составляет ~40 байтов на существующую ветвь. И он может даже быть в состоянии не создавать новые ссылки, пока вы действительно не отклонитесь от исходного репо (или пока вы не настроите ссылку отслеживания и не вытолкнете ее на свою ветвь для данной ветви - так что, вероятно, master является автоматическим?).
Учитывая комментарии, кажется, что это именно то, что делает Github, и, следовательно, действие Gitlab по фактической репликации репо (за ответ 0xcaff) больше похоже на форк Unix, где создается дублирующий процесс. Github очень гибким способом хочет подождать до последнего возможного момента для создания каких-либо новых объектов из-за развилки, фактически отличающегося от исходного репо.
Вероятно, именно поэтому в Github есть некоторые правила, касающиеся полного отделения форка от исходного репо, и почему необходима поддержка. Это будет стоить им места для хранения, и если они позволят всем делать это легко и бесплатно, это может стоить им много места для хранения и т. Д. С течением времени.
Это хороший вопрос, который заставил меня задуматься о том же.
Gitlab
К счастью, существует инструмент управления git-репозиторием с открытым исходным кодом, который называется gitlab.
В gitlab-оболочкеfork_project Функциональные ручки для разветвления. После проверки правильности переданных параметров выполняется следующая строка:
cmd = %W(git clone --bare -- #{full_path} #{full_destination_path})
system(*cmd) && self.class.create_hooks(full_destination_path)
Таким образом, GitLab просто клонирует репозиторий, дублируя исходный код.