Рабочий процесс Git в контексте нескольких пакетов юнит-тестов

Question

Мне любопытно, что люди используют для тегов юнит-тестирования и памяти в git.

Например, я периодически запускаю свой код C ++ через valgrind, drd и helgrind.

Я заставлю тег с mem_ok , drd_ok и helgrind_ok , если они пройдут.

Конечно, недостаток в том, что я потеряю все свои исторические теги.

Полагаю, альтернативой является их нумерация (вместо использования силы), например mem_ok_1 , mem_ok_2 , mem_ok_3 и т. Д. ... ... возможно Я должен написать скрипт для нумерации моих тегов?

Что в настоящее время делают разработчики для достижения такого рода функциональности в git?

Потенциальное решение [использует ветви вместо тегов]

Предположим, у меня есть следующие ветки:

• master коммиты должны пройти google-тест, valgrind, drd, helgrind
• нестабильно коммиты должны пройти google-test

Я думаю об этом виде рабочего процесса (M для master , U для unstable )

M1 -> U1 (branch off M1)
      U2 
      U3 
M2 <- U4 [merge]
      U5 
M3 <- U6 [merge]

В U2, U3 и U5 коммиты просто проходят google-тест: у меня нет времени на valgrind, drd, helgrind. Я объединяю U4 и U6 с M2 и M3 после того, как проверил, что все тесты (включая valgrind, drd, helgrind) прошли.

Часть, в которой я запутался, заключается в том, что когда я объединяю U4 с M2, нужно ли мне снова разветвляться или я могу просто продолжить работу с U4 для фиксации U5, U6 и т. Д ...?

Другими словами, мне нужно только перейти от мастера к разработке один раз в начале с этим рабочим процессом, правильно?

Answer 1

Git-теги на самом деле не предназначены для того, чтобы их можно было ставить на множество таких коммитов.Вместо этого я бы предложил интегрировать ваши тесты valgrind и т. Д. В рабочий процесс, а не в вашу ветку.Если вы уверены, что ваши коммиты будут успешно скомпилированы, вы можете автоматически запустить свои тесты, и, если они пройдут, вытащите из development до passed-unit-test - задание cron или подобное, если время, затраченное на запуск тестов, является проблемой,

Вы можете использовать git hook, чтобы запретить нажатия в ветку passed-unit-test, если не пройдены модульные тесты.

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

---

Редактировать:

Другими словами, мне нужно только один раз перейти от мастера к разработке в начале этого рабочего процесса, верно?

Да.development сворачивает в master, master только выталкивается в development в начале (и, если применимо, , если естьисправления - это может не относиться к вам, хотя).

Более подробное объяснение и обоснование : Я бы использовал рабочий процесс, основанный в значительной степени на потоке Nvie Git Flow .(Соответствующие сценарии расположены здесь ).Это достаточно хорошо используется , и об этом рабочем процессе написано множество материалов, таких как this (jeffkreefmeijer.com) и this (vimeo.com),если вы хотите получить четкое понимание методологии и обоснования рабочего процесса.Этот тип рабочего процесса дает вам сразу несколько очевидных преимуществ:

• У вас есть очевидная ветвь "выпуска" (т. Е. master).Это решает ваши сомнения относительно стратегий слияния.
• Весь рабочий процесс основан на получении features слияния в master через release candidate ответвления - слот в соответствующих тестах концептуально прост.

Итак:

Часть, в которой я запутался, заключается в том, что, когда я объединяю U4 с M2, я должен снова разветвляться или я могу просто продолжать работать с U4commit U5, U6 и т.д ...?

Предполагая, что вы работаете с моделью с двумя ветвями, подобной Nvie Git Flow, что-то вроде этого будет работать:

M    
| \
|  U // Branch Unstable off Master to begin with. 
|  |
|  U1 // Finish commit series between U and U1; commit to Master
| /|
M1 |
|  U2 // Finish commit series between U1 and U2; commit to Master
| /|
M2 |

-etc-

Ваша ветка разработки, которую я буду называть unstable, чтобы ответить на этот вопрос, получает ответвление master (потому что вы продолжаете разработку кода, который вы выпустили; код, который вы выпустили, т.е.«хороший» код, находится в master) в начале.

После этого master не возвращается к development.Причина этого довольно проста;master - это место, где находится ваш "хороший" код.Вы не должны редактировать этот код напрямую.(Кроме того, master является отличным местом для пометки).

Исключением для этого являются исправления ошибок;это зависит от того, насколько близко вы следуете модели Git Flow.Однако, если исправление является срочным, вы, вероятно, захотите сделать исправление при фиксации x (сломанной), а не при фиксации x+nD, где D - коммиты разработки.Однако, как только вы исправите код, вы захотите, чтобы исправление вернулось в код development;в противном случае вы просто создадите неработающий код.
Однако исправления и т. п. могут не иметь к вам отношения;модели с двумя ветвями, такой как та, которую вы вытащили, возможно, достаточно для вашего проекта.:)

Answer 2

Мои 2 цента: теги не должны использоваться для этого, и с прогрессивными числами вы получите беспорядок.

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