Наша компания создает соглашение об именах для ветвей и тегов SVN, и я не уверен в том, что я использую только дату или номер сборки в именах ветвей/тегов.
Мне кажется, нам нужны имена, которые дают большее определение того, что представляет этот путь, какие усилия предпринимаются и т.д.
Что вы думаете/используете?
Я всегда префикс тегов (и обычно ветки тоже) с датой в формате YYYYMMDD, а затем описание цели тега или ветки.
например, 20090326_Release_v6.5 или 20090326_Post_Production_Update
Это, конечно, стандартная иерархия соединительных линий/тегов/ветвей.
Префикс даты гарантирует, что все теги или ветки отображаются в порядке создания, что гораздо более полезно, чем просто сортировать по описанию, если вы просматриваете большую папку с тегами. Вы видите временные рамки того, когда и почему они были созданы (например, мини-сообщения журнала).
Хорошо, ветвление довольно открыто, так как существует несколько разных видов ветвей, именование их может быть очень различным.
Стоит вспомнить, что дает вам контроль источника. Имена тегов не просто "v1.4", это "/CashCowProject/tags/v1.4". Именование тега "/CashCowProject/tags/CashCowProject-v1.4" немного избыточно, что еще это будет?
Контроль версий также дает вам полный доступ к датам и времени создания тегов. Элемент управления ревизией также дает вам сообщения фиксации, которые вы должны использовать, особенно первую строку.
Учитывая всю эту информацию, нетрудно собрать простой взгляд, дающий вам всю необходимую информацию, исходя из последовательных и соответствующих источников, таких как:
CashCowProject
v1.4 - 26 March 2009 : With Added whizzbang (more)
v1.3 - 13 February 2009 : Best graphics! (more)
v1.2 - 01 January 2009 : Upgraded security (more)
Единственное, что имя тега действительно полезно здесь, это номер версии. Если вы пытаетесь поместить всю информацию в имя тега, это немного многословно, и я уверен, что это будет не так хорошо.
Для ветки функции назовите ее после того, что делается. Например, я переместил наш ORM из LINQ в SQL в NHibernate и создал ветвь под названием "NHibernate". После того, как вы закончите ветку и объедините ее обратно в багажник, вы можете удалить ветку, чтобы сохранить конфликты имен в будущем. Если вам действительно нужно получить ветку, вы можете просто вернуться в историю и восстановить ее.
Если у вас есть номера истории/цитаты/задания, относящиеся к ветке, я бы добавил его к имени ветки, например. "NHibernate_429", поэтому вы можете легко ссылаться на него в своей системе слежения. Тем не менее, я всегда бывал с англичанами в первую очередь тем, что люди более реалистично будут ссылаться на него, когда он находится в процессе развития.
Для таких вещей, как теги, трудно сказать, что вы хотите делать, поскольку это зависит от того, что именно вы отмечаете. Если вы помечаете выпуски, я бы использовал "Release X.X.X.X" или что-то простое. Вы действительно не заботитесь о том, какая дата или номер сборки были, когда вы оглядываетесь назад на конкретную версию в качестве примера.
Все наши задачи разработчика входят в систему отслеживания ошибок. Эта система отслеживания ошибок содержит идентификаторы, связанные с каждой задачей.
Итак, для имени ветки любой задачи мы используем:
ticketId_TicketSubject
Когда ветка содержит несколько идентификаторов ticketIds, мы просто объединяем их в название ветки:
ticketId1_ticketId2_Description
Таким образом, если вы находитесь в билете и хотите узнать, какую ветку нужно построить, вы можете легко найти его. Точно так же, если вы хотите найти билет со своей сборкой ветвей, вы также можете легко найти его.
Для тегов мы помечаем его номером версии.
Что касается расположения каждой ветки. У нас есть иерархия верхнего уровня:
/branches
/tags
/trunk
Затем все наши продукты/проекты идут под каждым из них внутри своих собственных подпапок.
/trunk/project1/
/branches/project1/TicketId_Description
Что мы используем (в основном следуя принятому соглашению):
projectName
|
--trunk
|
--tags
|
--branches
В багажнике у нас есть основной багажник.
В тегах мы отмечаем каждую версию (как внутренние, так и тестовые версии и выпуски клиентов). Там мы просто используем номер версии в качестве имени тега.
Под ветвями мы имеем одну ветвь для каждой выпущенной нами основной версии (в нашем случае результат одной итерации XP). Они называются главной версией ( "v5.03", "v6.04" ). Кроме того, у нас есть внутренние ветки для крупных изменений или специальных версий. Там именование является свободной формой, и имя должно сообщать людям, что представляет ветвь. Примерами будут "workaround_customerA", "module_x_reorg" и т.д.
Мы даем нашим ветвям версию ".X", где теги имеют число.
Например, веткой будет Foo-1.2.3.X, а тегами будут Foo-1.2.3.1, Foo-1.2.3.2 и т.д.
У нас также есть специальный тег Foo-1.2.3.0, который создается, как только ветвь создается из соединительной линии, перед любыми изменениями. Таким образом, мы можем в любой момент разделить ветки и теги на начальное состояние (так как через пару дней сундук, вероятно, будет другим). Эта практика упростила слияние, и она выясняет, какой код изменился в отрасли намного проще.
лучше:
<projectname>_<Year>_<minor>_00
как:
XYZ_14_01_00