Работа на Drupal и PHP - HookAny.com

Что делать, если ты нашел баг в проекте с Github и знаешь, как его исправить

В этой заметке я максимально сжато и доходчиво опишу последовательность действий от создания форка проекта на Github до внедрения исправления в основной проект.
Заметка будет особенно полезна разработчикам, которые только начинают работать с Git и Github.

1) Ты нашел нужную тебе либу на Github и подключил ее через composer к своему проекту:

composer require author/project

2) Внезапно ты понял, что в либе есть баг, и ты хочешь его исправить сам.
3) Для этого ты делаешь форк либы на Github (кнопка Fork).
4) Клонируешь свой форк себе в локальную папку (любую), например workspace/project
git clone git@github.com:yournickname/project.git ./workspace/project

5) Фиксишь баг.
6) Затем все свои изменения добавляешь в Git:
git add .

7) И комитишь их:
git commit -m "Fixed bug ...."

8) Потом заливаешь в удаленный репозиторий твоего форка на Github:
git push origin master

9) Теперь тебе нужно, чтобы твой большой проект использовал вместо оригинальной либы твой форк.
Для этого выставляешь в composer.json:
{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/yournickname/project"
        }
    ],
    "require": {
        "author/project": "dev-master"
    }
}

Обрати внимание, что версия проекта меняется на dev-master, где master - это ветка в твоем форке.
10) Чтобы применить свои изменения в composer.json, запускаешь:
composer update

11) Заходишь в папку vendor/author/project твоего большого проекта и видишь, что там лежит код форка, а не оригинального проекта.
Вот и все, баг исправлен, и ты можешь работать дальше, но...
12) Если ты уверен в своем исправлении и хочешь поделиться им с другими, ты заходишь на страницу своего форка на Github и видишь там надпись типа: "Данный проект впереди оригинального на 1 коммит. Создать pull request?"
Ты соглашаешься создать заявку на включение твоего фикса в оригинальный проект (pull request или, коротко, PR). В описании PR описываешь суть твоего фикса и просишь поревьюить.
13) Когда автор поревьюит и смерджит твои изменения с основным проектом, ты заходишь в composer.json и удаляешь из секции repositories упомнание твоего форка:
{
    "type": "vcs",
    "url": "https://github.com/yournickname/project"
}

И снова выставляешь нужную версию либы в require:
"require": {
    "author/project": "^1.1.2"
}

Как правило, автор оригинального проекта создает новую версию после внесения твоих изменений в проект.
14) Обновляешь зависимости:
composer update

И ты снова работаешь с оригинальным проектом, который теперь содержит на один баг меньше.

Данная последовательность шагов вылилась из дискуссии в чате Drupal сообщества Санкт-Петербурга, где полезная информация весьма частое явление. Спасибо Майку за то, что поднял тему.