Какие руководства или стандарты вы используете для контроля версий в вашей команде?

Question

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

Я предполагаю, что будут такие вещи, как;

• Часто совершайте (по крайней мере, каждый день / неделю / собрание и т. Д.)
• Версии выпуска всегда делаются из основной ветки
• Перед выпуском новая ветка будет создана для тестирования и помечена как таковая. только исправления ошибок с этого момента. Окончательный выпуск этого будет помечен как таковой, и исправления ошибок объединены обратно в ствол
• У каждого разработчика будет публичное репо
• Новые функции должны получить собственную ветку

Очевидно, что многое из этого будет зависеть от того, какую VCS вы используете и как вы ее структурировали.

Похожие вопросы;
рекомендации по именованию веток git
Существует ли стандартное соглашение по присвоению имен тегам git?

Answer 1

В текущем месте, где я работаю, система контроля версий является одной из самых передовых и зрелых. Вот как мы делаем.

У нас есть нечто, называемое "основной" ветвью, которая является базой кода, которая будет в производстве. Обратите внимание, кодовая база в одной огромной гигантской структуре. Скажем, если придет новый проект, мы должны сделать предварительную оценку и закажем неделю релиза. Теперь мы должны начать работать над этим. Итак, мы отрезаем ветку от main, называемую Feature Feature. Команда или группа разработчиков продолжают работать в этой конкретной функциональной ветви. Обратите внимание, что в основной ветви одновременно будет много срезов ветвей элементов.

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

Как только код запущен в производство и скажите, что мы столкнулись с некоторыми ошибками, мы вырезали ветку main, называемую веткой с исправлением ошибок. Сделай все изменения. И объединяя его обратно в главное; всегда следует за процессом предварительного выпуска / зеленой отметки времени. Это неизбежно.

Re-база. Итак, сначала я сказал, что мы бы забронировали, когда наша функциональная ветвь должна быть завершена. В течение этого периода будет много обновления кода на главной. Таким образом, очень важно, чтобы вы продолжали обновлять текущую ветку функций, чтобы синхронизировать ее с основной. Для этого выполняется процесс, называемый rebase. Это похоже на получение последнего кода из main, чтобы вы не работали в ветке, которая так устарела. В моей текущей организации ребаз будет запускаться каждые 2-3 недели, хотя политики рекомендуют 1 неделю.

Более интересные функции: скажем, я сейчас работаю над так называемой веткой Feature и хочу получить код от одной из других команд, которые также работают в своей собственной ветке Feature (этот сценарий, хотя кажется, встречается редко). Для этого мы изменим нашу конфигурационную спецификацию (ClearCase - наша система контроля версий), чтобы она указывала на те файлы, которые требуются из другого проекта. Можно использовать LATEST или TIMESTAMP для извлечения этих файлов из другой ветви функций.

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

Answer 2

Только один стандарт:

1. Проверка при внесении изменений приведет к удару.

Answer 3

мои 'cvs' - это TFS, так что принимайте их за то, что они стоят.

Если кто-то нарушает сборку, применяется правило пончика (приносит коробку пончика на следующий день)

Вы часто упоминали о совершении, исходя из дня, недели или встречи. Разве эта система не вводит неполный код? После проверки кода фиксация может быть более стабильной.

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

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

Построение подобной функцией может повысить производительность, поскольку QA может начать тестирование уже на следующий день, вместо того, чтобы быть заблокированным из-за поломки сборки, пока она не будет исправлена ​​позже во второй половине дня, или даже отодвинута назад на следующую, только чтобы увидеть другую подобную проблему. 1011 *

CVS хорошо известен, но если бы я начинал команду разработчиков / проект, я мог бы рассмотреть возможность взглянуть на Jira Studio

http://www.youtube.com/watch?v=2w2uN3c8pfA http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=related

Answer 4

Только регистрируйте (или продвигайте, в зависимости от вашего инструмента) рабочий код в «главную» ветку / поток / депо / репозиторий (выберите собственное определение «основной»). Эта «основная» ветка должна оставаться компилируемой и тестируемой всегда.

Answer 5

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

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

Держите ваши сообщения коммитов четкими и точными, это очень поможет вам, когда вы вернетесь к своему коду.

Небольшая ошибка с git: когда вы разветвляете ветку, она разветвляется от ветви, на которой вы находитесь, а не от мастера. Это очевидная вещь, но всегда проверяйте текущую ветвь перед тем, как создавать новую ветвь.

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