Репозиторії, випуски, декілька розробників та форкінг Github - найкращі практики робочого процесу

Дивний заголовок, так, але я думаю, що я маю трохи підґрунтя для висвітлення.

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

Мені цікаво, чи є найкраща практика, щоб кожен розробник в організації роздрібнювався в сховище організації, щоб виконувати роботу з функціями / виправлення помилок / тощо. Це здається досить солідним робочим потоком (як, в основному, це робить кожен проект з відкритим кодом на github), але ми хочемо бути впевнені, що ми можемо відслідковувати проблеми та витягувати запити з одного джерела, сховища організації.

Тож у мене є кілька питань:

1. Чи підходить підхід fork-per-developer у цьому випадку? Здається, це може бути трохи зайвим. Я не впевнений, що нам потрібна вилка для кожного розробника, якщо тільки ми не представимо розробників, які не мають прямого доступу та не потребують перегляду всього коду. У такому випадку ми б хотіли запровадити таку політику лише для тих розробників. Отже, що краще? Усі розробники в одному сховищі чи роздріб для всіх?
2. Хтось має досвід роботи з інструментом концентратора, зокрема функцією "pull-request"? Якщо ми робимо fork-per-developer (або навіть для менш привілейованих розробників), чи буде функція pull-request концентратора діяти над запитами на тягу із головного сховища висхідної течії (сховище організації?) Чи має іншу поведінку?

EDIT
Я здійснив тестування з питаннями, вилами та витягнутими запитами і виявив це. Якщо ви створюєте проблему у сховищі вашої організації, відправте сховище від вашої організації до вашого власного облікового запису github, внесіть деякі зміни, з’єднайтеся з головним відділенням вашого fork. При спробі запуску hub -i <issue #>ви отримаєте помилку, User is not authorized to modify the issue. Тож, мабуть, робочий потік не працюватиме.

Чи підходить підхід fork-per-developer у цьому випадку? Здається, це може бути трохи зайвим. Я не впевнений, що нам потрібна вилка для кожного розробника, якщо тільки ми не представимо розробників, які не мають прямого доступу та не потребують перегляду всього коду. У такому випадку ми б хотіли запровадити таку політику лише для тих розробників. Отже, що краще? Усі розробники в одному сховищі чи роздріб для всіх?

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

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

Підхід fork-per-developer - дуже хороший підхід, якщо ви цінуєте огляди коду та якість коду. Приємна річ у використанні запитів на тягу - це те, що вона перекладає відповідальність з технічного обслуговування на розробника.

Розробник хоче занести свій код в основну гілку і вимагає включення.

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

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

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

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

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

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

Я переключив би вашу увагу на тестування та огляд кодів. Чи пишуть люди тести? Вони гарні? Чи зроблено огляд коду?