Тег представляет версию конкретной ветви в данный момент времени. Ветвь представляет собой отдельный поток разработки, который может выполняться одновременно с другими разработками на той же кодовой базе. Изменения в ветке в конечном итоге могут быть объединены обратно в другую ветку для их объединения.
Обычно вы помечаете конкретную версию, чтобы вы могли ее воссоздать, например, это версия, которую мы отправлено XYZ Corp . Ветвь - это скорее стратегия для предоставления текущих обновлений конкретной версии кода при продолжении ее разработки. Вы создадите ветвь доставленной версии, продолжите разработку в основной строке, но исправите ошибки в ветке, которая представляет доставленную версию. В конце концов, вы Я объединю эти исправления ошибок обратно в основную строку. Часто вы будете использовать и ветвление, и теги вместе. У вас будут различные теги, которые могут применяться как к основной линии, так и к ее ветвям, отмечая определенные версии (например, доставленные клиентам) вдоль каждой ветки, которую вы, возможно, захотите воссоздать - для доставки, диагностики ошибок и т. Д.
На самом деле это сложнее, чем это - или настолько сложно, насколько вы хотите, - но эти примеры должны дать вам представление о различиях.
простой ответ:
ответвление: текущий указатель ответвления перемещается с каждым передавать репозиторию
, но
тег: фиксация, которую тег точки не изменяет, на самом деле тег, является снимком той фиксации.
С теоретической точки зрения:
С технической точки зрения :
refs / tags /
, и может указывать на объекты тегов (аннотированные и, возможно, подписанные теги GPG) или непосредственно на объект фиксации (менее используемый упрощенный тег для локальных имен), или в очень редких случаях даже на объект дерева или объект blob (например, подпись GPG). refs / Heads /
и могут указывать только на объекты фиксации . Указатель HEAD
должен ссылаться на ветвь (символическая ссылка) или непосредственно на фиксацию (отдельная HEAD или безымянная ветвь). refs / remotes / /
namespace и следуйте обычным ветвям в удаленном репозитории
. См. также gitglossary manpage:
branch
A "branch "- активное направление развития. Самая последняя фиксация в ветке называется вершиной этой ветки. На вершину ветви ссылается головка ветви, которая перемещается вперед по мере того, как в ветви выполняется дополнительная разработка. Один репозиторий git может отслеживать произвольное количество веток, но ваше рабочее дерево связано только с одним из них («текущая» или «извлеченная» ветвь), а HEAD указывает на эту ветвь.
tag
Ссылка, указывающая на тег или объект фиксации. В отличие от головы, тег не изменяется при фиксации. Теги (не объекты тегов) хранятся в
$ GIT_DIR / refs / tags /
. [...]. Тег чаще всего используется для обозначения определенной точки в цепочке предков фиксации.tag object
Объект, содержащий ссылку, указывающую на другой объект, который может содержать сообщение, как объект фиксации. Он также может содержать подпись (PGP), и в этом случае он называется «объектом подписанного тега».
Исходя из CVS, вам нужно понять, что вы больше не создаете каталогов при настройке ветки.
Больше никаких «липких тегов» (которые можно применить только к одному файлу) или «тегов ветвей».
Ветвь и теги - это два разных объекта в Git, и они всегда применяются к репозиторию all .
Вам больше не нужно (на этот раз с SVN) явно структурировать свой репозиторий с помощью:
branches
myFirstBranch
myProject
mySubDirs
mySecondBranch
...
tags
myFirstTag
myProject
mySubDirs
mySecondTag
...
Это Структура основана на том факте, что CVS - это система ревизий , а не система версий (см. Контроль версий или Контроль версий? ).
Это означает, что ветки эмулируются с помощью тегов для CVS, копии каталогов для SVN.
Ваш вопрос имеет смысл, если вы привыкли проверять тег, и начинаете работать с ним .
Чего не стоит;)
Тег должен представлять неизменяемый контент, используемый только для доступа к нему с гарантией получения того же контента каждый раз.
В Git история изменений представляет собой серию коммитов, образующих график.
Ветвь - это один путь к этому графу.
x--x--x--x--x # one branch
\
--y----y # another branch
1.1
^
|
# a tag pointing to a commit
См. Ответ Якуба Наребски для всех технических деталей, но, честно говоря, на данном этапе вам (пока) не нужны все детали;)
Суть в том, что : тег является простым указателем на фиксацию, вы никогда не сможете изменить его содержимое. Вам нужна ветка.
В вашем случае каждый разработчик, работающий над определенной функцией:
Теги могут быть подписанными или беззнаковыми ; ветви никогда не подписываются.
Подписанные теги никогда не могут перемещаться, потому что они криптографически привязаны (с подписью) к определенной фиксации. Беззнаковые теги не связаны, и их можно перемещать (но перемещение тегов не является нормальным вариантом использования).
Ветви могут не только перемещаться в другую фиксацию, но ожидается , чтобы это сделать. Вы должны использовать ветку для своего локального проекта разработки. Не имеет смысла фиксировать работу в репозитории Git «на теге».
Git Parable объясняет, как создается типичная DVCS и почему их создатели сделали то, что они сделали. Также вы можете взглянуть на Git for Computer Scientist ; в нем объясняется, что делает каждый тип объекта в Git, включая ветви и теги.