українська мова ▾ Topics ▾ Latest version ▾ git-cherry-pick last updated in 2.50.0

НАЗВА

git-cherry-pick - Застосувати зміни, внесені деякими існуючими комітами

СИНОПСИС

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

ОПИС

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

Коли незрозуміло, як застосувати зміну, відбувається таке:

  1. Поточна гілка та вказівник HEAD залишаються на останньому успішно зробленому коміті.

  2. Посилання CHERRY_PICK_HEAD встановлено так, щоб воно вказувало на коміт, який вніс зміну.

  3. Шляхи, в яких зміни застосовано чисто, оновлюються як у файлі індексу, так і у вашому робочому дереві.

  4. Для конфліктуючих шляхів індексний файл записує до трьох версій, як описано в розділі "TRUE MERGE" сторінки git-merge[1]. Робочі файли дерева міститимуть опис конфлікту, обведений у дужки звичайними маркерами конфлікту <<<<<<< та >>>>>>.

  5. Жодних інших модифікацій не вноситься.

Дивіться git-merge[1] для отримання деяких підказок щодо вирішення таких конфліктів.

ОПЦІЇ

<commit>…​

Коміти для вибору вишневого списку. Повніший список способів написання комітів див. у gitrevisions[7]. Набори комітів можна передавати, але обхід за замовчуванням не виконується, ніби було вказано опцію --no-walk, див. git-rev-list[1]. Зверніть увагу, що вказівка діапазону передасть усі аргументи <commit>…​ до одного обходу ревізій (див. наступний приклад, який використовує maint master..next).

-e
--edit

З цією опцією, git cherry-pick дозволить вам редагувати повідомлення коміту перед його створенням.

--cleanup=<mode>

Цей параметр визначає, як повідомлення коміту буде очищено перед передачею на механізм комітів. Див. git-commit[1] для отримання додаткової інформації. Зокрема, якщо для <mode> надано значення scissors, scissors буде додано до MERGE_MSG перед передачею у разі конфлікту.

-x

Під час запису коміту додайте рядок "(найкраще вибрано з коміту …​)" до оригінального повідомлення коміту, щоб вказати, з якого коміту було вибрано цю зміну. Це робиться лише для вибраних змін без конфліктів. Не використовуйте цю опцію, якщо ви вибираєте зміни зі своєї приватної гілки, оскільки ця інформація буде марною для одержувача. З іншого боку, якщо ви вибираєте зміни між двома публічно видимими гілками (наприклад, портуєте виправлення до гілки підтримки для старішого релізу з гілки розробки), додавання цієї інформації може бути корисним.

-r

Раніше команда за замовчуванням виконувала -x, як описано вище, а -r вимикала його. Тепер за замовчуванням -x не виконується, тому цей параметр не можна використовувати.

-m <parent-number>
--mainline <батьківський номер>

Зазвичай ви не можете вибрати злиття за допомогою cherry-pick, оскільки не знаєте, яку сторону злиття слід вважати основною лінією. Ця опція вказує номер батьківського елемента (починаючи з 1) основної лінії та дозволяє cherry-pick відтворити зміну відносно зазначеного батьківського елемента.

-n
--no-commit

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

Це корисно, коли вибираєте ефект кількох комітів для вашого індексу поспіль.

-s
--signoff

Додайте трейлер Signed-off-by в кінці повідомлення коміту. Дивіться опцію підписання в git-commit[1] для отримання додаткової інформації.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

Коміти GPG-sign. Аргумент keyid є необов’язковим і за замовчуванням використовує ідентифікатор комітера; якщо його вказано, він має бути прив’язаний до опції без пробілу. --no-gpg-sign корисний для скасування як змінної конфігурації commit.gpgSign, так і попередньої змінної --gpg-sign.

--ff

Якщо поточний HEAD збігається з батьківським комітом обраного методом cherry-pick, то буде виконано перемотування вперед до цього коміту.

--allow-empty

