Мне трудно понять, как использовать теги против веток в git.
Я просто перевел текущую версию нашего кода с cvs на git, и теперь я буду работать над подмножеством этого кода для определенной функции. Некоторые другие разработчики тоже будут работать над этим, но не все разработчики в нашей группе будут заботиться об этой функции. Должен ли я создавать ветку или тег? В каких ситуациях я должен использовать один против другого?
Тег представляет версию конкретной ветки в данный момент времени. Ветвь представляет собой отдельный поток разработки, который может выполняться одновременно с другими разработками в той же кодовой базе. Изменения в ветке могут быть в конечном итоге объединены в другую ветвь, чтобы объединить их.
Обычно вы помечаете конкретную версию, чтобы ее можно было воссоздать, например, эту версию мы отправили в XYZ Corp. Ветка - это скорее стратегия для обеспечения текущих обновлений конкретной версии кода, продолжая при этом сделать разработку на нем. Вы создадите ветку доставленной версии, продолжите разработку на основной линии, но исправите ошибки в ветке, которая представляет доставленную версию. В конце концов, вы объедините эти исправления ошибок с основной строкой. Часто вы будете использовать как ветвление, так и тегирование вместе. У вас будут различные теги, которые могут применяться как к основной линии, так и к ее ветвям, отмечая определенные версии (например, доставленные клиентам) вдоль каждой ветки, которую вы можете захотеть воссоздать - для доставки, диагностики ошибок и т.д.
Это на самом деле сложнее, чем это - или так сложно, как вы хотите, чтобы это сделать - но эти примеры должны дать вам представление о различиях.
С точки зрения Теоретическая:
Из технической точки зрения:
refs/tags/ и могут указывать на тег-объекты (аннотированные и необязательные теги подписи GPG) или непосредственно на объект-фиксацию (менее используемый легкий тег для локальных имен) или в очень редкие случаи даже для объекта дерева или объекта blob (например, подпись GPG).refs/heads/ и могут указывать только на объекты фиксации. Указатель HEAD должен ссылаться на ветвь (символическая ссылка) или непосредственно на фиксацию (отдельная головная или неназванная ветвь).refs/remotes/<remote>/ и следуют за обычными ветвями в удаленном репозитории <remote>.См. также gitglossary manpage:
ветвь
"Ветвь" - это активная линия развития. Последняя фиксация на ветке называется концом этой ветки. Наконечник ветки ссылается на головку ветки, которая движется вперед, когда дополнительная ветка развивается на ветке. Единственный репозиторий GIT может отслеживать произвольное количество ветвей, но ваше рабочее дерево связано только с одним из них (ветвь "current" или "check out" ), а HEAD указывает на эту ветку.
тег
A ref указывает на тег или объект commit. В отличие от головы, тег не изменяется с помощью фиксации. Теги (не теги) хранятся в
$GIT_DIR/refs/tags/. [...]. Тег чаще всего используется для обозначения определенной точки в цепочке родословной фиксации.объект тега
Объект, содержащий ref, указывающий на другой объект, который может содержать сообщение точно так же, как объект фиксации. Он также может содержать подпись (PGP), и в этом случае он называется "подписанным объектом тега".
Если вы думаете о своем репозитории как о книге, в которой говорится о прогрессе в вашем проекте...
Вы можете придумать ветку как одну из тех липких закладок:
В новом репозитории имеется только один из них (называемый master), который автоматически переместится на последнюю страницу (думаю, фиксация), которую вы написали. Тем не менее, вы можете создавать и использовать больше закладок, чтобы отметить другие точки интереса в книге, чтобы вы могли быстро вернуться к ним.
Кроме того, вы всегда можете переместить определенную закладку на другую страницу книги (например, используя git-reset); представляющие интерес, обычно меняются со временем.
Вы можете думать о тэгах как заголовках глав.
Он может содержать заголовок (думаю аннотированные теги) или нет. Тег похож, но отличается от ветки, поскольку он отмечает точку, представляющую исторический интерес в книге. Чтобы сохранить свой исторический аспект, как только вы поделились тегом (то есть нажали его на общий пульт), вы не должны перемещать его в другое место в книга.
Что вам нужно понять, исходя из CVS, заключается в том, что вы не создаете каталоги при настройке ветки.
Больше "липкой метки" (которая может быть применена только к одному файлу) или "тега ветвления".
Разделитель и теги - это два разных объекта в Git, и они всегда применяются ко всему репо.
Вы больше не будете (с 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
См. Ответ Jakub Narębski для всех технических вопросов, но, откровенно говоря, на данный момент вам не нужны (все же) все детали;)
Главное: тег, являющийся простым указателем на фиксацию, никогда не сможет изменять его содержимое. Вам нужна ветка.
В вашем случае каждый разработчик работает с определенной функцией:
Вместо того, чтобы напрямую отслеживать ветки ваших коллег, вы можете отслеживать только ветку одного "официального" центрального хранилища, к которому все подталкивают свою работу, чтобы интегрировать и совместно использовать все для этой конкретной функции.
Филиалы сделаны из дерева и растут из ствола дерева. Теги изготовлены из бумаги (производные из дерева) и висят как рождественские украшения из разных мест в дереве.
Ваш проект - это дерево, и ваша функция, которая будет добавлена в проект, будет расти на ветке. Ответ - ветка.
Похоже, что лучший способ объяснить, что теги действуют как ветки только для чтения. Вы можете использовать ветку как тег, но вы можете непреднамеренно обновить ее новыми коммитами. Теги гарантированно указывают на одно и то же сообщение, если они существуют.
Теги могут быть либо подписаны, либо без знака; ветки никогда не подписываются.
Подписанные теги никогда не могут перемещаться, потому что они криптографически связаны (с подписью) с определенным фиксатором. Неподписанные теги не привязаны, и их можно перемещать (но перемещение тегов не является обычным прецедентом).
Филиалы могут не только перейти на другую фиксацию, но должны сделать это. Вы должны использовать ветку для своего локального проекта разработки. Не имеет смысла совершать работу с репозиторием Git "на теге".
Git Parable объясняет, как создается типичный DVCS и почему их создатели сделали то, что они сделали. Кроме того, вы можете взглянуть на Git для Computer Scientist; он объясняет, что делает каждый тип объекта в Git, включая ветки и теги.
Мне нравится думать о ветвях, где вы идете, теги, где вы были.
Тег похож на закладку определенного важного момента в прошлом, например версию версии.
В то время как ветка является определенным путем, проект идет вниз, и, таким образом, маркер ветки продвигается вместе с вами. Когда вы закончите, вы слейте/удалите ветвь (т.е. маркер). Конечно, в этот момент вы можете пометить эту фиксацию.
Тег используется для обозначения версии, более конкретно она ссылается на точку в ветке. Филиал обычно используется для добавления функций в проект.
просто:
Ожидается, что теги всегда будут указывать на одну и ту же версию проекта, в то время как ожидается, что главы будут продвигаться по мере развития разработки.
простой ответ:
ветка: текущий указатель ветки перемещается с каждым коммитом в хранилище
но
tag: коммит, на который указывает тег, не меняется, фактически тег является снимком этого коммита.
Магистральный: будет основной частью разработки, начиная с начала проекта до настоящего времени.
Филиал: будет копией кода, полученного из определенной точки в соединительной линии, которая используется для внесения серьезных изменений в код, в то время как сохраняя целостность кода в багажнике. Если основной изменения работают в соответствии с планом, они обычно сливаются обратно в Ствол.
Тег: будет точкой во времени на соединительной линии или ветке, которую вы хотите сохранить. Две основные причины сохранения: либо это основной выпуск программного обеспечения, будь то альфа, бета, RC или RTM, или это наиболее стабильная точка программного обеспечения до были применены основные изменения на стволе.