Skip to content

Latest commit

 

History

History
466 lines (295 loc) · 27.3 KB

lesson10.md

File metadata and controls

466 lines (295 loc) · 27.3 KB
Raw

Лекция 10. Git. Удаленный репозиторий. Remote, push, pull. GitHub, BitBucket, GitLab, etc. Pull request.

Удалённый репозиторий

Удалённый репозиторий – это версия вашего проекта, которая хранится в интернете или другой сети. Он позволяет вам и другим разработчикам совместно работать над проектом. В Git удалённые репозитории обозначаются как "remotes".

Зачем нужны удалённые репозитории?

Удалённые репозитории в Git играют ключевую роль в командной разработке и управлении проектами. Вот основные причины, по которым они необходимы:

  • Совместная работа:

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

git_team.jpg

  • Резервное копирование:

Пример: Если локальный репозиторий на компьютере разработчика будет повреждён или утерян, все данные проекта будут утеряны. Удалённый репозиторий обеспечивает надёжное резервное копирование.

  • Доступ из любой точки:

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

  • Интеграция с CI/CD и другими сервисами:

Пример: Удалённые репозитории могут интегрироваться с системами непрерывной интеграции и доставки (CI/CD), что позволяет автоматизировать тестирование и развёртывание приложений.

  • Контроль версий и история изменений:

Пример: Удалённые репозитории сохраняют всю историю изменений, позволяя просматривать и восстанавливать предыдущие версии проекта.

Управление разрешениями и безопасность:

Пример: Удалённые репозитории позволяют управлять доступом и разрешениями для различных пользователей и команд, обеспечивая безопасность проекта.

А какие бывают платформы для хранения репозиториев?

Существует довольно много различных платформ для хранения репозиториев, например GitHub, GilLab, BitBucket, AzureRemotes, AWS CodeCommit. И многие другие.

Но годами самые популярные платформы это GitHub, GilLab, BitBucket. Большинство известных мне проектов используют именно их.

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

GitHub

GitHub – это одна из самых популярных платформ для хостинга Git-репозиториев. Она предоставляет мощные инструменты для совместной работы, такие как pull requests, issues и GitHub Actions.

BitBucket

BitBucket – это платформа для хостинга Git-репозиториев, которая также поддерживает Mercurial. BitBucket предлагает интеграцию с Jira и другие инструменты Atlassian для управления проектами.

GitLab

GitLab – это платформа для хостинга Git-репозиториев, которая также предоставляет CI/CD, issue tracking и множество других функций для DevOps.

И что с этим делать?

Любая из этих платформ предполагает что вы должны на ней зарегистрироваться и залогинится.

После этого появится возможность создать свой собственный новый репозиторий

Ну, или если мы говорим о коммерческой разработке, то скорее всего репозиторий уже создан, и ваш аккаунт просто добавят к существующему репозиторию

Публичные и приватные репозитории

Публичные репозитории

Публичный репозиторий – это репозиторий, доступ к которому может получить любой пользователь. Публичные репозитории обычно используются для открытых проектов и open-source разработки.

Преимущества публичных репозиториев

  • Открытый доступ:

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

    • Позволяет другим разработчикам вносить свой вклад в проект через pull requests. Облегчает привлечение новых участников и сторонних разработчиков. Популяризация проекта:

    • Проект становится видимым и доступным для широкой аудитории. Упрощает демонстрацию вашего кода потенциальным работодателям или партнёрам.

Недостатки публичных репозиториев

  • Ограниченная приватность:

    • Весь код и история коммитов видны всем пользователям. Могут возникнуть проблемы с защитой интеллектуальной собственности.

  • Открытость уязвимостей:

    • Все уязвимости и ошибки в коде также видны всем пользователям.
    • Может потребоваться более тщательный контроль качества и безопасности кода.

Приватные репозитории

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

Преимущества приватных репозиториев

  • Контроль доступа:

    • Доступ к коду имеют только авторизованные пользователи.
    • Упрощает управление доступом и ролями в команде.

  • Защита интеллектуальной собственности:

    • Код и информация о проекте остаются конфиденциальными.
    • Подходит для коммерческих проектов и внутренних разработок.

  • Безопасность:

    • Уязвимости и ошибки в коде видны только определённым пользователям.
    • Облегчает внедрение мер по защите кода и данных.

Недостатки приватных репозиториев

  • Ограниченное участие сообщества:

    • Вклад сообщества ограничен или невозможен.
    • Сложнее привлечь сторонних разработчиков и участников.

  • Стоимость:

    • Многие платформы требуют плату за использование приватных репозиториев (например, GitHub).
    • В некоторых случаях требуется покупка лицензий или подписок.

