We have TFS 2013 only for version control, Team City for building, a Nuget server and Visual Studio 2013. Little late in the game but we haven’t set guidelines for getting code from development into a build and package management process. Git-Flow as shown below will work for most of our projects (i.e. we need only one development line). We aren’t forced into TFS but I would like to see if GitFlow can work even with TFS (note: not much prior experience with TFS instead Git). With TFS 2013+ merging a branch like release below should be possible into master? There was a restriction (I think) with pre-2013 TFS that branch merging was only possible back to it’s origin (i.e. development in the release case).

We should be able to let TeamCity drive Nuget package management when a version (note: a semantic version, http://semver.org/) changes (i.e. the round bubbles on the master and development lines). Anybody done this?

When working on a feature, release or hotfix branch it is the responsibility of the development team to set the correct version in the assembly. Only we can know if there is a major, minor or patch change. Thus only we can update the assembly information. That said when code is checked into either the master or development TFS will automatically up the change set (I think per collection). To handle merges into development or master that demand a new version do people with TFS use pull requests (if they have update 4 or is this only if the code is managed by Git)? Otherwise, there is a risk that version numbers won’t get set correctly.

My main question is really how people handle bumping versions in TFS and a builder like Team City to later on pump out a NuGet package? With a bunch of over administration?