Як правильно відправити реліз на git stack overflow російською

Я використовую гіт для свого проекту, працюю один.

І ось готовий у мене реліз першої версії, я дотримуюся раді цій статті на Хабре і тут описано, що потрібно створити гілку релізу і як вона буде доведена до випуску то злити її в майстер і в Девелоп, після чого видалити її.

Але навіщо мені створювати гілку релізу якщо у мене в гілці Девелоп вже все готово. Я так розумію, що мені потрібно її зливати в майстер відразу і позначати тегом і продовжувати далі вести проект в дефелопе.

Але у мене локально є тільки гілка Девелоп і видалено є Девелоп і майстер.

Питання ось у чому, чи буде правильно зробити Комміт на локальній гілці Девелоп. поставити на неї таг, злити в віддалений Девелоп і вже віддалений Девелоп смержіть з віддаленим майстром.

Я просто не впевнений, що ця концепція правильна і друге я не впевнений, що можна робити Мержа на видалення гілках.

Порадьте як правильно зробити?

Спочатку трохи теорії, щоб обґрунтувати практичні рекомендації. Сподіваюся, занудьгувати не встигнете.

А для команд, які

нечисленні, приблизно до 10 осіб;
працюють по agile і дроблять завдання настільки, щоб вони робилися за день-два;
використовують в основному найостаннішу версію продукту і не повинні тягти старі версії;

git flow просто не потрібен. Він створює більше проблем, ніж вирішує.

Але навіщо мені створювати гілку релізу якщо у мене в гілці Девелоп вже все готово

Правильно! Вам і Девелоп-то не потрібен.

Для невеликих команд і соло-розробки більше підходять «легковагі» моделі організації робочого процесу. Найпопулярніша називається GitHub Flow, від неї відрізняються деякими деталями і більшій глибиною опрацювання GitLab Flow і Simple Git Flow (Atlassian).

Суть всіх простих моделей робочого процесу

Є єдина стабільна (постійна, довгоживуча) гілка master.
Будь-яка фіча або виправлення бага робиться в окремій гілці, яка розгалужується від master.
Як тільки фіча або багфикс готовий, пройшов рев'ю і тестування, відповідна гілка Мержа в master. Потім гілка обов'язково видаляється, щоб не збирати непотріб.

Крім очевидної простоти перевага в тому, що код не пишеться «в стіл» і не залежується в релізних гілках, а випускається як можна швидше. Чим коротше шлях від ідеї до продакшена - тим краще для справи. Клієнти (користувачі) швидше отримують нові фічі, а ви швидше отримуєте зворотний зв'язок від клієнтів і гроші за ці фічі.

Як створювати і називати гілки

Прийнято починати назву feature-гілки з номера завдання в трекері завдань.

Ви ж десь ведете список завдань? Почніть, якщо немає, і ось чому:

Щоб не тримати їх в голові, тому що це ненадійно і з'їдає ресурси мозку
Щоб ви могли їх оцінювати, планувати, вибирати пріоритети
Щоб зберігати інформацію про баги і способах їх відтворити.
Тренування для командної роботи; ви напевно не будете все життя працювати соло.
Якщо проект в опенсорс, то хто-небудь прийде і заведе вам задачу-побажання або завдання-багрепорт. Або візьме вашу задачу і зробить, просто так, задарма. Не можна зробити задачу, яка не описана, вірно?

Формулюйте маленькі, атомарні завдання, щоб робота в гілці йшла 1-3 дні, не більше. Це важливо для роботи соло і критично важливо для командної роботи.

Локальні гілки бажано теж пушіть на віддалений сервер, це хороший спосіб не втратити код, коли пролив чай в ноутбук, rm -rf /. пожежа, крадіжка, метеорит.

Як Мержа гілки

Є два основних способи:

Гілку можна замержіть вручну, локально. У командному рядку це так:

Якщо ви використовуєте GitHub, GitLab, Bitbucket - можна відкрити пулл / Мержа-реквест і потім його замержіть. При цьому фактично мержатся віддаленого гілки, потім вам потрібно буде підтягнути собі результат Мержа (git pull). Цей спосіб допомагає проводити інспекцію коду в команді і різний автоматизоване тестування, але якщо ви працюєте один, Мержа-реквести майже не потрібні.

особливості:

Мержа гілки потрібно через --no-ff. щоб завжди створювався Мержа-кому. Він допоможе вам переглядати історію, він допомагає знайти гілку, в якій був зроблений Ком. і точно позначає місце, де цю гілку замержілі, його можна скасувати за допомогою git revert. Любіть Мержа-коммітов, вони вам знадобляться.
Не потрібно Мержа в master то, що не готове, що не дороблено і т.п. Гілка master священна, в ній завжди повинен бути робочий код.
Ніколи не потрібно Мержа гілку master в гілку фичи. Винятки - підтягування коду з мажорного релізу в довгоживучу гілку, різні гілки для різних тестових оточень і інші ситуації, які майже не зустрічаються при соло-розробці невеликого проекту.