Примеры платформ и их подходов к приватности

GitHub:

  • Поддерживает как публичные, так и приватные репозитории.
  • Публичные репозитории бесплатны, за приватные может взиматься плата в зависимости от тарифного плана.

GitLab:

  • Поддерживает публичные и приватные репозитории.
  • Предлагает бесплатные приватные репозитории с базовым функционалом, а также платные планы с расширенными возможностями.

BitBucket:

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

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

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

Для обучения мы будем использовать публичные репозитории, на работе скорее всего будут приватные репозитории.

Варианты доступа к Git-репозиториям. HTTPS vs SSH

Git-репозитории могут быть доступны через два основных протокола: SSH и HTTPS. Мы не будем пока что разбирать их особенности, сделаем это намного дальше по курсу. Каждый из этих способов имеет свои особенности, и выбор между ними зависит от ваших требований и предпочтений.

Доступ через HTTPS

HTTPS (HyperText Transfer Protocol Secure) – это протокол, который использует шифрование SSL/TLS для защиты передаваемых данных. Доступ к Git-репозиториям через HTTPS возможен с использованием логина и пароля.

Пример URL для доступа через HTTPS:

https://github.com/username/repository.git

  • Преимущества HTTPS:

    • Простота настройки: Для доступа через HTTPS достаточно иметь логин и пароль. Это удобно для новичков и быстрого начала работы.
    • Работа в ограниченных сетях: HTTPS легко проходит через брандмауэры и прокси-серверы, что делает его хорошим выбором для работы в корпоративных сетях.
    • Универсальность: HTTPS доступен на любом устройстве и операционной системе без дополнительной настройки.

  • Недостатки HTTPS:

    • Неудобство частого ввода пароля: При каждом взаимодействии с удалённым репозиторием требуется вводить логин и пароль, что может быть неудобно.
    • Ограниченная безопасность: Хотя HTTPS обеспечивает шифрование данных, использование логина и пароля может быть менее безопасным по сравнению с SSH-ключами.

Доступ через SSH

SSH (Secure Shell) – это протокол, который предоставляет защищённый способ доступа к удалённым системам. Доступ к Git-репозиториям через SSH осуществляется с использованием пары SSH-ключей (открытого и закрытого ключа).

Пример URL для доступа через SSH:

git@github.com:username/repository.git

  • Преимущества SSH:

    • Безопасность: SSH использует криптографическую пару ключей, что обеспечивает высокий уровень безопасности. Пароль не передаётся по сети, что уменьшает риск его перехвата.
    • Удобство использования: После первоначальной настройки SSH-ключей нет необходимости вводить пароль при каждом взаимодействии с репозиторием.
    • Гибкость: SSH позволяет настраивать доступ для разных пользователей и ключей, что удобно для управления командой разработчиков.

  • Недостатки SSH:

    • Сложность настройки: Настройка SSH-ключей требует некоторых технических знаний и больше времени по сравнению с HTTPS.
    • Ограничения на уровне сети: В некоторых корпоративных сетях доступ через SSH может быть ограничен или заблокирован.

Примеры использования и настройки

Настройка доступа через HTTPS

Клонирование репозитория через HTTPS:

git clone https://github.com/username/repository.git

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

Настройка доступа через SSH

Создание SSH-ключей:

Самый простой способ для создания пары ключей для SSH это использовать консоль линукса. Если вы используете Windows, то вы можете использовать консоль которая была установленна вместе с GIT. Там эти команды тоже будут работать.

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Следуйте инструкциям и сохраните ключи в файлах по умолчанию (~/.ssh/id_rsa и ~/.ssh/id_rsa.pub).

В Windows путь будет другой, убедитесь что вы запомнили где будут созданы ключи!!

Добавление публичного ключа в аккаунт Git-платформы:

Скопируйте содержимое файла ~/.ssh/id_rsa.pub (или ваш путь для Windows) и добавьте его в настройки SSH-ключей на платформе (например, GitHub, GitLab, BitBucket).

Клонирование репозитория через SSH:

git clone git@github.com:username/repository.git

Про git clone

Команда git clone - создает fork. Форк - это копия любого репозитория.

Если вы хотите создать копию удаленного репозитория локально нам поможет именно команда git clone

Выводы

Выбор между HTTPS и SSH для доступа к Git-репозиториям зависит от ваших требований и предпочтений. HTTPS проще в настройке и подходит для быстрого начала работы, особенно в ограниченных сетях. SSH обеспечивает более высокий уровень безопасности и удобства использования после первоначальной настройки.

