Який потік роботи з двома людьми на проект

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

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

Чи повинні ми володіти конкретними частинами системи? Перевірка коду в? Перегляд коду?

Як ви працюєте з> 1 dev?

Я працюю в команді, яка використовує git, де 40+ розробників працюють у декількох сховищах коду (100+) у будь-який момент часу. Ми також починали з дуже мало розробників, збільшуючи розмір команди за декілька років. На початку, хоча з малою кількістю людей ви можете піти, знаючи лише мінімум git. З часом ви вдосконалите свій git fu, відкривши для себе потужні функції.

1. Вам знадобиться місце для розміщення коду. Подумайте про використання github або gitorious . Обидва вільні у використанні, але ваші сховища будуть відкритими та видимими для інших. Якщо ви хочете приватних сховищ, ви можете розмістити їх безкоштовно на github або встановити і розмістити власний серверний сервер .
2. На початку краще не турбуватися про розширені робочі процеси, які передбачають розгортання, витягнення запитів. Почати можна з використання git централізовано (здригається!). Ставтесь до розміщеної копії як до авторитетної копії вихідного коду. Давайте може викликати цей сховище upstream.
3. Один із вас закріплює весь код у локальному сховищі git та пересилає його до цього upstreamсховища.
4. Інший член команди може клонувати це сховище.
5. Набір мінімальних команд , які ви повинні будете дізнатися це clone, pull, push, add, commit, log, status, diff, branch, stash, apply, reset, format-patch, branch. Дізнайтеся більше про них з gittutorial .
6. Зараз будь-хто з вас може працювати над будь-якою частиною коду. Не хвилюйтеся, що станеться, коли ви обидва редагуєте один і той же файл. Git дійсно добре справляється зі злиттями та виправленням конфліктів.
7. Зробіть невеликі атомні доручення та запишіть гарні повідомлення журналу . Використовуйте теперішній час для журналів фіксації. Ви можете зробити будь-яку кількість комісій за вашою локальною копією, оскільки це не впливає на роботу іншої людини.
8. Коли ви думаєте, що ваш код готовий для спільного використання з іншими, опублікуйте його у upstreamсховищі. Гарна практика - завжди тягнути, перш ніж натиснути . Таким чином ви зберігаєте сховище у синхронізації з іншими змінами.
9. Повторіть кроки 7та 8.

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

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

1. Створіть набір комісій, з якими слід переглянути git format-patch. Це створить набір файлів патчів. Надішліть ці виправлення рецензентам.
2. Рецензент може застосувати патчі за допомогою git apply. Це застосовує виправлення, але не створює коміту.
3. Перегляньте код і поверніть електронну пошту із пропозиціями.
4. Повторюйте 1-2-3 до задовільного.
5. Рецензент підтверджує, що патчі можна відсунути upstream.

Я використовую для цього github та всю його функціональність. перевірте це на веб- сайті http://www.github.com/ Щоб ви могли використовувати гілки, вилки, проблеми, тягнути запити для роботи зі своїм партнером.

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

Після цього я б визначив між вами двома ролями, які ви будете грати, тобто

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

Удачі!