Каков надлежащий этикет и рекомендуемый рабочий процесс GitHub для одновременного вклада и отклонения от вышестоящего репо?

Я новичок в GitHub и VCS в целом. Я программировал на разных языках в течение многих лет, но я всегда работал соло над индивидуальными проектами (никаких публичных выпусков). Недавно я начал использовать виджет jQuery UI, который я скачал с GitHub в проекте, над которым я работаю. Репо больше не поддерживается первоначальным автором. Другая вилка включила в себя некоторые оригинальные запросы на извлечение. Это тот, от которого я раскошелился.

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

Я все еще изучаю GIT и GitHub, и я пытаюсь найти лучший способ сделать все. Я много читал (здесь, на страницах справки по GitHub, Pro Git) о различных концепциях / задачах: рабочие процессы, слияние, запросы на извлечение, выбор вишни, перебазирование, ветвление. Мое серое вещество плавает, и я должен начать делать так, чтобы я мог лучше понять, что я прочитал.

Главные проблемы:

1. Я думаю, что прочитал (где-то), что вы можете иметь только один запрос на ветку за раз. Значит ли это, что у меня должна быть отдельная ветка для каждой ошибки, а затем я делаю отдельный пул-запрос для каждой ошибки?

2. Я хочу устранить проблемы с пробелами и, кажется, помню, что читал, что лучше сделать это в отдельном коммите. Должен ли я сделать это в моем мастере или отдельной ветке? Я не хочу делать pull-запрос для чего-то такого тривиального , но если я внесу изменения пробела перед ветвлением, повлияет ли это на pull-запрос для исправления ошибки? Некоторые вилки выполняли очистку пробелов, и это делало разницу довольно бесполезной.

3. Я думал о создании проблем с моей вилкой как о способе документирования ошибок, даже если у меня уже есть их решение. Это хорошая идея? Как мне связать воедино проблему, коммит и слияние с мастером? Если я сделаю запрос на загрузку в обратном направлении, будет ли также возникать проблема в обратном направлении, или эта ссылка на документацию будет потеряна? Я не могу открыть вопрос против репозитория (нет вкладки).

4. Какой лучший способ отдать должное другому автору форка за идею его, которую я хочу использовать? Я не могу использовать его код в точности, тем более что его изменение применяется к более старой версии апстрима и не совместимо с другими моими изменениями, как есть. Но я хочу использовать эту идею, и я хочу отдать должное, где кредит должен. Должен ли я просто указать ссылку на его репо (или профиль, или конкретный коммит) в моем сообщении о коммите?

5. Каков этикет в отношении изменения файла readme и DocBlock в верхней части основного файла? Можно ли вносить изменения, добавлять мое имя, добавлять ссылки в репозиторий и демо-версию, удалять ссылки на исходную демоверсию (поскольку мой форк окажется несовместимым с оригиналом)? Конечно, я оставлю оригинальное имя автора и информацию о лицензии. Для записи, он лицензирован под лицензией MIT.

Как сольный разработчик, который никогда не использовал VCS, я привык переписывать историю . Я перфекционист и люблю, чтобы вещи были опрятными и аккуратными. Идея записанной истории заставляет меня немного нервничать, и я хочу сделать это правильно с первого раза . Я создал новый репозиторий, с которым можно играть / учиться, но мне не терпится приступить к исправлению виджета пользовательского интерфейса jQuery, чтобы я мог продолжить работу над своим проектом.

1. Правильно: pull-запрос связан с веткой в ​​вашем хранилище. Если вы изменяете ветку, вы также изменяете то, что вы отправляете как pull-запрос.

   Так что да, вам нужно создать ветку (и pull-запрос) для каждого исправления ошибки. Возможно, было бы целесообразно начать с одного и посмотреть, как сопровождающий реагирует на него, прежде чем делать все остальное. Открытый исходный код - это по своей сути социальный процесс.

2. Сделайте пул-запрос на изменения пробелов! Говоря, как кто-то, кто иногда является сопровождающим, я люблю эти типы запросов: я либо одобряю их, либо нет, и они обрабатывают мало времени.

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

3. Хм .. Непонятно, чего ты здесь пытаешься достичь. Это звучит как чрезмерная документация и не очень хорошая идея - может быть, вы можете уточнить, почему вы хотели бы сделать это?

4. Ссылка на его репо в сообщении о коммите (или даже в комментарии в коде) - отличный способ отдать должное. Однако будьте осторожны - четко заявите, что вы благодарите его за его идеи, а не за его код. Если вы скопировали код, я отправил бы ему письмо по электронной почте, если не очень ясно, какую лицензию он использует для своего кода. Если лицензирование ясно (и оно отличается от лицензии на репозиторий, в который вы отправляете коммит), вам нужно добавить другую лицензию в ваш запрос на извлечение, а также указать это в сообщении для вашего запроса.

5. Это действительно хороший вопрос, и он зависит от того, с кем вы разговариваете. Я считаю, что вы никогда не должны добавлять свое имя в любой коммит или код, который вы делаете. Основная причина в том, что это подразумевает «владение и ответственность за код» - это может помешать другим модифицировать код, потому что «он ваш». Но сейчас мы входим в большую дискуссию о природе открытого исходного кода, поэтому я остановлюсь здесь и скажу - спросите сопровождающего проекта или просто сделайте это и посмотрите, какова его реакция.

6. Вы можете переписать (вашу местную, еще не опубликованную) историю с помощью GIT! Изучите команду git rebase - это одна из главных причин, по которой я люблю git. Это действительно плохая идея (принудительно) отправлять перезаписанные коммиты / историю в общий репозиторий (например, github). Затем это будет связано с репозиториями, которые есть у других разработчиков - они должны будут делать сложные вещи, когда тянут ваши (переписанные истории) изменения.

[# 6: Спасибо @toxalot!]