Итак, после некоторых экспериментов, проб и ошибок, я понял, что понял:
И arc graft, и arc patch используют git cherry-pick под капотом и выполняют аналогичные вещи. Тем не менее, они имеют некоторые тонкие различия, и иногда arc patch дает сбой, и вы должны вместо этого использовать arc graft с флагом --skip-landed (обновление: или, возможно, arc patch с флагом --skip-dependencies тоже будет работать?).
Примеры:
arc patch --skip-dependencies D999 # cherry-pick their "D999" "diff" (branch) onto your current branch, while creating a new single branch for you named "arcpatch-D999", skipping dependencies in case they've already landed on the branch (ex: master) you currently have checked out.
OR
arc graft --skip-landed D999 # cherry-pick their "D999" "diff" (branch), *as well as all parent branch(es) it depends on*, onto your current branch, while creating the entire dependency tree of branches for you, exactly as the submitter originally had on their local machine, skipping any commits that have already landed on your local branch (ex: master) you currently have checked out
Представьте, что ваше arc flow дерево зависимостей содержит только ветку "master":
master
Однако у коллеги есть следующее arc flow дерево зависимостей:
master
└──new_feature_1
└──new_feature_2
Коротко: что такое arc flow дерево зависимостей? Ответ: это древовидная структура, отображаемая с помощью команды arc flow, которая показывает, какие ветви зависят от чего. Это несколько произвольная вещь, которую вы, как человек, отслеживаете вручную, поскольку знаете, что одна функция зависит от другой. Чтобы установить «зависимость», у вас есть два варианта:
- Позвоните по номеру
arc flow new_branch_name, чтобы создать новую дочернюю ветку, пока вы извлекаете ветку, которую хотите стать родительской, ИЛИ:
Используйте git, чтобы создать новую ветвь, а затем установите в восходящем потоке то, что вы хотите стать родительским. Пример:
git branch new_branch_name
git checkout new_branch_name # Or use `git checkout -b new_branch_name` to do both at once
git branch --set-upstream-to=upstream_branch_name # or `git branch -u upstream_branch_name` for short
Теперь arc flow покажет ваше дерево зависимостей. Это позволяет вам переходить к вещам типа arc cascade от родителя к его детям, который просто выполняет автоматические рекурсивные ребитальные преобразования от родителей к детям (т. Е. Перебрасывает детей на родителей).
Конец в стороне.
В любом случае, с помощью дерева зависимостей, показанного выше, ваш коллега извлек "new_feature_2", и он arc diff отправил его вам на проверку. Вы переходите к веб-инструменту «Дифференциал» и начинаете просматривать изменения. Тем не менее, вы хотите проверить это. Это означает, что вам нужно перенести их diff на ваш локальный компьютер. У вас есть два варианта: 1. arc patch их diff (ветвь с зависимостью от дерева зависимостей) на ваш локальный мастер или 2. arc graft их diff на ваш локальный мастер.
Предполагая, что их разница равна "D999", и в настоящее время у вас извлечена ветка "master", ваши команды и результирующие деревья зависимостей будут выглядеть следующим образом:
arc patch D999. Теперь у вас есть это дерево, где ваша вновь созданная "arcpatch-D999" является их веткой "new_feature_2":
master
└──arcpatch-D999
arc graft D999. Теперь у вас есть это дерево, как у них:
master
└──new_feature_1
└──new_feature_2
Однако (я думаю, исходя из моих проблем), что иногда, когда у них есть такое дерево зависимостей нескольких поколений, arc patch завершается с ошибкой (выдавая ошибку «Cherry Pick Failed!»), И в таком случае случай, вы должны использовать arc graft вместо этого! ОДНАКО, если их мастер НЕ точно такой же, как ваш мастер (что почти наверняка НЕ будет, так как они, вероятно, отозвали своего хозяина некоторое время назад, и вы должны были просто вытащить своего, чтобы убедиться, что у вас есть последняя версия), тогда ваши попытки трансплантат или патч потерпит неудачу. Вероятно, сбои будут связаны с тем, что некоторые из коммитов в истории веток содержат изменения, которые уже внесены и присутствуют в вашем мастере. Решение состоит в том, чтобы использовать arc graft D999 --skip-landed, что позволит вам захватить их diff и потянуть их вниз, отражая их дерево зависимостей arc flow. В таком случае arc patch D999, скорее всего, продолжит работать до тех пор, пока не потерпит неудачу они вытягивают последнюю версию мастера и arc cascade (или git rebase дважды), а затем повторно arc diff отправляют свои изменения на сервер, после чего вы можете затем успешно arc patch D999 на своем мастере. Так как вы не всегда можете заставить их перебазировать / arc cascade немедленно, просто сделайте arc graft D999 --skip-landed сейчас и все готово! Позвольте им перебазировать и повторно arc diff, когда они доберутся до него.
Одна небольшая проблема, однако, состоит в том, что, если вы arc graft много, это может сбить с толку, кто сделал какие ветви (вы или кто-то еще?), Поэтому я рекомендую вам привыкнуть прививать новый Филиал вы называете себе, как следует, просто для организации:
git checkout master # same as `arc flow master`
git pull origin master # pull latest master
arc flow graft-D999 # create and checkout a new child branch you are calling "graft-D999" (name it appropriately)
arc graft D999 --skip-landed # graft their entire dependency tree onto your branch "graft-D999"
Ваше дерево зависимостей теперь будет выглядеть следующим образом:
master
└──graft-D999
└──new_feature_1
└──new_feature_2
Отлично! Красиво и организованно. Теперь вы можете проверить "new_feature_2", скомпилировать и протестировать его. Обратите внимание, однако, что "master" и "graft-D999" будут в точности одинаковыми ветвями, но это нормально.