Зачем нужен pull request, если есть push?

На текущем проекте мне советовали загружать каждый таск так:
Создаем ветку по имени таска Комитим pull request - Отправляем все на удаленный репозиторий Далее мне советуют: "смотришь код и мерджишь"
Не совсем понятен четвертый пункт. Мне советуют для каждого таска ветвь создавать, заливать в нее изменения, и сливать обратно с master. Я понимаю, что репозитория два: локальный и удаленный.
Т.е. мне создавать на локальном ветку, коммитить, мержить и пушить на удаленный репозиторий? Перед этим всем скачать обновления с удаленного. Зачем тогда нужен pull request, если push и так отправляет данные в удаленный репозиторий?

Ответ

Организация работы, основанная на пулл-реквестах (pull-request, merge-request, запрос на слияние), характерна для распредленных проектов, которые размещаются на специальных хостингах репозиториев. Git сам по себе не имеет такого функционала, он реализуется именно хостингом. Кроме GitHub эту возможность предоставляет Gitlab, возможно есть и другие хостинги. Называется такая организация GitHub flow или Gitlab flow - в противоположность более традиционному Git flow git-flow ("flow" - поток).
Про организацию Git flow можно почитать в описании метки. Кратко: есть основная ветка master, разработчики создают ветки под конкретные задачи (фича, багфикс), потом сливают их в master. Возможно использование ветки-агрегатора develop, в которой копятся изменения до момента очередного релиза.
Git flow реализуем, когда у всех разработчиков есть право создавать новые ветки в удалённом репозитории. Это часто так при закрытой разработке внутри компании, но почти всегда не так, когда проект хостится открыто. Нельзя просто так взять и запушить свою ветку в чужой репозиторий на GitHub.
Другое важное право - сливать изменения в ветку master или другую, из которой код уходит в производство. В открытом репозитории это может делать владелец или группа уполномоченных пользователей. В закрытом код обычно может сливать ответственный за это сотрудник. Перед слиянием код может и должен проходить инспекцию и тестироваться. Если у вас не так - повод обеспокоиться.
Чтобы у разработчиков всё-таки была возможность принимать участие, коммитить свои изменения/дополнения и потом предлагать слить их в основную ветку проекта, были придуманы форки (fork, вилка). Форк - это ваша собственная копия целого репозитория Git. В ней вы можете создавать собственные ветки, делать новые коммиты и всё остальное, что можно делать с принадлежащим вам репозиторием.

Чтобы предложить добавить ваши изменения в основной репозиторий, используется пулл-реквест. Алгоритм создания такой:
Создаете локальную ветку. Создаете в ней новые коммиты (иначе нет смысла в слиянии). Пушите эту локальную ветку на удаленный репозиторий. Заходите на сайт хостинга репозиториев. Там выбираете одну из веток вашего удаленного репозитория и предлагаете влить её в одну из веток другого удалённого репозитория. Как вариант, если у вас есть право создавать ветки, но нет права сливать в master - можно создавать пулл-реквест внутри одного репозитория. Нажимаете кнопку подтверждения.
Теперь создаётся собственно пулл-реквест, как сущность. У него в том числе есть:
Номер и url. Он также появляется в списке открытых реквестов целевого репозитория. Информация о внесённых изменениях в формате diff. Красным подсвечиваются удалённые строки, зелёным добавленные. Есть общая статистика добавленных и удаленных строк.
Возможность оставлять комментарии к любой строке диффа, а также к пулл-реквесту в целом. Эта невероятно полезная возможность позволяет проводить инспекцию кода прямо в пулл-реквесте.
Информация о новых коммитах в виде дерева.
Автоматическая оценка возможности бесконфликтного слияния. Если оно невозможно, придётся вручную разрешать конфликты, как в обычном слиянии. Кнопки, чтобы слить или, наоборот, отклонить запрос.
Изучив ваш пулл-реквест, владелец основного репозитория может выполнить его слияние (а может и нет). Отсюда и название: не вы "выталкиваете" (push) свои изменения в чужой репозитория, а уполномоченный пользователь их "затаскивает" (pull) в него.