Щоб запущено теги на віддалений сервер, робіть так:

Параметр --follow-tags потрібен для того, щоб запущено тільки анотовані теги і не пушіть легковагі (lightweight), якщо вони у вас раптом є.

Чи не відзначайте релізний тегами коммітов в feature-гілках. Замержілі, протестували результат, відзначили тегом отриманий Мержа-кому. Все, що не в master. не може бути релізом.

Для створення номерів версій використовуйте семантичне Версіонування.

Випускайте релізи якомога частіше

Оскільки гілка master завжди повинна містити працюючий код і ви завжди Мержа в неї тільки готові фичи, кожен Мержа - це фактично маленький реліз. При цьому обов'язково кожен раз збирати заново додаток. Не факт, що його потрібно відразу випускати для всіх користувачів - занадто часті оновлення програми можуть їх дратувати.

Але постарайтеся зібрати групу бета-тестерів (почніть з себе), для яких ви будете випускати додаток після кожного Мержа гілки в master. Таким чином ви прискорите отримання зворотного зв'язку, а чим швидше цикл ОС, тим швидше розвивається ваша програма і ваші навички. В цьому суть Agile.

З урахуванням вищесказаного, пропоную такий план дій.

Замержіть (злити) develop в master.
Повісити на отриманий Мержа-комун тег.
Видалити гілку develop і не згадувати про неї до пори.

А в цілому за відповідь спасибі! Я начебто так і зробив. Тільки я спочатку створив гілку у себе локально від віддаленого майстра git checout -b master origin # 47; master потім на гілку Девелоп зробив Комміт і повісив таг і злив цю локальну Девелоп в локальний майстер. Потім зробив пуш і тагуа і гілці майстер. І в підсумку видалив локальний майстер. Я вже трохи звик коли у мене локально дев гілка і від неї я роблю гілки фичи а видалено майстер і дев. В видалення майстер я зливаю локальний майстер для збереження. - Aleksey Timoshchenko 4 Жовтня '16 о 18:09

Я просто не впевнений, що ця концепція правильна

Вона одночасно може бути правильною, і не придатною конкретно вашого проекту.

я не впевнений, що можна робити Мержа на віддалених гілках.

Не можна. Ви синхронізуєте локальні гілки з віддаленими (fetch / pull), Мержа, і синхронізуєте віддалені з локальними (push). Насправді навіть гілка origin / master теж є локальною.

Порадьте як правильно зробити?

IT - така цікава область, в якій безліч правильних відповідей.

Зокрема, для проекту з одним розробником можна обійтися однією гілкою master і позначати релізи тегами.

git flow і інші методики працюють добре, тільки якщо ви розумієте які саме проблеми вони вирішують. Поки ваш проект таких проблем не містить, методики самі лише ускладнюють життя.

1 створити rc гілку
2 смержіть з вашої dev
3 вилити rc гілку

Так робиться для того, що в разі креша можна було спокійно переключитися на попередню стабільну гілку, пофиксить нову rc гілку і знову зарелізіть. Видаляти гілки вкрай не рекомендую. На практиці часто доводиться діставати зміни в інших гілках. Але якщо у вас гілок перевалило за N і ви в них вже плутаєтеся, тоді можна почистити і тільки локально (git branch -d <ветка>)

відповідь дан 8 Жовтня '16 о 13:11

1) вилити означає зробити git pull на проде. 2) Так, уявіть ситуацію ви розробляли модуль1 в гілці r1 зробили

50 коммітов. А модуль2 в r2 теж N коммітов. Смержілі. Видалили r1 (повністю на сервері і локально git push origin: the_remote_branch). І раптом гілка зламалася або модуль2 не потрібен. Коротше потрібно відновити тільки rc1. І починається пошук коммітов по хешу, а коммітов незрозуміло скільки. Але це не межа, уявіть ситуацію коли ви помержілісь потім зробили доопрацювання в rc1 потім в rc2 знову помержілісь. У цій ситуації гілку шукати дуже складно. - Konstantin Okhotnick 8 Жовтня '16 о 14:37

У тому випадку, що Ви описали Ви можете вступити 2 способами:

Піти шляхом git flow, створивши release гілку і тут же її завершивши.
Зробити злиття develop з master самостійно і [опціонально] поставивши tag на master.

Обидва способи дадуть однаковий результат, але використовуючи другий, потрібно виконати менше роботи. Тому, на мій погляд, варто скористатися саме їм.

