Как использовать github, ветки и автоматические выпуски для управления версиями? [закрыто]

К настоящему времени я понимаю большинство основных концепций Git / Github, однако мне все еще трудно понять общую картину.

Вот некоторые вещи, которые мне удалось получить до сих пор:

• Нажмите коммитов
• Работа с филиалами
• Интегрируйте Github с Travis CI, системой непрерывной интеграции
• Через Travis CI, автоматически создавайте каждый коммит для мастеринга и помещайте релиз в виде ZIP на Github.

Однако до сих пор я работал только над альфа / бета-версиями проектов, поэтому на практике я никогда не видел версионные версии.

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

Как бы я гарантировал, что произойдут следующие вещи:

• Есть разные версии моего проекта, например версии 1.1.0 и 2.0.0
• Иметь возможность устанавливать исправления в версиях, что-то вроде повышения версии до 1.1.1 или 2.0.1 и т. Д.
• Сделайте так, чтобы система непрерывной интеграции автоматически создавала эту версию при фиксации, а в случае успеха публикуйте релиз для этой конкретной версии.

Я сомневаюсь между следующими вариантами:

• Нужно ли использовать теги для каждой версии? Если да, то как автоматическая сборка системы непрерывной интеграции выпускается автоматически?
• Должен ли я создавать ветки для каждой версии? Если это так, разве это не создаст целую тонну веток (например, ветки 1.1 и 2.0, исправления идут в эту ветку, конечно)
• Как бы я указал номер версии? Можно ли иметь файл конфигурации, в котором указан номер версии, или есть более разумные способы обойти это? В этом случае это будет проект Java, если это имеет значение.

Вы должны посмотреть на git-flow . Это отличная (и популярная) модель ветвления.

Git Flow Summary

разветвление

Основными стволами, которые остаются навсегда, являются developи master. masterсодержит ваш последний выпуск и developвашу последнюю "стабильную" версию для разработки.

Участники создают featureветки (с префиксом feature/по соглашению) из develop :

$ git checkout -b feature/my-feature develop

и hotfixветви (с префиксом hotfix/по соглашению) от master:

# hotfix the latest version of master
$ git checkout -b hotfix/hotfix-version-number master

# or hotfix from a specific version
$ git checkout -b hotfix/hotfix-version-number <starting-tag-name>

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

Отделочные Отрасли

Когда участник делает featureветку, он объединяет ее в develop:

$ git checkout develop
$ git merge --no-ff feature/my-feature
$ git branch -d feature/my-feature

Когда они завершают работу с hotfixветкой, они объединяют ее обратно в обе части, masterи developисправление переносится вперед:

$ git checkout master
$ git merge --no-ff hotfix/hotfix-version-number
$ git checkout develop
$ git merge --no-ff hotfix/hotfix-version-number
$ git branch -d hotfix/hotfix-version-number

Это аспект непрерывной интеграции.

релизы

Когда вы готовы начать упаковку релиза, вы создаете releaseветку из вашей «стабильной» developветки (так же, как и создание featureветок). Затем вы врезаете номер версии в тег (описано ниже).

Использование отдельных releaseветок позволяет вам продолжать разработку новых функций, developпока вы исправляете ошибки и добавляете последние штрихи к releaseветке.

Когда вы будете готовы закончить выпуск, вы объединяете releaseветку в обе части masterи develop(точно так же как hotfix), чтобы все ваши изменения были перенесены.

Tagging

Когда вы создаете releaseветку или hotfixветку, вы соответствующим образом увеличиваете номер версии в теге. С ванильным мерзавцем это выглядит так:

$ git tag -a <tag-name> -m <tag-description>

Затем вам также нужно будет вставить теги (отдельно) в ваш удаленный репозиторий:

$ git push --tags

Обычно лучше использовать семантическое управление версиями, в котором ваши версии принимают форму major.minor.hotfix. Основные неровности несовместимы в обратном направлении, в то время как мелкие неровности и неровности исправлений не являются несовместимыми в обратном направлении (если вы не в бета-версии 0.x.x).

сращивание

Как вы видели выше, git-flow предлагает вам объединить ветки с помощью следующей команды:

$ git merge --no-ff <branch-name>

--no-ffОпция позволяет сохранить все истории филиала , не оставляя кучу веток , лежащих вокруг в токе фиксации хранилища (так не беспокойтесь, вы не будете иметь отделение для каждой версии).

Вам также рекомендуется тянуть с

$ git pull --rebase

Таким образом, вы не добавляете много бесполезных коммитов слияния.

Вы можете настроить git для выполнения обеих этих функций по умолчанию в вашем .gitconfig. Я позволю тебе посмотреть это хотя;)

Просмотр версий

Когда кто-то ищет конкретную версию вашей кодовой базы, он может проверить тег по имени:

# checkout in detached HEAD to browse
$ git checkout <tag-name>

# OR checkout and create a new local branch (as you might for a hotfix)
$ git checkout -b <new-branch-name> <tag-name>

