Чем тег отличается от ветки в Git? Что я должен использовать здесь?

Question

Мне трудно понять, как использовать теги против филиалов в git .

Я только что переместил текущую версию нашего кода с cvs на git , и теперь я собираюсь работать над подмножеством этого кода для конкретной функции. Несколько других разработчиков будут работать над этим, но не все разработчики в нашей группе будут заботиться об этой функции. Должен ли я создавать ветку или тег? В каких ситуациях я должен использовать одно против другого?

Answer 1

С теоретической точки зрения:

• теги являются символическими именами для данной ревизии . Они всегда указывают на один и тот же объект (обычно: на одну и ту же ревизию); они не меняются.
• ветви являются символическими именами для линии развития . Новые коммиты создаются в верхней части ветки. Указатель ветви естественным образом продвигается, указывая на все новые и новые коммиты.

---

С технической точки зрения:

• теги находятся в refs/tags/ пространстве имен и могут указывать на теговые объекты (аннотированные и необязательно подписанные теги GPG) или непосредственно на фиксировать объект (меньше используется облегченный тег для локальных имен), или в очень редких случаях даже для объекта дерева или объекта блоба (например, подпись GPG).
• ветви находятся в пространстве имен refs/heads/ и могут указывать только на объекты фиксации . Указатель HEAD должен ссылаться на ветвь (символьная ссылка) или непосредственно на коммит (отсоединенный HEAD или безымянная ветвь).
• ветви удаленного отслеживания находятся в пространстве имен refs/remotes/<remote>/ и следуют обычным веткам в удаленном хранилище <remote>.

---

См. Также gitglossary manpage:

филиал

«Филиал» - это активная линия развития. Самый последний коммит на ветке называется кончиком этой ветки. На кончик ветки ссылается глава ветки, которая движется вперед по мере того, как на ветке делается дополнительная разработка. Один репозиторий git может отслеживать произвольное количество веток, но ваше рабочее дерево связано только с одной из них (ветвью "текущий" или "извлеченный"), и HEAD указывает на эту ветвь.

бирка

Ссылка, указывающая на тег или объект коммита. В отличие от головы, тэг не изменяется коммитом. Теги (не теговые объекты) хранятся в $GIT_DIR/refs/tags/. [...]. Тэг чаще всего используется для обозначения определенной точки в цепочке предков коммитов.

тег объекта

Объект, содержащий ссылку, указывающую на другой объект, который может содержать сообщение, подобное объекту фиксации. Он также может содержать подпись (PGP), и в этом случае он называется «объект подписанного тега».

Answer 2

Тег представляет версию определенной ветви в данный момент времени. Ветвь представляет собой отдельный поток разработки, который может выполняться одновременно с другими разработками в той же кодовой базе. Изменения в ветке могут быть в конечном итоге объединены в другую ветвь, чтобы объединить их.

Обычно вы помечаете конкретную версию, чтобы ее можно было воссоздать, например, эту версию мы отправили в XYZ Corp. Ветка - это скорее стратегия для обеспечения текущих обновлений определенной версии кода. продолжая делать разработку на нем. Вы создадите ветку доставленной версии, продолжите разработку на основной линии, но исправите ошибки в ветке, которая представляет доставленную версию. В конце концов, вы объедините эти исправления ошибок с основной строкой. Часто вы будете использовать как ветвление, так и тегирование вместе. У вас будут различные теги, которые могут применяться как к основной линии, так и к ее ветвям, отмечая определенные версии (например, доставленные клиентам) вдоль каждой ветви, которую вы можете захотеть воссоздать - для доставки, диагностики ошибок и т. Д.

Это на самом деле сложнее, чем это - или так сложно, как вы хотите, чтобы это сделать - но эти примеры должны дать вам представление о различиях.

Answer 3

Если вы думаете о своем хранилище как о книге, в которой рассказывается о прогрессе в вашем проекте ...

Филиалы

Вы можете думать о ветке как об одной из этих липких закладок :

В новом репозитории есть только один из них (называемый master), который автоматически переходит на последнюю страницу (например, commit ), которую вы написали. Тем не менее, вы можете создавать и использовать больше закладок, чтобы отмечать другие интересные места в книге, чтобы вы могли быстро вернуться к ним.