Ось тут добре вписуються release гілки. Наприклад, Ваша команда зробила певні набір функціоналу, який потрібно до випуску, скажімо, версії 1.0. Все це знаходиться в гілці develop і у Вас немає ніякої впевненості, що код правильний (він не відтестували як слід, і головний менеджер ще теж не вивчав функціонал). Ви могли б викласти результат з develop, але що робити з простоюють розробниками, які не можуть вливати новий функціонал в develop, тому що є чітко окреслене коло функціоналу випуску?

Щоб розробники не простоювали - випускаємо release гілку, в якій вже не можна додавати ніякого нового функціоналу, але повинні бути виправлені будь знайдені помилки і неточності. Коли всі знайдені помилки виправлені, і зауваження враховані - release гілка закривається, зливається з master і продукт випускається.

Як Ви можете бачити, для Вас, як для одинака, release гілка не потрібна. Тому, просто обходьте цей крок стороною, якщо не хочете виконувати додаткової роботи і пам'ятайте, що будь-яка методологія це набір загальних принципів і правил, і майже завжди методології потрібно адаптувати до потреб конкретного випадку - якщо Ви не розумієте, як щось використовувати, то майже напевно Вам це не потрібно.

відповідь даний 12 Жовтня '16 в 5:41

Перевірте, у вас повинна бути локальна гілка master. І робити злиття треба, звичайно, локально, а потім вивантажувати їх в центральний репозиторій.

Що стосується необхідності створювати гілку релізу, то тут, напевно, все залежить від того, як ви розробляєте проект, і як організований процес. У XXI столітті, де є Scrum, Continuous Integration і DevOps, розгортання проекту може відбуватися по одній кнопці, і допрацьовувати його напилком при кожному релізі в окремій гілці не потрібно.

Інша справа, постійна гілка release. Вона може бути корисна для реалізації того самого розгортання по одній кнопці. Є кілька різних способів реалізації такої поведінки, і один з них - повісити хук на push в гілку release. за яким новий код і буде розгорнуто на сервері промислової експлуатації (він же production).

Тоді ви просто пишіть і тестируете код в одній гілці, назвемо її dev. і коли вважаєте, що код працює коректно, переливає зміни в release. а ваш build-сервер збирає інсталяційний пакет або розгортає код на веб-сервері.

При цьому теги, звичайно, ви ставите, і ставите там, де вам зручно. Гілка dev цілком підійде.

відповідь дан 11 Жовтня '16 о 4:45

Але навіщо мені створювати гілку релізу якщо у мене в гілці Девелоп вже все готово.

Вся принадність гілок не тільки в тому, що ви отримуєте свою копію проекту, а й в тому, що ваші коммітов будуть логічно об'єднані:

Тобто ви будете потім бачити, що ці 5 коммітов були зроблені в рамках реалізації тієї фичи

Не слухайте нікого, що тому ви девелопер одинак, то вам можна не слідувати всім цим правилам gitflow. Вчіться працювати правильно з самого початку!

Використовуючи модель git-flow і працюючи з чистим git. да, ви будете виконувати зайві команди, що буде сповільнювати вас. Але це не проблема цієї моделі, а ваша проблема, тому що ви не використовуєте потрібні утиліти ;-) Наприклад я використовую gitflow-avh. отконфигурировать .gitconf

і додав аліаси в .bashrc

Не знаю як у вас, але на самому початку, коли я познайомився з git. у мене виникала плутанина з розумінням того що є гілки master. production. develop. Тому я для себе вирішив так. ІМХО:

Гілка, яку котимо на бойові сервера - production
Гілка, в якій ведеться розробка (то куди ви Мержа ваші фичи) - develop

Але у мене локально є тільки гілка Девелоп і видалено є Девелоп і майстер.

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

Ви робите Мержа вашого локального Девелоп в локальний майстер
Ви робите push вашого локального майстра в віддалений

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

Є єдина стабільна гілка master.

Її не можна назвати стабільною, поки ви не проведете тестування. Під час тестування ви можете виявити баг, для фікса якого ви зробите додатковий Комміт в master. Відповідно на Попереднє Ком ваша гілка є не стабільною.

З цієї причини придумали гілку release. В якій можна робити хоч скільки завгодно ітерацій тестування по завершенню яких ви випускаєте свій реліз і робите Мержа гілки в master / production і develop.

Нехай що там не говорять, але в будь-якому випадком ви повинні мати такі гілки:

production гілка - це гілка в якій гарантовано будь Комміт готовий до Деплой.
develop гілка - це гілка в яку ви зливаєте ваші фичи
hotfix гілка - ця гілка (щоб не робити cherry-pick з прод в дев) в якій ви робите фікси
release гілка - для спокійного створення релізів