tl; dr - Здається, що пора піднятися до великих ліг. Нанесення помади на свиню не робить її гарнішою, якщо тільки ви не займаєтесь такою штукою ...
Проблема людей
Перший випуск - це синхронізація фіксації. Якщо у вас є кілька людей, які працюють над одним кодом одночасно, вам потрібно лише одне правило, щоб запобігти проблемам:
Rule 1: Always pull before you merge/rebase
Що стосується DVCS, важко вносити зміни до віддаленого відділення (тобто основного сховища) і дуже легко вносити зміни до локальних. Кожна людина несе відповідальність за те, щоб власні доповнення до коду без проблем вкладалися у ціле ціле. Якщо 2 людини не здійснюють в один і той же час, ви не повинні відчувати. Доступ до початкового / віддаленого майстра повинен бути обмежений лише кількома розробниками, і вони повинні витягувати зміни від інших розробників за допомогою віддалених гілок відстеження.
Проблема з кодом
Звідки ви знаєте, що внесені вами зміни не порушують код?
Проста відповідь ... Напишіть тести, щоб довести, що їх немає. Якщо ви ігноруєте школу думок TDD (Test Driven Design), вся суть тестів полягає в тому, щоб додати рівень перевірки, який дозволяє вам змінити код, не порушуючи його.
Rule 2: Don't make assumptions, write proofs (ie tests).
На додаток до цього, перед тим, як натиснути на початковий / віддалений майстер, слід запустити повну гаму тестів.
Зберігайте свої зобов’язання якомога менше і стисліше. Таким чином, якщо вам потрібно буде відмовитись від зміни, яка виникла щось пізніше, ви позбавитесь від необхідності повторно реалізувати частини, які не порушили код.
Спочатку вам може знадобитися деяке організаційне переструктурування
Якщо вищезазначені рішення не можуть бути легко застосовані, мабуть, є деякі проблеми зі структурою розробки, які потрібно вирішити спочатку.
Власник проекту повинен бути воротарем. Якщо є проблеми синхронізації з фіксацією, можливо, занадто багато людей, які мають доступ до здійснення. Навіть у таких масштабних проектах, як Linux ядро, лише кілька розробників мають доступ до початкового / віддаленого головного сховища. Насправді існує кілька рівнів сховищ для управління комітами. Замість одношарової моделі фіксації, де всі підштовхують свої зміни до походження, в ієрархічній моделі є воротарі, які втягують зміни та перевіряють їх якість перед включенням у проект. Ієрархічна модель фіксації може масштабуватись набагато більше і ефективніше, ніж одношарова модель, не приносячи шкоди якості.
Для дияволів, які не отримують доступу, вони повинні навчитися створювати власні гілки віддаленого відстеження (git та gitorious корисні для цього), так що чорти, які роблять має доступ для фіксації можна легко витягти / об'єднати філії в початок координат. Якщо зміни невеликі, патчі працюватимуть так само добре.
Можливість витягнути зміни перед тим, як зробити злиття / ребазування, передбачає, що ви не розвиваєтесь у вашій місцевій головній галузі. Найпростіший спосіб впоратися з цим - це зробити первинний потяг, перш ніж почати кодувати, а потім виконати всю свою роботу на цій гілці. Важкий спосіб - це розгалужити його безпосередньо перед об'єднанням і відкотити майстра.
Визначте стиль кодування для проекту в цілому і змусьте розробників слідувати за ним. Розробники розробників повинні писати код, який відповідає стандартам / нормам проекту, щоб мінімізувати очищення. Стиль кодування може бути великим бар'єром его у відкритому проекті. Якщо не встановлено жодного стандарту, кожен буде кодувати у своєму бажаному стилі, і база коду стане дуже потворною дуже швидко.
Міф про «Міфічний місяць людини»
Вірите чи ні, більші / більш успішні проекти з відкритим кодом не ведуться як демократія. Вони управляються як ієрархія. Заявляючи, що проект не може ефективно перерости понад 8-10 розробників, наївно. Якби це було правдою, то таких мегапроектів, як Linux Kernel, не існувало б. Більш глибоке питання полягає в тому, що надання доступу до всіх лише робить ефективне спілкування занадто важким для обробки.
Проблему міфічного чоловіка місяця насправді можна подолати. Вам просто потрібно запустити свій проект, як військовий. В ієрархії існує багато рівнів, тому що загальновідомо, що окремі люди справді ефективні лише в управлінні комунікаціями з жменькою людей. Поки жодна особа не несе відповідальності за управління роботою понад 5-7 людей, система може масштабувати нескінченно.
Це може обмежити найкращих / досвідчених розробників у більшій інтеграції та розробці / плануванні вищого рівня, але це не погано. Частина розширення масштабів полягає в тому, щоб вирішити, що проект потребує довгострокового плану. Людям найвищого рівня, які мають найбільші інвестиції (час також є ресурсом) у майбутньому, проекти повинні бути доручені приймати великі рішення.
Приємно чути про проект з відкритим кодом, що переживає все біль. Вітання та удача.