Как проходит работа с двумя людьми над проектом?

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

Он задал очень хороший вопрос, который был «как это будет работать». Что-то, о чем я мог только теоретизировать, поскольку я никогда не программировал с кем-то еще. Не могли бы вы посоветовать мне лучший рабочий процесс. Мы используем Git.

Должны ли мы владеть определенными частями системы? Проверка кода в? Обзор кода?

Как вы работаете с> 1 разработчиком?

Я работаю в команде, которая использует git, где более 40 разработчиков работают над несколькими хранилищами кода (более 100) в любой момент времени. Мы также начинали с очень немногих разработчиков, увеличивая размер команды в течение нескольких лет. В начале, хотя с немногими людьми, вы можете узнать только минимальный мерзавец. Со временем вы улучшите свое мерзавец, открывая для себя мощные функции.

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. Собираетесь ли вы писать функциональность кода в тандоме, или один человек собирается исправлять ошибки, а другой продолжает работу с функциями.
2. Хотите ли вы создать набор базовых стандартов кодирования, таких как положение скобок, именование переменных закрытого члена, соглашение о присвоении имен переменных и методов (CamelCase и т. Д.)
3. Как часто вам нужно регистрироваться. Я бы посоветовал хотя бы раз в день убедиться, что вы оба видите, что другой делает особенно рано. Хотя всегда проверяйте перед регистрацией, что код может быть собран.
4. Он босс, но вы собираетесь быть программистом?

Удачи!