За замовчуванням, вибір порожнього коміту за допомогою cherry-pick завершиться невдачею, що вказує на необхідність явного виклику git commit --allow-empty. Ця опція замінює цю поведінку, дозволяючи автоматично зберігати порожні коміти у cherry-pick. Зверніть увагу, що коли діє "--ff", порожні коміти, які відповідають вимозі "fastforward", будуть збережені навіть без цієї опції. Також зауважте, що використання цієї опції зберігає лише ті коміти, які були спочатку порожніми (тобто коміт записав те саме дерево, що й його батьківський коміт). Коміти, які стали порожніми через попередній коміт, призведуть до невдалого вибору cherry-pick. Щоб примусово включити ці коміти, використовуйте --empty=keep.

--allow-empty-message

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

--empty=(drop|keep|stop)

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

drop

Коміт буде видалено.

keep

Коміт буде збережено. Має на увазі --allow-empty.

stop

Вибір коміту зупиниться після його застосування, що дозволить вам переглянути його. Це поведінка за замовчуванням.

Зверніть увагу, що --empty=drop та --empty=stop вказують лише на те, як обробляти коміт, який спочатку не був порожнім, а став порожнім через попередній коміт. Коміти, які спочатку були порожніми, все одно призведуть до невдалого вибору коміту, якщо не вказано один з параметрів --empty=keep або --allow-empty.

--keep-redundant-commits

Застарілий синонім для --empty=keep.

--strategy=<strategy>

Використовуйте задану стратегію злиття. Слід використовувати лише один раз. Див. розділ СТРАТЕГІЇ ЗЛИТТЯ в git-merge[1] для отримання детальної інформації.

-X<option>
--strategy-option=<option>

Передайте специфічний для стратегії злиття параметр до стратегії злиття. Див. git-merge[1] для отримання детальної інформації.

--rerere-autoupdate
--no-rerere-autoupdate

Після того, як механізм rerere повторно використає записане вирішення поточного конфлікту для оновлення файлів у робочому дереві, дозвольте йому також оновити індекс результатом вирішення. --no-rerere-autoupdate — це гарний спосіб перевірити, що зробив rerere, та виявити потенційні помилки злиття, перш ніж занести результат до індексу за допомогою окремого git add.

ПІДКОМАНДИ СЕКВЕНСЕРА

--continue

Продовжуйте поточну операцію, використовуючи інформацію з .git/sequencer. Можна використовувати для продовження після вирішення конфліктів у невдалому виборі вишневого коду або поверненні.

--skip

Пропустити поточний коміт та продовжити решту послідовності.

--quit

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

--abort

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

ПРИКЛАДИ

git cherry-pick master

Застосуйте зміни, внесені комітом на кінчику гілки master, та створіть новий коміт з цією зміною.

git cherry-pick ..master
git cherry-pick ^HEAD master

Застосувати зміни, внесені всіма комітами, що є предками master, але не HEAD, для створення нових комітів.

git cherry-pick maint next ^master
git cherry-pick maint master..next

Застосувати зміни, внесені всіма комітами, що є предками maint або next, але не master або будь-якого з його предків. Зверніть увагу, що останнє не означає maint та все, що знаходиться між master та next; зокрема, maint не використовуватиметься, якщо він включений до master.

git cherry-pick master~4 master~2

Застосуйте зміни, внесені п’ятим та третім останнім комітами, на які вказує master, та створіть 2 нових коміти з цими змінами.

git cherry-pick -n master~1 next

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

git cherry-pick --ff ..next

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

git rev-list --reverse master -- README | git cherry-pick -n --stdin

Застосуйте зміни, внесені всіма коммітами на гілці master, що стосувалися README, до робочого дерева та індексу, щоб результат можна було перевірити та, за потреби, перетворити на один новий коміт.

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

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)

  1. застосуйте зміни, які будуть показані командою git show topic^. У цьому прикладі патч застосовується не повністю, тому інформація про конфлікт записується в індекс та робоче дерево, і нові зміни не створюються.

  2. підсумувати зміни, що підлягають узгодженню

  3. скасувати вибірку. Іншими словами, повернутися до стану до вибору, зберігаючи будь-які локальні зміни, які ви мали в робочому дереві.

  4. спробуйте застосувати зміну, внесену topic^, ще раз, витративши додатковий час, щоб уникнути помилок, пов’язаних з неправильно зіставленими рядками контексту.

ДИВ. ТАКОЖ

git-revert[1]

GIT

Частина набору git[1]