Разветвление TFS и объединение решения MVC, состоящего из нескольких проектов

Question

У нас есть решение MVC / C#, состоящее из нескольких проектов (Data, Service, Model et c). Началась жизнь в TFS, сохраненная в одной ветке DEV. Затем мы создали ветку Main и поместили этот проект в Main. Затем мы создали новую ветку DEV (task-1271) из Main, чтобы мы могли выполнить некоторые улучшения. Это было выпущено и слито обратно в Main. Затем мы создали новую ветку DEV (task-1316) для дальнейшего набора улучшений. Я заметил, что проект Data указывал на dll проекта Data (папка debug / bin) в предыдущей ветке DEV (task-1271). Это вызвало проблемы, так как при запуске миграции не происходили изменения модели. После большого напряжения мы в конечном итоге получили возможность подобрать изменения модели для миграции. Теперь я не хочу возвращать проект в DEV, поскольку он, похоже, все еще указывает на предыдущую папку задач. Я не хочу обновлять две ветви DEV (если это так и будет).

Не будет ли это происходить каждый раз, когда мы возвращаемся в Main? Это будет иметь ссылки в той или иной форме на предыдущие папки веток DEV? Есть ли недостаток в этой стратегии TFS? Есть ли шаги, которые необходимо выполнить при слиянии и разветвлении решения DEV?

Большое спасибо!

Answer 1

@ Джейсон, я настоятельно рекомендую, чтобы файлы (например, dll), являющиеся продуктом построения вашего c# проекта, , а не , были проверены в вашей системе управления версиями ( VCS). Это считается лучшей практикой при использовании any VCS. См. Концепции управления версиями и передовые практики Майкла Эрнста, в частности раздел под названием Не фиксировать сгенерированные файлы .

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

Еще одна важная вещь - это использование тщательно разработанного потока. для ветвления и слияния с вашей VCS. В Интернете много обсуждают эту топику c, и люди склонны к мнению о своей любимой модели потока VCS. Две очень популярные модели, которые вы можете рассмотреть, это Gitflow и GitHubflow.

Для Gitflow я рекомендую исходное сообщение Винсента Дриссена, Успешная Git модель ветвления или Atlassian Gitflow Workflow ).

Для GitHub Flow , Я бы начал с руководства GitHub Понимание потока GitHub ).