Кроме того, вы всегда можете переместить определенную закладку на другую страницу книги (например, с помощью git-reset); достопримечательности обычно меняются со временем.

Метки

Вы можете думать о тегах как заголовки глав .

Может содержать заголовок (например, аннотированные теги ) или нет. Тег похож на ветку, но отличается от нее тем, что отмечает точку исторического интереса к книге. Чтобы сохранить его исторический аспект, после того, как вы поделились тегом (т.е. перенесли его на общий пульт), вы не должны перемещать его в другое место в книге.

Answer 4

Что вам нужно понять, исходя из CVS, так это то, что вы больше не создаете каталогов при настройке ветви.
Нет больше «прикрепленного тега» (который может быть применен только к одному файлу) или «тега ветвления».
Ветка и теги - это два разных объекта в Git, и они всегда применяются к репо all .

Вам больше не нужно (с SVN на этот раз) явно структурировать ваш репозиторий с помощью:

branches
   myFirstBranch
     myProject
       mySubDirs
   mySecondBranch
     ...
tags
   myFirstTag
     myProject
       mySubDirs
   mySecondTag
   ...

Эта структура проистекает из того факта, что CVS является ревизионной системой , а не системой версий (см. Контроль версий и Revision Control? ).
Это означает, что ветви эмулируются через теги для CVS, копии каталогов для SVN.

Ваш вопрос имеет смысл, если вы привыкли извлекать тег, и начинает работать в нем .
Что вы не должны;)
Тег должен представлять неизменный контент, используемый только для доступа к нему с гарантией получения одного и того же контента каждый раз.

В Git история ревизий - это серия коммитов, образующих граф.
Ветвь - это один путь этого графа

x--x--x--x--x # one branch
    \ 
     --y----y # another branch
       1.1
        ^
        |
        # a tag pointing to a commit

• Если вы извлекаете тег, вам нужно создать ветку, чтобы начать с него работать.
• Если вы извлечете ветку, вы сразу увидите последний коммит ('HEAD') этой ветки.

См. Ответ Якуба Наренбского обо всех технических деталях, но, честно говоря, на данный момент вам не нужны (пока) все детали;)

Суть в том, что тег, являющийся простым указателем на коммит, никогда не сможет изменить его содержимое. Вам нужна ветка.

---

В вашем случае каждый разработчик работает над определенной функцией:

• должен создать собственную ветку в своем репозитории
• отслеживать ветки из репозиториев своих коллег (те, которые работают с той же функцией)
• тянет / толкает, чтобы поделиться своей работой со сверстниками.

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

Answer 5

Ветки сделаны из дерева и растут из ствола дерева. Метки сделаны из бумаги (производная от дерева) и висят, как рождественские украшения из разных мест на дереве.

Ваш проект - это дерево, и ваша функция, которая будет добавлена ​​в проект, будет расти на ветке. Ответ отраслевой.

Answer 6

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

Answer 7

Теги могут быть со знаком или без знака ; ветви никогда не подписываются.

Подписанные теги никогда не могут перемещаться, потому что они криптографически связаны (с подписью) с определенным коммитом. Беззнаковые теги не связаны, и их можно перемещать (но перемещение тегов не является нормальным вариантом использования).

Ветви могут не только перейти к другой фиксации, но и ожидаются . Вы должны использовать ветку для вашего местного проекта развития. Не имеет смысла фиксировать работу с Git-репозиторием «по тегу».

Answer 8

Притча Git объясняет, как создается типичный DVCS и почему их создатели сделали то, что сделали. Также вы можете взглянуть на Git for Computer Scientist ; он объясняет, что делает каждый тип объекта в Git, включая ветви и теги.

Answer 9

Мне нравится думать о ветвях как , куда вы идете , тегах как , где вы были .

Тег ощущается как закладка определенного важного момента в прошлом, такого как выпуск версии.

В то время как ветвь - это конкретный путь, по которому идет проект, и, таким образом, маркер ветки продвигается вместе с вами. Когда вы закончите, вы объедините / удалите ветку (то есть маркер). Конечно, в этот момент вы можете пометить этот коммит.

Answer 10

Тег используется для обозначения версии, более конкретно, он ссылается на момент времени на ветви. Ветвь обычно используется для добавления функций в проект.