Git Cherry-pick vs Merge Workflow

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

1. Я cherry-pickкожен здійснюю віддалено (по порядку). У цьому випадку git записує комісію як не пов'язану з віддаленою гілкою.
2. Я mergeфілію, втягуючи всі зміни і додаючи новий «конфлікт», виконуючи (якщо потрібно).
3. Я mergeкожний здійснюю з віддаленої гілки окремо (знову в порядку), дозволяючи записати конфлікти для кожного комітету, а не згрупувати всі разом як одне ціле.
4. Для повноти ви можете зробити так rebaseсамо (як cherry-pickваріант?), Однак я розумію, що це може спричинити плутанину у учасника. Можливо, це виключає варіант 1.

В обох випадках 2 і 3 git записує філіальну історію комітетів, на відміну від 1.

Які плюси та мінуси між використанням cherry-pickабо mergeописаних методів? Я розумію, що метод 2 є нормою, але я вважаю, що вирішення великого комітету за допомогою єдиного "конфліктного" злиття не є найчистішим рішенням.

І те, rebaseі те, cherry-pickі mergeмають свої переваги та недоліки. Я заперечую mergeтут, але варто розуміти і те, і інше. (Подивіться тут на альтернативну, добре аргументовану відповідь, що перераховує випадки, де rebaseбажано.)

mergeкраще cherry-pickі rebaseз кількох причин.

1. Міцність . Ідентифікатор SHA1 комітету ідентифікує його не тільки сам по собі, але і стосовно всіх інших комітетів, які йому передують. Це дає вам гарантію того, що стан сховища в заданому SHA1 однаковий для всіх клонів. Теоретично немає жодного шансу, щоб хтось зробив те, що схоже на ту саму зміну, але насправді псує або викрадає ваше сховище. Ви можете вибирати вишні в окремих змінах, і вони, ймовірно, однакові, але у вас немає гарантій. (Що стосується другорядного другого питання, то нові вишневі комітети займуть додаткове місце, якщо хтось ще вибирає вишню в тому ж самому фіксації, оскільки вони будуть присутні в історії, навіть якщо ваші робочі копії виявляться однаковими.)
2. Простота використання . Люди схильні розуміти mergeробочий процес досить легко. rebase, як правило, вважається більш розвиненим. Краще розуміти і те, і інше, але людям, які не хочуть бути експертами в контролі версій (що, на мій досвід, було багато колег, які чортово добре займаються тим, що роблять, але не хочуть витрачати зайвий час) легше час просто зливається.

Навіть із робочим процесом, який є важким для злиття, rebaseі cherry-pickвсе ще корисний для конкретних випадків:

1. Одним із недоліків mergeє захаращена історія. rebaseне дозволяє розповсюджувати довгу серію комітетів у вашій історії, як це було б, якби ви періодично зливалися в інших змінах. Це насправді його головне призначення, яким я користуюсь. Що ви хочете бути дуже обережними, це ніколи не rebaseкодувати, якими ви поділилися з іншими сховищами. Після pushредагування комітету хтось інший, можливо, здійснив поверх нього, а повторне звільнення в кращому випадку спричинить тип дублювання, про який говорилося вище. У гіршому випадку, ви можете зіткнутися з дуже заплутаним сховищем та тонкими помилками, для того, щоб провести викид, вам знадобиться багато часу.
2. cherry-pick корисно для вибору невеликого набору змін із гілки теми, які ви в основному вирішили відмовитись, але зрозуміли, що є кілька корисних фрагментів.

Що стосується переваги об’єднання багатьох змін у одну: це просто набагато простіше. Ви можете зробити дуже нудним робити злиття окремих наборів змін, як тільки ви почнете мати їх багато. Дозвіл злиття в git (і в Mercurial, і в Bazaar) дуже хороший. Ви не зіткнетесь із великими проблемами, з’єднуючи навіть довгі гілки більшу частину часу. Я, як правило, зливаю все все одночасно, і лише якщо у мене виникає велика кількість конфліктів, я створю резервну копію та повторюю частину злиття. Вже тоді я роблю це великими шматками. Як справжній приклад, у мене був колега, який змінив три місяці, і він отримав 9000 конфліктів у 250000 лінійній кодовій базі. Що ми зробили, щоб виправити, - це зробити об'єднання вартістю одного місяця за один раз: конфлікти не виникають лінійно, і це робиться по шматочках призводить далекоменше 9000 конфліктів. Роботи було ще багато, але не стільки, скільки намагатися зробити це один раз за один раз.

На мою думку, збирання вишні повинно бути зарезервоване для рідкісних ситуацій, коли це потрібно, наприклад, якщо ви зробили якусь поправку безпосередньо на "головній" гілці (стовбур, головна гілка розвитку), а потім зрозуміли, що її слід застосовувати також до "Maint" '. Ви повинні базувати робочий процес або на злитті, або на ребазі (або "git pull --rebase").

Будь ласка, пам’ятайте, що вибрана або викладена на вишню комірка відрізняється з точки зору Git (має інший ідентифікатор SHA-1), ніж оригінал, тому вона відрізняється від фіксації у віддаленому сховищі. (Rebase зазвичай може вирішувати це, оскільки він перевіряє ідентифікатор патча, тобто зміни, а не ідентифікатор комісії).

Також в git можна з’єднати відразу багато гілок: так зване злиття восьминога . Зауважте, що злиття восьминога має успіх без конфліктів. Проте це може бути корисним.

HTH.

Rebase та Cherry-pick - це єдиний спосіб зберегти чисту історію фіксації. Уникайте використання злиття і уникайте створення конфлікту злиття. Якщо ви використовуєте герріт, встановіть один проект на Злиття, якщо необхідно, а один проект у вишневому режимі та спробуйте самостійно.