Понимание различий между этими протоколами и их преимуществ поможет вам выбрать наиболее подходящий способ доступа к вашим Git-репозиториям и обеспечит надёжное управление проектами.

В рамках курса мы будем использовать именно SSH ключи!

Работа с удалёнными репозиториями

Для того что бы несколько разработчиков могли работать над одним удаленным репозиторием, они все должны быть подключены к одному удаленному репозиторию, гит об этом должен как то узнать.

Добавление удалённого репозитория

Чтобы добавить удалённый репозиторий, используется команда git remote add:

git remote add origin <URL>

Здесь origin – это стандартное имя для удалённого репозитория. Вы можете использовать любое другое имя, если хотите. Но обычно если у вас один удаленный репозиторий, то он называется именно так.

Просмотр удалённых репозиториев

Чтобы посмотреть список всех настроенных удалённых репозиториев, используйте команду:

git remote -v

Удаление удалённого репозитория

Чтобы удалить удалённый репозиторий, используйте команду:

git remote remove <name>

Изменение URL удалённого репозитория

Чтобы изменить URL удалённого репозитория, используйте команду:

git remote set-url origin <new-url>

Команды push и pull

Команда git push

git push – это команда для отправки ваших локальных изменений в удалённый репозиторий. Она передаёт коммиты из локальной ветки в соответствующую ветку удалённого репозитория.

git push origin main

Эта команда отправляет изменения из локальной ветки main в ветку main на удалённом репозитории origin.

Если ветка существует только локально, но не существует на удаленном репозитории, гит покажет ошибку, и подскажет команду которую надо выполнить, что бы успешно пушнуть код, и создать ветку на удаленном репозитории.

Команда git pull

git pull – это команда для получения и объединения изменений из удалённого репозитория в вашу локальную ветку. Эта команда сочетает в себе команды git fetch и git merge.

git fetch

Эта команда получает из удаленного репозитория всю информацию которая отличается от вашей локальной версии. Ничего не меняет!! Только получает информацию, что, что-то изменилось.

git merge

Уже обсуждали, повторю, объединяет две ветки. В данном случае локальную и удаленную, с одинаковыми названиями.

Использование двух команд, вместо команды pull не встречается на практике.

git pull origin main

Эта команда получает изменения из ветки main удалённого репозитория origin и объединяет их с локальной веткой main.

Pull Request

Pull Request (PR) – это механизм для предложения изменений в проекте. Он позволяет другим разработчикам просмотреть ваш код перед его включением в основную ветку проекта. Pull request включает в себя описание изменений, обсуждения, ревью кода и возможность автоматического тестирования.

Именно так и надо будет сдавать домашние задания и модули, в виде пулл реквестов.

Процесс создания Pull Request

  1. Клонирование репозитория:

    • Клонируйте репозиторий на ваш локальный компьютер.
    git clone <URL>

  2. Создание новой ветки:

    • Создайте новую ветку для ваших изменений.
    git checkout -b feature-branch

  3. Внесение изменений и коммит(ы):

    • Внесите необходимые изменения и создайте коммит(ы).
    git add .
git commit -m "Добавлено новое изменение"

  4. Отправка изменений в удалённый репозиторий:

    • Отправьте изменения в ваш удаленный репозиторий на GitHub, BitBucket или GitLab.
    git push origin feature-branch

  5. Создание Pull Request:

    • Перейдите на страницу вашего репозитория на платформе и создайте новый pull request, выбрав основную ветку проекта и вашу ветку с изменениями.

Этот процесс выглядит по разному на каждом сайте, но суть всегда одна и та же. На занятии покажу как это выглядит на GitHub

  1. Ревью и обсуждение:

    • Ведите обсуждение изменений с другими разработчиками. Возможно, вам потребуется внести дополнительные изменения.

  2. Мерджинг Pull Request:

    • После завершения ревью и одобрения изменений ваш pull request может быть объединён с основной веткой проекта.

Про совместную работу

Для того что бы я мог проверять ваши домашки, я должен быть добавлен в ваш репозиторий как колаборатор.

Для этого надо:

  1. Открыть свой репозиторий
  2. Перейти в настройки (Settings)
  3. Найти там collaborators
  4. Нажать добавить (add people)
  5. Вписать мой ник PonomaryovVladyslav
  6. Дождаться пока я подтвержу участие в проекте

Эти действия нужно выполнять для каждого созданного репозитория (Домашки, Модули, Веб, лучше всего для разных проектов и разделов обучения создавать новый репозиторий)

Как сдавать домашки

Для этого есть вот эта инструкция!

Жду код первого модуля в виде пулл реквеста! Всем удачи!!!