Как поднять полномочия только при необходимости?

Итак, после некоторых экспериментов, проб и ошибок, я думаю, я понял это:

И arc graft, и arc patch используют git cherry-pick под капотом и выполняют аналогичные вещи. Тем не менее, они имеют некоторые тонкие различия, и иногда arc patch терпит неудачу, и вы должны вместо этого использовать arc graft с флагом --skip-landed (update: или, возможно, 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.

ИЛИ

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                              
└──new_feature_1
   └──new_feature_2 

Коротко: что такое дерево зависимостей arc flow? Ответ: это древовидная структура, показанная с помощью команды arc flow, которая показывает, какие ветви зависят от чего. Это несколько произвольная вещь, которую вы, как человек, отслеживаете вручную, поскольку знаете, что одна функция зависит от другой. Чтобы установить «зависимость», у вас есть две опции:

1. Вызвать arc flow new_branch_name, чтобы создать новую дочернюю ветвь, в то время как вы в настоящее время извлекли ветку, которую хотите стать родителем, ИЛИ: [ 1141]

2. Используйте 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 на ваш локальный мастер.

Предполагая, что их diff равен "D999", и в настоящее время у вас есть извлеченная ветка "master", ваши команды и результирующие деревья зависимостей будут выглядеть следующим образом:

1. [тысяча сто двадцать семь]. Теперь у вас есть это дерево, где ваш недавно созданный "arcpatch-D999" является их веткой "new_feature_2":

   master
   └──arcpatch-D999 
   

2. 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» будут точно одинаковыми ветвями, но это нормально.