Як використовувати github, гілки та автоматичні випуски для управління версіями? [зачинено]

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

Ось деякі речі, над якими я встиг налагодити роботу:

• Push здійснює
• Робота з філіями
• Інтегруйте 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

Відгалуження

Головні стовбури, які назавжди залишаються навколо, є 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), так що всі ваші зміни продовжуватимуться вперед.

Позначення тегами

Під час створення releaseфілії чи hotfixгілки ви збігаєте номер версії відповідно до тегу. З ванільним git, це виглядає приблизно так:

$ 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 для 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 з виправленнями безпеки і т.д. .

Як я можу вказати номер версії? Чи добре мати файл конфігурації, який вказує номер версії, чи є розумніші способи навколо нього? У цьому випадку це буде проект 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