Инструменты, которые необходимо знать специалистам по данным

В последнем уроке мы узнали об основах GitHub. В этом руководстве все эти основы соберутся воедино, и мы познакомимся с реальной силой GitHub, которая исходит от совместной работы. Обратите внимание, что в этом уроке мы будем часто использовать такие слова, как клонирование, отправка, вытягивание, ветки, мастер и т. д. Поэтому, если вы не понимаете какой-либо из них, сначала прочитайте последний урок.

Определение сотрудничества

Чтобы оценить решение, важно оценить проблему. Прочитайте следующее, чтобы понять сценарий, в котором GitHub может пригодиться.

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

В вашей команде каждый специалист по данным работает индивидуально над улучшением предсказания модели. Поэтому они создали свои локальные версии или альтернативные ветви «основной» версии.

Предположим, что вы внесли некоторые изменения в «главную» версию своего кода, и член вашей команды придумал его собственная отредактированная версия и утверждает, что он значительно улучшил предсказание модели. Визуальное представление этого сценария выглядит следующим образом:

Теперь вы хотите обновить «основную» версию кода, но может возникнуть ряд конфликтов. Упомянем несколько ниже:

  • Изменения, которые вы внесли в «главную» версию, вероятно, отсутствуют в разветвленной версии члена вашей команды.
  • Разветвленная версия может иметь некоторые обработки переменных, которые отличаются от «главного» кода.

Это означает, что простая перезапись«главного» кода версией кода ответвления может не отвечать интересам проекта. . GitHub пригодится для разрешения конфликтов, подобных этим.

Время решения

Я уверен, что приведенный выше сценарий заставил вас оценить стоящую перед вами проблему. Вопрос в том, чем поможет GitHub?

Перво-наперво

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

  • Соавтор — разработчик, официально добавленный в репозиторий проекта и получивший доступ с принудительной отправкой (доступ для изменения содержимого репозитория). называется соавтором или соавтором
  • Вилка.Вилка в GitHub похожа на копирование чужого репозитория в вашу учетную запись. Как правило, если вы хотите использовать проект с открытым исходным кодом, созданный каким-то другим разработчиком и вы не являетесь участником, вы разветвляете его и получить доступ к своему репозиторию.
  • Ветвь. Как правило, разработчики используют разные ветки для обслуживания разных модулей проекта. Другой распространенный сценарий, требующий использования ветвей, — это когда несколько членов команды хотят работать над одним и тем же фрагментом кода. Это когда у каждого может быть своя ветка. По умолчанию каждый вновь созданный репозиторий имеет центральную ветвь с именем «главная ветвь».
  • Запрос на вытягивание. Создается запрос на вытягивание для слияния ветки с веткой «master». Запрос направляется непосредственно владельцу проекта, и он/она может работать с участником ветки, чтобы принять/отклонить изменения.

Сценарии

Чтобы решить описанную выше проблему, мы рассмотрим 2 сценария, с которыми вы можете столкнуться при активном сотрудничестве на GitHub:

  • В первом сценарии мы предполагаем, что вы хотите внести свой вклад в репозиторий (проект), в котором вы не добавлены в качестве участника. В этом сценарии мы предполагаем, что в ветку «master» не вносились изменения после того, как вы разветвили проект (на приведенной выше схеме примера сценария желтые прямоугольники версий 2 и 3 не существует).
  • Второй сценарий предполагает, что вы являетесь частью проектной группы и добавлены в качестве участника в репозиторий проекта. В этом сценарии мы предполагаем, что в ветку «master» были внесены изменения после того, как вы создали свою собственную ветку (на схеме примера сценария, показанной выше, желтые прямоугольники версий 2 и 3 существуют).

Давайте посмотрим на рабочий процесс вышеприведенных сценариев.

Сценарий 1 — не соавтор

Если вы не участвуете в репозитории, вам не разрешено отправлять изменения из вашей локальной системы на GitHub. Шаги рабочего процесса для совместной работы в подобном сценарии следующие:

  • Разветвление репозитория —поскольку мы не сотрудничаем с репозиторием, мы сначала разветвим репозиторий. Чтобы разветвить репозиторий, войдите в свою учетную запись и найдите интересующий вас репозиторий. Перейдите на страницу репозитория GitHub и нажмите «Кнопка «Разветвить»», как показано ниже. :

