Выбор стратегии потока кода
Важно выбрать стратегию потока кода, которая соответствует тому, как работает ваша команда. У вас есть несколько стратегий для рассмотрения. В конце модуля вы сможете изучить варианты. Веб-команда Tailspin решает разработать стратегию потока кода, основанную на Git и GitHub.
Когда Мара настроила Azure Boards, она и команда определили несколько начальных задач для решения. Одна из задач заключалась в создании рабочего процесса на основе Git.
Давайте слушайте в команде, так как они работают лучше, чтобы сотрудничать. В настоящее время они используют централизованную систему управления версиями, но план заключается в переходе на Git, распределенную систему.
Мара старательно работает над ее назначенными функциями, когда Энди идет в.
Энди: Привет Мара. На заседании руководства сегодня утром мы подняли, что наша команда и команда разработчиков игр используют различные системы управления версиями. Чтобы упростить совместное использование ресурсов между командами, мы попросили перейти к распределенной системе управления версиями, которая может лучше справиться с совместной работой.
Мара: Это хорошо знать. Если вы помните, мы положили его на нашу доску. В настоящее время мы используем централизованную систему управления версиями. Сейчас это отлично подходит для нас, но я согласен с тем, что распределенная система управления версиями лучше подходит, когда мы начинаем делиться между командами и нашей командой становится больше. В наши задачи также входит повышение прозрачности, чтобы все заинтересованные стороны знали, что все делают. Я думаю, что распределенная система управления версиями, как Git, также поможет.
Энди: Я хотела попробовать Git в течение некоторого времени. Кажется, у меня никогда нет времени. Трудно ли научиться или настроить? Если это кажется разумным, может быть, мы могли бы работать над ним сейчас. Я устал от всегда откладывать вещи. И было бы приятно увидеть, что делает каждый, и иметь доступ ко всему репозиторию. Хорошо, что это все о?
Мара: Позвольте мне объяснить это, а затем вы можете решить, звучит ли это как то, что мы хотим реализовать сразу.
Мара и Энди переходят на доску для обсуждения по управлению версиями.
Что такое Git и распределенное управление версиями?
Мара: рисунок слева является централизованным элементом управления версиями, как то, что мы используем сейчас. У нас есть центральная версия базы кода 
в системе управления версиями Team Foundation (TFVC), которую используют все. Мы работаем с файлами, которые необходимо изменить, а по завершении работы снова объединяем их в главном репозитории.
Энди. Да, и это удобно для нас. Ну, не считая того случая с блокировкой, когда критическое изменение было добавлено в центральный репозиторий.
Мара: Да! Вы были заблокированы 
. Мы могли бы применить стратегию ветвления с использованием TFVC, чтобы решить блокирующую проблему, но в нашей текущей конфигурации слияние может несколько усложниться. И когда у нас было это критическое изменение 
, никто не может получить никаких действий, пока мы не получили это решение. Эта проблема всегда скрывается, так как мы все используем одну копию кода.
Справа — это рисунок распределенного управления версиями. У нас по-прежнему есть центральный репозиторий 
, который является стабильной версией базы кода, но каждый разработчик имеет собственную копию 
, из которой следует работать. Это позволяет нам экспериментировать и использовать разнообразные подходы, в которых центральный репозиторий не затрагивается.
Распределенное управление версиями гарантирует, что только рабочий код 
добавляется в центральный репозиторий. Мы даже могли бы сделать так, что код нельзя объединять, пока он не будет проверен.
Что касается Azure DevOps, это хорошо работает как с централизованными системами управления версиями, так и с распределенными системами управления версиями.
Энди: Что происходит, когда несколько человек изменяет один и тот же файл?
Мара: Часто Git может автоматически объединять несколько изменений. Конечно, необходимо всегда следить, чтобы комбинация изменений приводила к работающему коду. Если Git не может автоматически объединить изменения, он помечает конфликты непосредственно в файлах, чтобы человек смог выбрать, какие изменения следует принять.
Энди. Сейчас наш код хранится на нашем сервере. Если перейти к использованию распределенного управления версиями, где будет храниться код?
Мара: Я рад, что ты спросил. Вот где размещение приходит.
Где можно разместить репозиторий?
Мара: Когда мы решаем, где разместить наши репозитории, у нас есть несколько вариантов. Например, можно разместить их на локальном сервере, в Bitbucket или в GitHub. Bitbucket и GitHub — это веб-решения для размещения. Мы можем получить доступ к ним из любого места.
Энди: Вы использовали один из них?
Мара: Я использовал GitHub в прошлом. Он имеет функции, важные для разработчиков, например простой доступ к журналам изменений и функциям управления версиями из командной строки или веб-портала.
Энди: Так как работает Git?
Разделы справки работать с Git?
Мара: Как я упоминание раньше, с распределенными системами разработчики могут получить доступ к любому файлу, который им нужен, не влияя на работу других разработчиков, так как у них есть собственная копия репозитория. Клон — это локальная копия репозитория.
Когда мы работаем над функцией или исправлением ошибок, мы обычно хотим попробовать различные подходы, пока не найдем лучшее решение. Тем не менее, попробуйте использовать код в копии основной базы кода не рекомендуется, так как вам может не потребоваться сохранить первые несколько попыток.
Чтобы предоставить вам лучший вариант, Git имеет функцию, называемую ветвлением, где можно поддерживать столько копий, сколько вы хотите, и объединить только тот, который вы хотите сохранить. Это обеспечивает стабильную основную ветвь.
Энди: Я получаю понятия до сих пор. Разделы справки проверка в коде?
Как мои локальные изменения попадают в основную базу кода?
Мара: В Git ветвь по умолчанию или ствол обычно называется main.
Если вы считаете, что код готов к слиянию в ветви main в центральном репозитории, который используется совместно всеми разработчиками, создайте запрос на вытягивание. При создании запроса на вытягивание следует указать другим разработчикам, что код готов к проверке и будет слит в ветви main. После утверждения запроса на вытягивание и слияния код становится частью центральной базы кода.
Как выглядит рабочий процесс ветвления?
Шаг 1. В начале работы над новой функцией или исправлением ошибки первое, что нужно сделать, — убедиться, что используется последняя стабильная база кода. Для этого можно синхронизировать локальную копию main ветви с копией сервера. При этом вытягивается локальная копия всех других изменений разработчика, которые были отправлены main в ветвь на сервере с момента последней синхронизации.
Шаг 2. Чтобы убедиться, что вы работаете только со своей копией кода, создайте новую ветвь только для этой функции или исправления ошибки. Ожидаемо,что запомнить все ветви для всех вещей, которые вы делаете, может быть непросто, поэтому применение продуманного соглашения об именовании является очень важным.
Прежде чем вносить изменения в файл, можно извлечь новую ветвь, чтобы убедиться, что вы работаете с файлами из этой ветви, а не из какой-то другой. Вы можете переключать ветви в любое время, проверка выключив эту ветвь.
Шаг 3. Теперь вы безопасно внесите все необходимые изменения, так как эти изменения находятся только в вашей ветви. Во время работы вы можете фиксировать изменения в ветви, чтобы не потерять свою работу и иметь возможность откатить изменения, внесенные в предыдущих версиях. Прежде чем зафиксировать изменения, необходимо выполнить этап файлов, чтобы Git знал, какие из них можно зафиксировать.
Шаг 4. Следующий шаг — отправить или отправить локальную ветвь до удаленный репозиторий (например, GitHub), чтобы другие могли видеть то, что вы работаете. Не беспокойтесь, это еще не будет объединять изменения. Вы можете подтолкнуть вашу работу так же часто, как вы хотите. На самом деле, это хороший способ резервного копирования работы или разрешить себе работать с нескольких компьютеров.
Шаг 5. Этот шаг является общим, но не обязательным. Если вы удовлетворены работой кода, можно извлечь или объединить удаленную ветвь main с локальной ветвью main. Изменения произошли там, что у вашей локальной main ветви еще нет. После синхронизации удаленной ветви main со своей объедините локальную ветвь main с рабочей ветвью и снова протестируйте сборку.
Этот процесс помогает убедиться, что функция работает с последним кодом. Это также помогает обеспечить плавность интеграции вашей работы при отправке запроса на вытягивание.
Шаг 6. Теперь локальный код должен быть зафиксирован и отправлен в размещенный репозиторий. Это то же самое, что и шаги 3 и 4.
Шаг 7: вы готовы предложить свои изменения удаленной ветви main. Для этого начинается запрос на вытягивание. Когда этот шаг настроен в Azure Pipelines или другой системе CI/CD, он активирует процесс сборки, и вы можете отслеживать изменения, перемещаясь по конвейеру. После успешной сборки и других утверждающих запрос на вытягивание код можно объединить в удаленную main ветвь. (Это все еще до человека, чтобы объединить изменения.)
Энди: Все это выглядит сложным и трудно учиться.
Мара: Git может показаться пугающим, потому что это так мощно, но после того, как вы получите висят поток, он начинает чувствовать себя естественным.
Вы будете использовать только несколько команд ежедневно. Ниже приведена сводная информация о вариантах.
| Категория | Выполнения задачи | Используйте эту команду |
|---|---|---|
| Управление репозиторием | Создание репозитория Git | git init |
| Скачивание удаленный репозиторий | git clone |
|
| Ветвь | Создание ветви | git checkout |
| Изменения этапа и фиксации | Просмотр измененных файлов | git status |
| Этапы для фиксации файлов | git add |
|
| Фиксация файлов в ветви | git commit |
|
| Удаленная синхронизация | Скачивание ветви из удаленный репозиторий | git pull |
| Отправка ветви в удаленный репозиторий | git push |
Энди: Это звучит как отличная отправная точка. Я определенно могу справиться с этим. Я могу узнать более сложные команды, так как им нужны.