Исходный контроль в новых проектах

Question

Я работаю над проектом сам на работе, и я знаю, что в конечном итоге его нужно будет сохранить в нашем SVN. Мой вопрос: что мне делать, чтобы сохранить его в SVN, если я начинаю с нуля? Могу ли я зафиксировать стабильные завершенные сборки или зафиксировать, только когда чувствую, что определенный модуль достигает определенного этапа?

Answer 1

Фиксируйте рано и часто. Это минимизирует шаги по разрешению конфликтов при работе в команде. Это также хорошая практика, когда вы работаете в одиночку, поэтому у вас есть история, к которой вы можете вернуться, если обнаружите, что двигались в неправильном направлении.

Answer 2

Первоначально:

Зафиксируйте то, что у вас есть в качестве начальной версии.

Вы будете часто совершать коммиты по мере развития. Вы захотите убедиться, что то, что вы делаете, является работоспособным.

Вы всегда можете проверить конкретную ревизию своего кода, и по мере достижения этапов вы также можете пометить свой репозиторий.

Как только у вас есть рабочий код:

Как только вы стабилизируете свой основной код, вы можете начать делать ветки для больших изменений. См. Мой ответ здесь для получения дополнительной информации о ветвях и транке для разработки .

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

Кроме того, если они не могут построить то, что вы делаете, это тоже тратит их время.

Когда следует соблюдать осторожность при передаче в ваш багажник:

Если у вас есть несколько разработчиков в вашем проекте, будьте осторожны, когда вы делаете коммит в транке. Совершая что-то, что не работает полностью, вы тратите время других разработчиков на проект.

Хорошо часто совершать:

Часто хорошо делать коммиты, будь то ветка или ствол, потому что ...

• Вы можете отслеживать свои изменения через журнал SVN.
• Вы можете вернуться к рабочей версии, если что-то сломаете.
• Если вы потеряете код, у вас будет резервная копия.
• Проще слиться с изменениями других людей. Если вы долго работаете с ветками, вы можете перегруппировать и объединить изменения в эту новую ветку.

Answer 3

Зафиксируйте часто и зафиксируйте все, что не нарушит вашу сборку. Под «сборкой» я подразумеваю все, что компилируется, проходит модульные тесты ... какими бы ни были ваши критерии успешной сборки.

Answer 4

Я бы порекомендовал совершать часто. Если ваши коллеги также сделают это, вам будет сложно вступать в конфликты, а контроль версий будет служить резервной копией проекта.

Я думаю, что абсолютный минимум - совершать один раз в день, и чем чаще, тем лучше! Идея состоит в том, что, если он компилируется, он может быть зафиксирован.

Для более крупных команд также может быть указано определенное время дня для выполнения фиксации (например, перед обедом, чтобы разрешить обработку автоматической сборки).

Answer 5

Фиксируйте рано и часто. Как правило, фиксируйте вещи, которые компилируются, но иногда, если вы собираетесь внести некоторые разрушительные изменения в свой дизайн, проверьте версию, чтобы вы могли вернуться к своей «последней почти стабильной» версии. Пока вы работаете соло в своем собственном хранилище, это не будет иметь большого значения; Вы не будете ни на кого влиять. Как только вы используете общий репозиторий, убедитесь, что вы изолируете свою собственную разработку от всего, что может нарушить работу других; использовать ветки.

Answer 6

Начните с вашего текущего кода, добавьте его как «первоначальный коммит».