Начало с Git и история геймдевера. Часть 2. Удаленные репозитории, работа в команде, Clone, Push и Pull Request.

Напомню, что в предыдущей статье мы начали "историю гейм девелопера" как пример для постепенного объяснения и изучения Git. Что же дальше? А дальше мы перенесем наш репозиторий проекта на удаленный и добавим в нашу команду разработчиков нового участника. Интересно? Отлично, ведь мы начинаем!

5) Представим, что в вашу игру уже играют достаточное количество людей и у вас находят всё чаще и больше багов. Один, по всей видимости вы не справитесь. Что же делать? Использовать удаленный*, а не локальный** репозиторий, конечно!

Локальный репозиторий - это репозиторий, находящийся на вашем компьютере, которым вы пользуйтесь именно сейчас. Если это сервер, то этот же репозиторий может являться и удаленным* для других устройств.

Удаленный репозиторий - это репозиторий, находящийся на другом компьютере (или сервере). В основном такие репозитории хранятся на всяких сервисах типа GitHub, GitLab, BitBucket и т.д.

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

Скачать репозиторий можно, но зачем? Намного удобнее использовать клонирование. Клонирование - это перенос репозитория из удаленного в локальный и наоборот. (Не путать с Push)

6) Так, вы клонировали репозиторий на GitHub и теперь дали к нему доступ Олегу - вашему другу. Он делает, к примеру, функцию сохранения в Google Drive. Он создает новую ветку Feature/cloud_saving. Однако эта ветка создалась только у него на компьютере. Почему так произошло?

Это произошло, потому что клонирование работает так, что вы просто создаете у себя на компьютере локальный репозиторий, который следует за удаленным. Олег создал ветку только у себя на локальном репозитории, а чтобы она создалась на удаленном ему надо выполнить Push*.

Push - это отправка всех новых изменений с локального на удаленный репозиторий. Каждая ветка отправляет коммиты на удаленную ветку, которой она следует. Например, на удаленном репо. есть ветка origin/dev, а у вас на "локалке" есть ветка dev. Логично, что ветка dev будет отправлять свои коммиты на origin/dev. Это и есть следование локальной ветки удаленной. (Не забывайте, что это идет именно Локальный -> Удаленный, а не наоборот)

7) Так, Олег, по всей видимости, уже закончил фичу и решил, что она уже готова. Однако просто взять и залить всё в основную ветку - не вариант. Надо чтобы главный разработчик - в данном случае вы - проверил всё. Иначе в проектах с открытым исходным кодом творился бы полный хаос. Но Олегу сообщить вам, что фича готова? В реале встретиться - не удобно. Как же быть? Для этого есть Pull Request*.

Pull Request - незаменимая функция Git для Open Source проектов, особенно когда за проектом следят команда из разрабов, а претендентов на добавление новых фич - море. К каждому обращаться не совсем правильно, так что для этого у Git есть свой метод. Вы просто кидаете свои изменения из вашей ветки в основную ветку и к одному из главных разработчиков (владельцев проекта или ветки) приходит уведомление, что такой-то человек хочет добавить в такую-то ветку такие-то изменения. В таком случае этот владелец проекта смотрит изменения, делает Code Review, и делает вывод - добавлять эту фичу, отправить на доработку или полностью отклонить. (Надеюсь было понятно)

На этом вторая часть окончена, а в следующей мы поговорим о таких вещах как rebase как альтернатива merge (да, да, в следующей, а не в этой), merge конфликты и их решения. Спасибо за внимание!