Git - pull request, push, работа в команде и т.д
Бэкендер
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, и делает вывод - добавлять эту фичу, отправить на доработку или полностью отклонить. (Надеюсь было понятно)

Спасибо за внимание!