Почему Git не сохраняет имя ветки как часть коммита? - PullRequest
10 голосов
/ 18 октября 2011

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

Было много дискуссий о том, как две системы контроля версий Git и Mercurial отличаются друг от друга с точки зрения пользователя (например, В чем разница между Mercurial и Git? и http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/), а главное отличие - обработка веток. Я прочитал многие из этих дискуссий, но я продолжаю задавать себе этот вопрос:

Почему Git не сохраняет имя ветки как часть коммита?

Я действительно не вижу веской причины не делать этого; это означает, что данные не могут просто исчезнуть, потому что на них нет ссылки (тега, ветви или чего-либо еще)

Я считаю хранение ветки в коммите большим плюсом для Mercurial, потому что это затрудняет потерю данных.

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

Ответы [ 2 ]

14 голосов
/ 18 октября 2011

Одним из окончательных источников о ветках для Git и Mercurial является вопрос SO:

" Git и Mercurial - Сравните и сопоставьте "

В ссылках Git (ветки, ветки и теги удаленного отслеживания) находятся вне DAG коммитов.

(Это позволяет управлять различными пространствами имен относительно филиалов, для локальных и удаленных филиалов)

У вас есть аналогичное понятие с Mercurial с ветвями закладок (которые можно толкать / тянуть).

Обратите внимание, что в Git данные не будут "исчезать", потому что нет ссылки: у вас все еще есть reflog для извлечения этих ссылок без ссылок.

Почему Git не сохраняет имя ветки как часть коммита?
Я не вижу веской причины не делать этого

Идея состоит в том, чтобы отделить то, что изменилось (коммиты) от почему m, т. Е. От контекста изменения (название ветви).
Поскольку вы можете слить ускоренную перемотку ветку, фиксации из одной ветви могут быть частью другой в любое время.

Именно поэтому Якуб Наренбский поставил под сомнение дизайн "именованных ветвей" Mercurial (с именами ветвей, встроенными в метаданные набора изменений), особенно с пространством имен global , не очень подходящим для распределенная система контроля версий.

Вы создаете ветку, чтобы изолировать усилия по разработке (см. « Когда вы должны переходить? »), но с DVCS, эта работа по разработке (набор коммитов) должна быть опубликована под любым именем ветви , Какой локальный контекст (имя ветки), который вы определили, может оказаться недействительным после публикации в другом репозитории Git.

8 голосов
/ 18 октября 2011

Базовая модель работы Mercurial - очень простые анонимные ветви, которые образуют ориентированный ациклический граф (DAG), и, поскольку такие имена ветвей не имеют большого значения, вы будете иметь с ними дело намного меньше.Именованные ветви существуют в основном для организационных целей (ветки релизов и т. Д.), Для которых, я бы сказал, глобальное пространство имен имеет больший смысл или, по крайней мере, менее нежелательно.

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

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

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

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

Я думаю, вы могли бы сказать, что философское различие заключается в том, что Mercurial рассматривает именованные ветви как постоянные метаданные, которые дают некоторую дополнительную информацию о строкеcommit, тогда как для Git ветки - это неуправляемая система управления для разработчиков поверх DAG.Между прочим, Mercurial также имеет их под названием «закладки» (начиная с версии 1.8 - основная функция), но на самом деле они скорее инструмент отслеживания и обрабатываются как метки, а не как ветви.

...