Що таке правильний етикет та рекомендований робочий процес GitHub для одночасного сприяння та відхилення від репо-виходу за течією?


21

Я новачок у GitHub та VCS взагалі. Я роками програмував на різних мовах, але завжди працював сольно над власними проектами (жодних публічних релізів). Нещодавно я почав використовувати віджет інтерфейсу jQuery, який я завантажив з GitHub у проекті, над яким я працюю. Оригінальний автор вже не підтримує репо. Ще одна вилка включила деякі оригінальні запити на витяг. Це той, від якого я розщедрився.

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

Я все ще вивчаю GIT та GitHub, і я намагаюся винайти найкращий спосіб зробити все. Я багато читав (тут, ТАК, довідкові сторінки GitHub, Pro Git) про різні поняття / завдання: робочі процеси, об'єднання, запити на витяг, збирання вишні, перезавантаження, розгалуження. Моя сіра речовина - плавання, і мені потрібно почати займатися, щоб я краще зрозумів, що я прочитав.

Основні питання:

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

  2. Я хочу прибрати проблеми з пробілами, і, здається, пам’ятаю, що читав, що найкраще це зробити в окремому комітеті. Чи повинен я це робити у свого господаря чи окремої гілки? Я не хочу робити запит на витяг для чогось такого тривіального , але якщо я внесу зміни в пробіли перед розгалуженням, це вплине на запит на виправлення помилок? Деякі вилки зробили пробіл, і це ефективно зробило різницю марною.

  3. Я думав створити проблеми проти моєї вилки як спосіб документування помилок, хоча я вже маю виправлення для них. Це гарна ідея? Як мені взяти участь у поєднанні проблеми, прихильності та злиття для управління? Якщо я зверну запит на витяг за течією, чи з'явиться також моя проблема вище за течією чи буде втрачено посилання на документацію? Я не можу відкрити проблему проти репо за течією (немає вкладки випуску).

  4. Який найкращий спосіб надати кредит другому автору вилки за ідею його, яку я хочу використати? Я не можу точно використовувати його код, тим більше, що його зміна застосована до старої версії висхідного потоку і не сумісна з іншими моїми змінами, як є. Але я хочу використовувати цю ідею і хочу дати кредит там, де належить кредит. Чи повинен я просто посилатись на його репо (або профіль або конкретну комісію) у своєму повідомленні про вчинення?

  5. Який етикет стосується зміни файла readme та DocBlock у верхній частині основного файлу? Чи добре вносити зміни, додавати моє ім’я, додавати посилання на моє репо та демо, видаляти посилання на оригінальну демонстраційну версію (оскільки моя вилка виявиться несумісною з оригіналом)? Звичайно, я залишу оригінальне ім’я автора та інформацію про ліцензію. Для запису це ліцензія під ліцензією MIT.

Як сольний розробник, який ніколи не використовував VCS, я звик переписувати історію . Я перфекціоніст і люблю, щоб речі були акуратними та охайними. Ідея записаної історії змушує мене трохи нервувати, і я хочу зробити це правильно з першого разу . Я створив нове репо, з яким можна грати / вчитися, але я прагну перейти до налаштування віджета інтерфейсу jQuery UI, щоб я міг рухатися далі зі своїм проектом.

Відповіді:


15
  1. Правильно: потяг-запит пов’язаний із відділенням вашого сховища. Якщо ви змінюєте філію, ви також змінюєте те, що подаєте як запит на виклик.

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

  2. Зробіть запит на зміну пробілів! Виступаючи як хтось, хто інколи підтримує, я люблю такі типи запитів: я їх схвалюю, чи ні, і їм потрібно небагато часу на обробку.

    Що ви також можете зіткнутися, це те, що обслуговуючий персонал не погоджується з вашими змінами пробілу! Отже, будьте обережні ..

  3. Хм .. Не ясно, чого ви тут намагаєтеся досягти. Це звучить як надмірна документація і не така гарна ідея - можливо, ви можете уточнити, чому б ви хотіли це зробити?

  4. Посилання на його репо в повідомленні про вчинення (або навіть у коментарі до коду) - це чудовий спосіб надати кредит. Але будьте обережні - чітко поясніть, що ви дякуєте йому за ідеї, а не за його код. Якщо ви скопіювали код, то я надішлю його електронною поштою, якщо тільки не зрозуміло, яку ліцензію він використовує для свого коду. Якщо ліцензування чітке (і це ліцензія, що відрізняється від сховища, до якого ви подаєте зобов’язання), вам потрібно додати іншу ліцензію у своєму тяглому запиті, а також згадати про це у своєму повідомленні про запит.

  5. Це дійсно гарне запитання і відрізняється залежно від того, з ким ви спілкуєтесь. На мою думку, ви ніколи не повинні додавати своє ім’я до будь-якого комітету чи коду, який ви робите. Основна причина полягає в тому, що він передбачає "право власності та відповідальність за код" - це може заважати іншим змінювати код, оскільки "це ваше". Але зараз ми вступаємо у величезну дискусію про природу відкритого коду, тому я зупинюсь тут і скажу - запитайте у керівника проекту або просто зробіть це і подивіться, на що його реакція.

  6. Ви можете переписати (свою локальну, ще не опубліковану) історію за допомогою GIT! Дізнайтеся команду відновлення git - це одна з основних причин того, що я люблю git. Це дійсно погана ідея (сила) поштовх переписаних коммітов / історію в загальному сховищі (GitHub, наприклад). Потім це буде затято з репозиторіями, які мають інші розробники - їм доведеться робити складні справи, коли витягувати зміни (переписана історія).

[# 6: Дякую @toxalot!]


Для №6, так, ви можете переписати історію, але лише краєзнавчу історію. Після того, як його підштовхнуть до публічного репо, дуже погана ідея переписувати історію.
токсалот
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.