Как я уверен, вы заметили, что, просматривая в Интернете ответы на эту тему, это одна из тех вещей, где лучшим ответом является "Это зависит", и, как указывалось в большинстве ответов, это компромисс между тем, насколько просто вы хотите иметь возможность фиксировать / объединять новый код, и управлять обширной историей версий, которую вы можете легко откатить для поддержки или отладки.
Я работаю в небольшой компании, что означает, что в любой момент времени у нас может быть 3 или 4 разных версии кода на машинах разработчика, которые еще не были добавлены в репозиторий. Мы используем TortoiseSVN для нашей системы контроля версий, что дает нам возможность без особых затруднений выполнять ветвление / слияние, а также довольно просто просматривать журнал обновлений или возвращать наши локальные копии в более раннюю версию.
Исходя из вашего вопроса, я полагаю, что мы попадаем в группу разработчиков, которые всегда стараются сохранить стабильный Trunk, и мы разветвляем новый код и тестируем его перед слиянием обратно в Trunk. Мы также прилагаем усилия к тому, чтобы сохранять «снимки» каждого выпуска версии, чтобы при необходимости мы могли легко проверить более раннюю версию и пересобрать ее, не добавляя никаких новых функций, предназначенных для будущего выпуска (это также является отличным механизм для отслеживания ошибок, так как вы можете использовать более ранние версии кода, чтобы помочь определить, когда конкретная ошибка была впервые введена в ваш код, однако следует помнить, что ваше приложение ссылается на общий код, который поддерживается отдельно от вашей версии. код, вам нужно будет отслеживать это тоже!).
В хранилище он выглядит примерно так:
Когда я впервые начал работать в компании, структура нашей версии была не такой сложной, и, по моему опыту, я бы сказал, что если вам нужно что-либо отслеживать в более ранних версиях, то стоит приложить усилия что-то вроде этого вместе (как я уже говорил ранее, это не обязательно должно выглядеть точно так, пока это соответствует вашим индивидуальным потребностям), храните это хорошо документированным, чтобы все участники могли поддерживать его (альтернатива - завершение создателя «нянчить» репо, который быстро становится невероятной тратой времени), и поощрять всех ваших разработчиков следовать им. Вначале может показаться, что нужно приложить немало усилий, но вы оцените это в первый раз, когда вам понадобится воспользоваться этим.
Удачи!