Як я можу внести внесок до коду інших в GitHub? [зачинено]


231

Я хотів би внести свій внесок у певний проект у GitHub . Я повинен роздрібнити його? Відділити його? Що рекомендується і як це зробити?


61
Ще одне смішне закриття
Стівен

4
Я написав докладніший покроковий посібник із допису до Concrete5 у Github, але процес може стосуватися будь-якого проекту. Перевірте це .
Джо Мейєр

7
Я насправді не бачу, як це "не конструктивно". Самі голоси та погляди підтверджують, що це популярне питання, на яке люди хочуть відповісти.
Ян


1
можливо, при достатньому голосуванні більшості, попередньо закриті раніше питання повинні бути дозволені, щоб знову поставити, і нехай люди знову внесуть участь у нитку.
Петро Тео

Відповіді:


180

В ідеалі ви:

  1. Розкладіть проект
  2. Зробіть одну чи кілька добре прокоментованих та чистих комісій у сховище. Тут ви можете створити нову гілку, якщо ви змінюєте більше однієї частини чи функції.
  3. Виконайте запит на виклик у веб-інтерфейсі github.

якщо це новий запит на функцію, не запускайте кодування спочатку. Не забудьте опублікувати проблему, щоб обговорити нову функцію.

Якщо функція добре обговорюється і є якийсь +1, або власник проекту затвердив її, призначте проблему собі, тоді виконайте дії, описані вище.

Деякі проекти не використовуватимуть систему запиту. Зверніться до автора чи списку розсилки щодо найкращого способу повернення коду до проекту.



1
Так, тягнути запит. Запит на об'єднання - це грізна термінологія.
Янна Рамін

2
@MariusKavansky це навпаки! Як тільки ви знаєте, над чим працювати, тоді ви лише робите свій внесок :)
hashbrown

після того, як я взяв участь у проекті з відкритим кодом. Я думаю, що краща ідея відкрити питання для обговорення нової функції, якщо це нова функція. Якщо це добре обговорена особливість чи проблема, вам слід призначити це питання, тоді виконайте дії, описані вище. Це мої 2 центи.
wizztjh

@hashbrown, Він запитує, де зараз "список" запитуваних функцій. Ті функції, які вже запитуються та поставили +1.
Пейсьер

31

Щоб додати відповідь Ян , після того, як ви роздрібнили проект, ви зможете розвиватися в будь-якій галузі, яку ви хочете (новій або одній з оригінального проекту)

Пам'ятайте:


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/

Також не забудьте подивитися на правій бічній панелі під заголовком "співпрацююча".


10

Існує велика Railscast відео тут , що проведе вас через процес. Він також має ряд корисних порад, таких як показати, як визначити, над якою галуззю ви хочете працювати, коли працюєте, використовуючи тести, підмодулі тощо.

Хоча ця трансляція орієнтована в першу чергу на розробників Rails, більшість інформації є дійсною для участі в будь-якому проекті з відкритим кодом.


4

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

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

  • Викладіть репо в github
  • Клоніруйте репо до своєї машини
  • Зробіть відділення та внесіть необхідні зміни
  • Натисніть на зміни на вилці на GitHub git push origin branch-name
  • Перейдіть до роздрібнення на GitHub, щоб побачити Compare and pull requestкнопку
  • Клацніть на ньому та вкажіть необхідні деталі


2

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

Я б запропонував такий робочий процес:

  1. Розкладіть сховище (через веб-інтерфейс GitHub: кнопка "Fork")
  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 років). Оголошено.
VonC
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.