робочий процес команди github - розщедритися чи ні?

Ми невелика команда веб-розробників, які зараз використовують підрив, але незабаром ми переходимо на github.

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

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

Це схоже на робочий процес, пояснений тут: https://github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow

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

Будь-які пропозиції від команд, які спробували обидва робочі процеси?

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

Занурись - ти побачиш, що це насправді чудово! Вам не потрібно занадто розщедритися (не роздрібнюйтесь для кожної зміни у кожному файлі), але ви можете роздрібнити функції та об'єднатись назад.

Подумайте про GitHub як про кілька версій, які варто вдосконалити на багатьох основних концепціях управління джерелами.

Поняття "стабільної" гілки та вилки "активного розвитку" також охоплюють багато з цих питань, якщо ви не вагаєтесь робити вилазки. : P

Ми пробували і те, і інше, з розробниками, які дуже сильно вдома працюють у svn. І якщо ви є купою розробників, які вже працюють разом і довіряють один одному права на виконання зобов’язань, вам, напевно, буде простіше просто зберегти єдину центральну репо в git і додати вас усіх як співавторів, які виконують цю репо.

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

Я б почав з єдиного центрального репо і просто деякий час працював з git. Можливо, приватна вилка виросте на вас, а може й ні. Або добре.

У git, вилка - це справді ще одна гілка. За допомогою робочого процесу fork-for-кожного-розробника ви ефективно вимагаєте, щоб кожен розробник мав публічну (віддалену) гілку для відстеження змін у їх розвитку. Це корисно для можливості безпосередньо співпрацювати між розробниками (одноранговими). У будь-якому випадку вам доведеться об'єднати зміни кожного розробника в центральний репо, тому я не думаю, що це додасть великих витрат.

Для невеликої команди з 2-3 розробників добре використовувати розгалуження на репо, щоб керувати виправленнями та функціями. Проблема полягає в тому, коли у вас більше розробників, а також більше функцій та виправлень, які розробляються.

Коли це так, у вашого головного репо в Github буде сотні відділень; деякі будуть старими і забутими і невбитими.

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

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

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