Лучшие практики контроля вариантов

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

Обсуждение кодекса поведения не должно быть длительным, оно может быть очень кратким; пока все находятся на одной странице о том, как использовать репозиторий, совместно используемый программистами в команде. Если вы хотите использовать более продвинутые функции в Mercurial, такие как выбор вишни или очереди исправлений, попробуйте использовать их, чтобы это не повлияло на членов вашей команды негативным образом, например, перебазирование в общедоступном репозитории.

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

Когда и как часто мне следует совершать коммит? Будет ли это работать после любого серьезного изменения? Когда я закончу на ночь? Только когда он достигнет следующей стабильной итерации? После каких-либо исправлений?

При работе с командой существует несколько подходов, но общее правило - фиксировать рано и часто . Основная причина, по которой вы должны часто коммитить , - это упростить обработку конфликтов слияния .

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

Есть несколько исключений из правила частой фиксации, одно из которых возникает, когда у вас есть критическое изменение . хотя, если у вас есть возможность фиксировать локально (что вы делаете в Mercurial и git по сути), вы можете фиксировать критические изменения. Пока вы исправляете все, что сломалось, вам следует отправить это вверх по течению в общий репозиторий, когда вы исправите свое собственное критическое изменение.

Могу ли я разветвляться, когда я хочу, скажем, изменить макет меню, а затем снова слиться? Я должен ветвиться?

Есть много стратегий ветвления на выбор (есть статья Streamed Lines 1998 года, в которой есть исчерпывающий список шаблонов стратегий ветвления ) и когда вы делаете их для себя, это должна быть открытая игра для вас самих. Однако при работе в команде лучше открыто обсудить с командой, нужно ли вам разветвляться или нет. Всякий раз, когда у вас возникает желание разветвляться, вы должны задать себе следующие вопросы:

• Будут ли мои будущие изменения нарушать работу других?

• Будет ли моя команда иметь прямое негативное влияние на изменения, которые я буду делать до тех пор, пока Я закончил?

• Мой код не используется?

Если ответ положительный на любой из приведенных выше вопросов, вы должны , вероятно, ветвиться публично или оставить его себе (поскольку вы можете сделать это в Mercurial несколькими способами). Сначала вы должны обсудить со своей командой, как выполнить всю операцию, чтобы увидеть, есть ли какой-либо другой способ сделать это, и если вы собираетесь объединить свои изменения обратно, иногда в игре есть факторы, в которых нет необходимости ветвь (это в основном связано с модульностью кода).

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

В качестве примечания: вы ведь пишете хорошие комментарии к коммитам, не так ли? ВЕРНО!? Хороший комментарий коммита обычно сообщает , почему было сделано это конкретное изменение или над какой функцией работает коммиттер, вместо невзрачного комментария типа «Я сделал фиксацию». Это упрощает для того, кто обрабатывает большой конфликт слияния, выяснить, какие изменения строки можно перезаписать, а какие оставить, просматривая историю изменений.

Время компиляции или, скорее, время сборки иногда играет важную роль в обсуждении ветки, которое у вас может быть. Если у вашего проекта медленное время сборки, может быть хорошей идеей использовать промежуточную стратегию в ваших ветках. Эта стратегия учитывает, что все разработчики должны интегрироваться в «основную ветку», а одобренные изменения имеют повышенный уровень (или «продвинутый») на следующий этап, например, на стадии тестирования или выпуска. Классически это иллюстрируется именами тегов для программного обеспечения с открытым исходным кодом, например:

main -o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-> ...
         \           \              \
test      o-----------o--------------o---------> ...
           1.0 RC1     \ 1.0 RC2      2.0 RC1
release                 o----------------------> ...
                          1.0

Суть в том, что тестировщики могут работать, не прерываясь программистами, и что существует известная базовая линия для тех, кто занимается управлением выпусками. В распределенном управлении версиями разные строки могут быть клонированными репозиториями, и это может выглядеть немного иначе, поскольку репозитории совместно используют граф управления версиями. Однако принцип тот же.

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

Однако в игру вступает совсем другое - время, необходимое для развертывания сайта. По моему опыту, инструменты контроля версий действительно плохо справляются с управлением активами. Работа с художественными активами, которые в сумме составляют до нескольких ГБ, обычно является огромной проблемой в Subversion (особенно в Mercurial). Ресурсы могут потребовать от вас обработки их другим способом, который требует меньше времени, например, помещением их в общее пространство, которое синхронизируется и резервное копирование выполняется традиционным способом (художественные активы обычно не обрабатываются одновременно, как с файлами исходного кода).

В чем разница (только для меня, как разработчика-одиночки) между ветвлением, последующим слиянием, клонированием репозитория и его возвращением?

Концепции ветвления и сохранения удаленных репозиториев сейчас ближе, чем с инструменты централизованного контроля версий. Вы могли почти считать их одним и тем же. В Mercurial (и в git) вы можете "ветвиться" одним из следующих способов:

• Клонирование репозитория

• Создание именованной ветки

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

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

Поскольку просмотр веток является немного необычным для тех, кто привык к прямой линии коммитов, опытные пользователи знают, как манипулировать своими версиями, поэтому история версий "чиста", например, выбор вишни или перебазирование . На данный момент git docs довольно хорошо объясняет rebase .