Как я могу внести свой вклад в чужой код в GitHub? [закрыто]

231

Я хотел бы внести свой вклад в определенный проект в GitHub . Должен ли я это раскошелиться ? Разветвить это? Что рекомендуется и как это сделать?

wizztjh
источник
61
Еще один нелепый
конец
4
Я написал более подробное пошаговое руководство по внесению вклада в Concrete5 на Github, но этот процесс можно применить к любому проекту. Проверьте это .
Джо Мейер
7
Я действительно не вижу, как это «не конструктивно». Только голоса и мнения являются доказательством того, что это популярный вопрос, на который люди хотят получить ответы.
Ян
1
возможно, с достаточным большинством голосов, ранее разрешенные вопросы должны быть снова воскрешены, и пусть люди снова вносят свой вклад в обсуждение.
Питер Теох

Ответы:

180

В идеале вы:

  1. Форк проект
  2. Сделайте один или несколько хорошо прокомментированных и чистых коммитов в хранилище. Вы можете создать новую ветку здесь, если вы изменяете более одной детали или функции.
  3. Выполните pull-запрос в веб-интерфейсе github.

если это новый запрос Feature, не начинайте сначала кодирование. Не забудьте опубликовать вопрос, чтобы обсудить новую функцию.

Если функция хорошо обсуждена, и некоторые +1 или владелец проекта одобрил ее, назначьте проблему для себя, а затем выполните действия, описанные выше.

Некоторые проекты не будут использовать систему запросов на выборку. Узнайте у автора или списка рассылки, как лучше вернуть ваш код в проект.

Ян Рамин
источник
4
Подробная информация о разветвлении и запросах
Габриэль Грант
1
Да, вытащить запрос. Запрос на слияние - это полезная терминология.
Ян Рамин
2
@MariusKavansky это наоборот! Как только вы знаете, над чем работать, только вы
вносите
после того, как я внес свой вклад в какой-то проект с открытым исходным кодом. Я думаю, что лучше было бы открыть вопрос, чтобы обсудить новую функцию, если это новая функция. Если это функция или проблема, которая хорошо обсуждалась, вы должны назначить эту проблему себе, а затем выполнить действия, описанные выше. Это мои 2цента.
wizztjh
@hashbrown, он спрашивает, где находится «список» запрошенных функций. Те функции, которые уже запрашиваются и + 1 ед.
Pacerier
31

Чтобы добавить к ответу Янна , после того, как вы разбудили проект, вы можете разрабатывать в любой отрасли, которую хотите (новую или одну из исходного проекта)

Запомни:

VonC
источник
1
Можете ли вы добавить детали или ссылки на ваш второй пункт (перебазирование ветки) ?
JorgeArtware
1
@JorgeArtware Я обновил ответ несколькими ссылками, иллюстрирующими ребаз.
VonC
@VonC Я задаю вопрос здесь, но если вы считаете, что это необходимо, я сделаю из этого совершенно новый вопрос. Зачем мне делать ребаз вместо слияния, кроме «прямой истории»? Другими словами, вот что я делаю, когда я участвую в некоторых проектах (после того, как PR из моей функциональной ветви был объединен для разработки и основной ветки): то git checkout master; git pull;же самое для разработки (где моя функциональная ветвь была объединена первой). из, после прочтения "pull vs pull --rebase" и "merge vs rebase" просто плоская история. Что-нибудь еще более глубокое?
linuxbandit
@grasshopper в терминах «вклада» (в контексте этой страницы), вы всегда хотите перебазировать свои локальные коммиты поверх обновленных веток, прежде чем нажимать: это сделает упомянутый вклад тривиальным для интеграции сопровождающим в исходную ветку проекта. В контексте вашего вопроса, где ваш PR был принят, конечно, вы можете объединить вместо ребаз, чтобы обновить существующие филиалы.
VonC
(Извините, изменил имя пользователя только сейчас, чтобы отразить мой github) - @VonC спасибо, так что все предложения, которые я читал о ребазе, применяются до PR, имеют смысл. Чтобы отразить принятый и объединенный PR внутри моего локального репо, есть ли какая-либо распространенная практика (перебазировка вместо слияния), или я могу сделать что-нибудь еще? Что если я подам еще один пиар?
linuxbandit
15

Чтобы добавить к ответам Яна и VonC, это хороший ресурс от самих github: http://help.github.com/forking/

Также обязательно посмотрите на правую боковую панель под заголовком «Сотрудничество».

brycemcd
источник
10

Существует большое Railscast видео здесь , что проведет вас через процесс. В нем также есть несколько полезных советов, таких как показ того, как определить, над какой веткой вы хотели бы работать при добавлении, с помощью тестов, субмодулей и т. Д.

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

SnapShot
источник
4

У Github есть много способов сотрудничества с проектом. Модель, используемая в большинстве проектов, представляет собой модель запроса на извлечение. Я начал проект, чтобы помочь людям сделать первый запрос на GitHub. Вы можете сделать практический урок, чтобы сделать свой первый PR здесь

Рабочий процесс прост как

  • Репо в github
  • Клонируйте репо на свою машину
  • Сделайте ветку и внесите необходимые изменения
  • Поместите ваши изменения в ваш форк на GitHub git push origin branch-name
  • Перейдите на свой форк на GitHub и увидите Compare and pull requestкнопку
  • Нажмите на нее и укажите необходимые данные
Судо Бэнгбэнг
источник
2

Технический рабочий процесс

Я бы предложил следующий рабочий процесс:

  1. Форк репозитория (через веб-интерфейс GitHub: кнопка «Форк»)
  2. В своем разветвленном хранилище скопируйте URL
  3. Клон (в командной строке)

    git clone <url-from-your-workspace>

  4. Введите каталог, который только что был создан, и создайте ветку

    cd <directory> git checkout -b <branchname>

  5. Теперь внесите свои изменения

  6. Вы можете создать один или несколько коммитов после каждого изменения:

    commit -a

  7. Когда закончите, нажмите ваши изменения

    git push origin <branch>

  8. В вашей командной строке вы должны увидеть URL для создания PR . Посетите URL и нажмите кнопку, чтобы создать PR.

  9. Если нет, посетите репозиторий в браузере, и он предложит вам кнопку для создания запроса на извлечение.

Вот и все.

Итак, в основном, вы разветвили репозиторий в свою рабочую область, создали новую ветку и добавили эту новую ветку.

Если вы позже сделаете больше PR из того же клонированного репо, вам нужно синхронизировать (получить последние изменения из исходного репозитория), прежде чем создавать другую ветку для другого PR:

git checkout master
git remote add upstream <url-of-original-repo>
git pull upstream master

Другие соображения:

  • проект может иметь Рекомендации по вкладу: найдите файл CONTRIBUTING.rst или .md
  • Вы можете следовать руководству по кодированию для проекта
  • Вы можете изложить свою идею в первую очередь
  • Вы можете посмотреть вкладку «Запросы на извлечение» для проекта и проверить, есть ли открытый PR, объединенный PR

Эти предложения здесь, чтобы уберечь вас от необходимости вкладывать работу в PR, который не будет объединен. Если в проекте есть активность, и пиар слился, это хороший знак. Если есть рекомендации для участников, следуйте им.

Всегда будь вежливым. Помните, что сопровождающие проекта никоим образом не обязаны объединять ваш PR. У вас есть что добавить в проект?

Сибилла Питерс
источник
1
Хорошо подробный процесс (точнее, чем мой 9-летний ответ). Upvoted.
VonC