Зберігання чистої історії git при використанні gitflow - неперевірених зобов’язань на розробці

Використовуючи gitflow, створюючи release-1.0.0гілку та об’єднуючи її в обидві, masterі developобидві гілки матимуть відсутність комітету:

masterне будемо робити комітети, куди release-1.0.0було злитоdevelop
developне будемо робити комітети, куди release-1.0.0було злитоmaster

Натомість після того, як hotfix-1.0.1створено та об'єднано master, коли воно об'єднане develop, зобов’язання до об'єднання включатимуть попереднє зобов’язання, у яке release-1.0.0було об'єднано master; тому це буде виглядати приблизно так:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Якщо це звучить дивно, ви можете легко помітити це everytie ви бачите develop, як правило , кілька фіксацій позаду master(хоча і розвиватися, теоретично, повинен тільки бути попереду , так як це основна галузь. Ці фіксацій є зливається з release-x.x.xдо master).

Як це слід вирішувати для підтримки чистої історії?

git gitflow

— Крістофер Франсиско
джерело

Будь ласка, визначте "чисту історію".

— Джейс Браунінг

Хочете чистої історії? Не використовуйте gitflow. Це за визначенням забруднює вашу історію. Натомість подумайте, що вам справді потрібно, і побудуйте навколо цього робочий процес, щоб він насправді відповідав тому, як ви хочете працювати.

— FP

Злиття в головне буде "копією", не потрібно об'єднувати її для розвитку. Зробіть гарячі виправлення з попередньої гілки випуску, а не майстер, і з’єднайтеся з обома звідти, і у вас не виникне проблеми. Майстер не додає великої кількості моделі, так що ви можете фактично її повністю відкинути, IMO.

— axl

@axl Я розумію, що ви маєте на увазі, але я намагаюся дотримуватися gitflow якомога ближче до його документації. Я б краще не робив жодного "хакза", оскільки оскільки gitflow вже прийнято багатьма багатьма розробниками, вони повинні вже мати рішення для цієї простої речі

— Крістофер Франсиско

Існує кілька дискусій про те, як вирішити різні проблеми з GitFlow на GitHub та інших місцях. Іноді просто немає срібної кулі.

— axl

Я думаю, що хороший підхід полягає у тому, щоб уникнути наявності двох "головних" галузей, освоювати та розвиватись є надлишковими. Це пояснюється ретельно тут , затаврували cactus-flowавтором.

Деякі моменти виділяються на відміну від git-flow:

Лише одна головна галузь
Зливаються лише швидкі вперед

Для мене останній важливий, оскільки після тривалого використання git-flow я ще не бачу, що корисне для --no-ffзлиття.

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

ІМХО, це ваша велика помилка. У вас немає жодної причини, щоб ви дотримувались git-flow якомога більше. Він може використовуватися в тисячах проектів, але це не впливає на ваш, не приносить користі.

Git-flow - це хороша відправна точка, але слід подумати про те, щоб адаптувати його до своїх інструментів та робочого процесу, а не навпаки.

— Серхіо Басурко
джерело