Или, если кто-то просматривает сайт на github, в раскрывающемся списке «ветки» также есть вкладка «Теги».

Использование расширения git-flow (рекомендуется)

Мой любимый способ использовать эту модель с расширением git flow для git.

( Правка: Луи порекомендовал вилку AVH, которая работает лучше git describeи может быть более активной сейчас. Спасибо Луи.)

Расширение автоматизирует все беспорядочные части (например, использование merge --no-ffи удаление веток после слияния), чтобы вы могли продолжить свою жизнь.

Например, с расширением вы можете создать функциональную ветку следующим образом:

$ git flow feature start my-feature-name

и закончить это так

$ git flow feature finish my-feature-name

Команды для исправлений и выпусков аналогичны, хотя вместо имени ветви они используют номер версии, например:

# Create hotfix number 14 for this minor version.
$ git flow hotfix start 2.4.14

# Create the next release
$ git flow release start 2.5.0

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

Надеюсь, это поможет :) Я не уверен, как именно вы интегрируете все это с вашей настройкой Travis CI, но я предполагаю, что хитрости доставят вас туда.

Нужно ли использовать тег для каждой версии?

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

Должен ли я создавать ветки для каждой версии?

Конечно! В Git ветвление дешевое / бесплатное, поэтому я использую его при каждом удобном случае. Вы также можете довольно быстро объединять и удалять ветки. Если вы чувствуете, что у вас есть много ветвей, вы всегда можете сократить их позже с помощью некоторого выборочного слияния. Существует множество доступных схем ветвления Git, если вы хотите использовать проверенную и верную схему.

Как бы я указал номер версии?

Тэги обычно так, как вы указываете номер версии, поскольку это относится к git. Если вы говорите о том, как создать версию проекта, или о том, как это лучше всего сделать, вам придется немного покопаться, так как это довольно объективный вопрос. Некоторые проекты остаются в бета-версии навсегда, другие увеличивают целые версии версий, как будто они выходят из моды (глядя на вас, хром)

Нужно ли использовать теги для каждой версии?

Если под «версией» вы подразумеваете набор файлов, которые составляют релиз или кандидата на релиз, тогда я настоятельно рекомендую пометить каждую версию тегами. Если вам нужно обратиться к версии 1.2.7 в будущем, вы хотите искать хеш коммита или просто использовать номер версии?

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

Если да, то как автоматическая сборка системы непрерывной интеграции выпускается автоматически?

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

Должен ли я создавать ветки для каждой версии? Если это так, разве это не создаст целую тонну веток (например, ветки 1.1 и 2.0, исправления идут в эту ветку, конечно)

Я не вижу ветвления как вещь для каждой версии. У меня есть пара проектов, где мои версии все коммиты на masterветке. Я ничего более сложной , чем это не нужно сейчас , потому что ни один проект находится на стадии стабильной и нет никакой необходимости поддерживать более старых версий в долгосрочной перспективе. Но, скажем, я выпускаю 1.0, 1.1, 1.2, потом выпускаю 2.0, и мне все еще нужно поддерживать серию 1.0 с исправлениями безопасности и т. Д. Тогда у меня наверняка будет ветвь, чтобы выпускать выпуски поддержки для серии 1.x ,

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

Наличие единого источника для номера вашей версии, такого как файл конфигурации, является наилучшим способом, поскольку он предотвращает ошибки, которые могут возникнуть в противном случае, если вам придется обновлять номера в нескольких местах. Я говорю из ... хм ... неловкого опыта. Вы выпускаете 1.3 только для того, чтобы обнаружить, что программа все еще сообщает, что это версия 1.2. К сожалению!

В другом ответе mxdubois рекомендовал вам gitflow. Если вы решите использовать gitflow, я бы порекомендовал использовать версию AVH . Оригинальная версия больше не поддерживается. Одно заметное отличие состоит в том, что редакция AVH выполняет слияния релизов, которые позволяют git describeработать интеллектуально. Оригинальная версия выполняет объединение таким образом, что отключаетсяgit describe .

Сканируя ваш список, я вижу версию как ваше внимание, так что ...

Один из способов поддержки версий - это ветки и слияния (или перебазирование).

Так что у тебя есть:

master

тогда вы создаете ветку

v1

затем вы добавляете больше изменений в

master(diff1)

тогда вы создаете ветку

v3

затем вы добавляете больше изменений в

master(diff2)

В настоящее время:

Чтобы обновить версию 2, вы теперь делаете

git checkout v2
git merge master  # for the changes you want to bring into version 2
# rebasing is also an option
# resolve any merge conflicts
# Done.

Обновить версию 3

git checkout v3
git merge master

Выше для оптовых обновлений.

Вероятно, более вероятно, что вы захотите выбрать конкретные изменения, для которых есть

git cherry-pick

Подробнее о сборке вишни на http://git-scm.com/docs/git-cherry-pick