Объединить мои необходимые файлы из ветви DEV в QA в Azure VSTS

Question

Это относится к развертыванию кода Playbook Splunk Phantom.

Всякий раз, когда мы создаем новую пьесу, в репозитории создается два файла для каждой пьесы (. json, .py). У нас есть 3 разные ветви, связанные с одним репозиторием (DEV, QA, PROD).

В нашей ветви DEV работа по разработке будет продолжена, и у нее будет около 300 файлов (JSON и Python, что означает, что 150 playbooks в Phantom dev GUI).

Теперь я не хочу объединять все эти файлы с моим QA, мне просто нужно несколько файлов, которые претерпели изменения в DEV, чтобы pu sh, чтобы QA (потому что из 300 файлов в DEV у нас есть около 160 файлов в QA с одинаковым кодом).

Когда какие-либо изменения произойдут с файлами DEV, я должен выбрать эти указанные c файлы и поднять запрос на удаление, затем слияние (это означает, что только те файлы с изменениями в DEV должны быть перемещены в QA {своего рода Cherry-picking}).

Я следовал нижеприведенному процессу, но у меня возникают конфликты слияния.

Процесс:

1. Создать новую ветку

   git checkout -b branch_name
   

2. Удалить все файлы для этой ветви

   git rm -rf .
   

3. Передать изменения

   git commit -m "create new branch" 
   

4. Получить некоторые файлы из основная ветвь

   git checkout master -- file1 file2 file3 file4    
   

5. Подтверждение изменений

   git commit -m "create new branch" 
   

После этого я перехожу к своему интерфейсу VSTS и применяю cherry- выберите «commit», что я сделал на 4-м, 5-м шагах (я могу успешно создать коммит с моими необходимыми файлами, и во время выполнения cherry-pick у меня возникают проблемы).

Ниже приведен скриншот, когда я пытался сделать «вишню» - сообщение об ошибке выглядит так:

There were conflicts when cherry-picking commit 60625f. This operation needs to be done locally

Answer 1

tl; dr

Если вы обнаружите, что используете cherry-pick или rebase -i каждый раз, когда хотите продвигать изменения с помощью запроса на извлечение, ваша конфигурация процесса и инструментов неверна.

---

Рассмотрите возможность использования ветвей элементов

Элемент (или topi c, если вы читаете книгу git scm), ветви, которые простираются от ствола (master), сфокусированы и одноразовые. Эта модель не только упрощает понимание запросов и выпусков Pull, но и намного проще в управлении, чем поддержание двух или трех ветвей жизни в нужное время и в нужное время c

Be правдиво о том, что должно находиться под контролем версий

Наличие в одной ветке репо файлов, которые никогда не предназначены для переноса в другие ветки, является убедительным свидетельством того, что эти файлы на самом деле не нужны под контролем версий. Хотя эти файлы могут быть необходимы для разработки вашего продукта, они явно не представляют real частей вашего результата. Именно поэтому файл .gitignore существует. Настройте файл .gitignore, чтобы эти файлы могли находиться в рабочем пространстве без отслеживания.

Правильное выполнение файла .gitignore должно устранить необходимость выполнять работу, которая приводит вас к конфликтам слияния в Во-первых, использование функциональных веток одной ветки жизни, а не трех веток жизни сделает все остальное о реализации практик DevOps для вашей команды и кода намного проще для понимания и поддержки.

С учетом сказанного ...

Исправление общей проблемы локального разрешения конфликтов слияния

В этих предложениях предполагается, что ваш PR пытается поместить изменения с branch_name в origin\QA

Azure devops (ранее VSTS) просит вас разрешить конфликты слияния локально, и pu sh эти изменения в вашем PR.

После вашего шага 5. вам нужна локальная копия целевой ветви PR (я предполагаю QA) с пульта (обычно идентифицируемой как origin в вашем локальном репо).

Один раз Вы сделали это, вернитесь к branch_name и запустите git merge localQA. Это должно показать вам, что слияние не может быть завершено в / c конфликтов. Теперь вам нужно открыть файлы, перечисленные в git status, которые не добавлены в индекс, и исправить конфликт. Когда конфликты файлов исправлены, вы можете зафиксировать слияние и pu sh.

Чтобы по-другому подходить к вашей текущей ситуации

Не удаляйте все файлы в branch_name и checkout выборочно от мастера, который, я полагаю, представляет origin/DEV. Вместо этого вырежьте branch_name из современной локальной копии origin\QA. Это позволит вам начать с QA-копии файлов, которые вы хотите. Затем из этой ветви вы можете git checkout master -- fileA etc. до переписать эти изменения в вашу копию QA. Теперь вы можете сделать sh копию QA для origin и создать PR.

Если вы сообразительны, вы, возможно, уже заметили, что этот способ действий точно такой же, как иметь одну ветвь времени жизни (QA), которая использует PR для получения изменений из функциональных ветвей. Это потому, что коммиты из DEV никогда не делают его из DEV.

Когда вы используете git checkout <tree-ish> -- [pathspec], вы не перемещаете commit , вы перемещаете изменения. Например ..

Скажем, у меня есть ветка master, и создайте ветку test для некоторых изменений и добавьте файл.

Теперь, если я создам новую ветвь и использую checkout <tree-ish> -- [pathspec], вы увидите, что она создает новый набор изменения для принятия.

В моем примере того, как вы используете контроль версий, если master представляет ваши origin/QA и test представляет origin/DEV, зачем вообще вообще беспокоиться о ветке test, если я собираюсь создать новые коммиты на newTest, которые представляют изменения, сделанные в test? Я (ты) не должен.

Дополнительная альтернатива

Используйте git rebase -i в своей ветке для РАЗДЕЛИТЬ КОМИТЕТЫ , чтобы файлы, которые вы хотите игнорировать , были в коммите, который вы можете игнорировать. При таком подходе вы все равно должны создать ветку из origin/QA или любой другой цели PR. Затем вы можете использовать cherry-pick для коммитов, которые вы хотите из ветки разработки, и использовать PR между этой веткой и целью.

Поймите: использование Rebase таким образом переписывает историю вашей ветки. Некоторые утверждают, что это неразумно, поэтому убедитесь, что вы знаете, что делаете