На приведенных выше 4 снимках экрана мы ищем репозиторий (D2WAP/Test). Мы перешли на страницу репозитория и нажали кнопку ответвления в правом верхнем углу. Произошел процесс разветвления, и репозиторий разветвился в нашей учетной записи.

  • Клонировать репозиторий.После этого вы можете клонировать разветвленный репозиторий, чтобы сделать его содержимое доступным в вашей системе. Процесс для этого объясняется в последнем уроке. Поскольку разветвленный репозиторий является частью вашей учетной записи, у вас будет доступ для отправки изменений, и вы сможете отправлять свои изменения в разветвленный репозиторий. Обратите внимание, что в этом случае клонирование следует выполнять после разветвления, потому что, если это сделать до разветвления, ваш локально клонированный репозиторий будет указывать на учетную запись другого разработчика, где вы не сможете иметь push-доступ.
  • Изменить код, зафиксировать и отправить. Следующим шагом является редактирование кода в клонированном репозитории, фиксация изменений, и отправьте их в разветвленный репозиторий. Если у вас есть ответвление, вы можете отправить изменения непосредственно в «главную» ветку или можете также создать новую ветку. Мы рекомендуем вносить изменения только в новую ветку, но для простоты этого сценария мы отправляем изменения непосредственно в «главный» ветвь . Мы рассмотрим создание новой ветки в сценарии 2. Чтобы продемонстрировать процесс, я отредактировал файл read me file разветвленный репозиторий. Разницу между разветвленным и исходным репозиторием можно увидеть на скриншоте ниже:

  • Создать новый запрос на слияние.Теперь, когда вы внесли необходимые изменения в коды (в нашем случае read me file), пришло время создать запрос на вытягивание. Нажмите кнопку «Запрос на вытягивание» и перейдите к экрану запроса на вытягивание. В правом верхнем углу экрана нажмите «Новый запрос на вытягивание».

  • Выберите базовый и головной репозиторий. После того, как вы нажмете «Новый запрос на вытягивание», вы попадете на страницу, где сможете выбрать базовый и головной репозиторийвместе с соответствующими ветвями. Думайте о базе как о целевом репозитории, а о голове — как о разветвленном репозитории. Поскольку мы внесли изменения непосредственно в ветку «master» разветвленного репозитория, для головной и базовой веток выберите «master”. Как только выбор будет сделан, GitHub покажет вам сравнение между двумя версиями, которые вы пытаетесь объединить. Снова нажмите «Создать запрос на вытягивание».

  • Добавить комментарии. Нажав кнопку Создать запрос на вытягивание, вы попадете на страницу комментариев, где вы может добавить соответствующие комментарии для разработчика исходного репозитория. Еще раз нажмите «Создать запрос на вытягивание», и ваш запрос на вытягивание будет отправлен разработчику исходного кода. Обратите внимание на сообщение GitHub об отсутствии конфликтов. Это подтверждает наше предположение о том, что после того, как мы разветвили репозиторий, в исходный код не было внесено никаких изменений.

  • Объединение по автору — после того, как вы отправили запрос на вытягивание, автор получает его и, при отсутствии конфликтов, может сразу одобрить его. Чтобы выполнить слияние, автор перейдет на вкладку запроса на вытягивание и нажмет «Объединить запрос на слияние». Вот и все, вы успешно внесли свой вклад в исходный репозиторий.

Сценарий 2 — Вы являетесь участником

Поскольку в этом сценарии мы предполагаем, что вы добавлены в качестве участника владельцем репозитория, у вас будут права доступа для отправки изменений непосредственно в исходный репозиторий. С этим предположением давайте пройдемся по рабочему процессу:

  • Клонировать. Поскольку теперь вы можете напрямую отправлять изменения в основной репозиторий, разветвление не требуется. Идите вперед и клонируйте репозиторий. Процесс для этого объясняется в последнем уроке
  • Исходный файл редактируется. На приведенных ниже снимках экрана показаны изменения, внесенные как в исходный файл, так и в разветвленный файл. В демонстрационных целях мы модифицируем файл readme.

  • Перетаскивание. Предполагая, что вы внесли необходимые изменения, вы можете перейти на исходную страницу репозитория на GitHub и перетащить отредактированный файл на страницу. Скриншот добавлен для справки:

  • Создать новую ветку. После того, как вы перетащите отредактированный файл на страницу репозитория, вы получите возможность напрямую редактировать «мастер». ветку или создать новую ветку. В этом сценарии мы будем использовать рекомендуемый подход создания новой ветки. Когда соответствующий переключатель будет выбран, GitHub попросит вас назвать ветку. Получив название, нажмите «Предложить изменения». Каждый раз, когда вы хотите сделать резервную копию или контролировать версии своей работы, вы можете делать этот шаг. Просто убедитесь, что если вы продолжаете контролировать версии изменений перед созданием запроса на вытягивание (объяснено в следующем шаге), вы делаете это в той же ветке. Скриншоты добавлены ниже для справки:

  • Создать новый запрос на вытягивание. После того, как вы предложите изменения, вы можете создать запрос на вытягивание точно так же, как это было объяснено в сценарии 1. Обратите внимание, что, поскольку мы внесли изменения непосредственно в исходный репозиторий, вам не требуется выбирать базовый и головной репозитории, а только ветки для слияния. Кроме того, поскольку 2 ветки редактировались параллельно при слиянии, GitHub поднимает конфликт. Скриншоты добавлены для справки:

  • Разрешение конфликтов — здесь владелец репозитория и сотрудник филиала могут начать обсуждение и вместе разрешить конфликт. На GitHub это можно сделать, нажав «Разрешить конфликт», и может быть инициировано как владельцем репозитория, так и владельцем ветки. На скриншоте ниже обратите внимание на правки, которые приводят к конфликтам. Какие изменения оставить, а какие отклонить, можно решить путем взаимного обсуждения. После внесения изменений нажмите "Отметить как решенное" в правом верхнем углу экрана. Скриншот добавлен для справки:

  • Запрос на слияние. После разрешения конфликтов вы перейдете к экрану запроса на слияние, где сообщение о конфликтах будет заменено запросом на слияние. Нажмите «Запрос на слияние», а затем нажмите «Подтвердить слияние» вместе с любым сообщением, если хотите. задокументировать. Вот и все, ваши изменения объединены с веткой «master». Скриншоты добавлены для справки:

  • Повторная проверка ветки «master». После слияния вы увидите, что ветвь «master» обновлена ​​с правки из ветки.

Заключительное примечание

Есть много других функций, связанных с git и GitHub, но об этом мы поговорим в другой раз.

Вооружившись этими знаниями, сотрудничайте со своими проектными группами и оставьте заботу о контроле версий GitHub. Надеюсь, этот урок был полезен, и вы узнали что-то новое.

Постараюсь привнести больше интересных тем в будущие уроки.

ПРИЯТНОГО ОБУЧЕНИЯ!!!