What are people's workflow with using TFS/VSO as source control?
-
I'm finding myself to really miss being able to move around using branches with Mercurial, or being able to pull down a fork with GIT.
Right now I'm using Shelvesets and Undo + Unshelve, but it's prone to error.
How are other people managing it.
-
@xaade We have one persistent development branch, rather than many. Things get checked into that dev branch and built to a QA environment.
Once individual items pass testing in QA, we merge the relevant changesets into our master branch and build to our User Acceptance Testing environment.
Once it passes UAT, those DLLs get deployed to production.
-
Where do you put in-progress stuff that you're working on by yourself. Do you use a shelveset then, or do you just live with it being only on your own pc?
-
@xaade I usually live with it only being on my own PC. But just because you don't have a feature branch doesn't mean you can't do frequent check-ins, as long as you're not going to break the build. The ticket/feature can have multiple check-ins, so I will do a checkin at reasonable breakpoints.
If I'm going 2-3 days without checking stuff in, my changes are probably too big.
-
@xaade A lot of places have a branch per developer that gets the latest version from master before you merge it up. I prefer not to do it that way, myself.
-
@magus Branch-per-feature usually works well. Gets a bit more awkward once a feature gets to the point where it needs multiple developers to make it work (as opposed to just having Dev B apply a polishing step after Dev A has made it work, which is a bit important when Dev A has dyslexia).
-
@dkf On my personal project, where I still get to use TFS, we just work on master. Mostly because "we" means me these days, but at most there were two of us.
-
@magus I still prefer to use feature branches these days; it gives me a checkpoint where I can think “do I really want to inflict this pile of changes on others in this form?” and I've learned enough to sometimes even answer that “no, not like that, not now” on my own. ;)
I used to work the other way, especially back on CVS and older SVN where branching was painful…
-
@dkf There's no specific reason the Git Flow method wouldn't work on TFS, is there? It's got all the necessary features.
-
@blakeyrat said in What are people's workflow with using TFS/VSO as source control?:
There's no specific reason the Git Flow method wouldn't work on TFS, is there?
It'd probably be OK, depending on exactly what bits are used. The pattern of feature branches and merges should work just fine; that works in almost everything, as long as you've got branches you'll need merges. Rebasing and squashing might be more of a problem, but I think it's OK to hate on them anyway. :D I've no idea if the offline and multiple server stuff would work; I don't know TFS nearly well enough to say one way or the other. (Multiple server only really makes sense in a DVCS in the first place; centralised VCSs don't really have the concept.)
The biggest blocker for that sort of way of working I've seen in practice was back in CVS (and before that, in RCS) where branching was stupidly expensive. I'm guessing that TFS isn't brain-damaged in that way.
-
@dkf said in What are people's workflow with using TFS/VSO as source control?:
Rebasing and squashing might be more of a problem,
Is that part of Git Flow? The workplaces I've been at that used Git Flow never used rebasing. (And I don't know what "squashing" is-- do you mean turning all your feature branch commits into a single commit when you merge the Pull Request? Never worked for a place that did that either.)
@dkf said in What are people's workflow with using TFS/VSO as source control?:
I've no idea if the offline and multiple server stuff would work;
???
What "offline and multiple server stuff" are you referring to? I think I'm lost.
@dkf said in What are people's workflow with using TFS/VSO as source control?:
I'm guessing that TFS isn't brain-damaged in that way.
No. It's probably not as fast as Git, but it's certainly not slow enough for it to be a factor. And since it does partial checkouts, you only have to tough the subset of files you actually expect to use.
-
@blakeyrat said in What are people's workflow with using TFS/VSO as source control?:
Is that part of Git Flow? The workplaces I've been at that used Git Flow never used rebasing. (And I don't know what "squashing" is-- do you mean turning all your feature branch commits into a single commit when you merge the Pull Request? Never worked for a place that did that either.)
There's many possible workflows with Git. You're correct that you don't need to use those two features. (Also, squashing is any combining of a sequence of commits into one, not just during accepting a PR, and it'd only ever really acceptable on branches that are not routinely shared between developers.)
It's entirely OK to not use either rebasing or squashing.
What "offline and multiple server stuff" are you referring to? I think I'm lost.
Features of being a Distributed VCS. They enable some patterns of working such as specialised code-review servers.
-
@dkf said in What are people's workflow with using TFS/VSO as source control?:
Features of being a Distributed VCS.
Right; but what do they have to do with using Git Flow?
-
To clear up the obvious misunderstanding between @dkf and @blakeyrat, because fun as it is to watch you talk past each other, I need to show how superior I am by explaining things
Gitflow is a type of branching workflow that doesn't really have much to do with Git the SCM. I think it was first made popular by people who implemented it in Git, but any source control with branches and merging can use it. It's pretty similar to feature branches
-
@xaade said in What are people's workflow with using TFS/VSO as source control?:
Where do you put in-progress stuff that you're working on by yourself. Do you use a shelveset then, or do you just live with it being only on your own pc?
I don't use this VCS but I do make daily backups of my work.
-
@jaloopa Huh, interesting. For some reason I thought gitflow made use of full forking of repos, and was mainly for heavy-duty open source use, or maybe for companies with many outsourced firms that for whatever reason wanted to silo their own repos.
I've always used the "feature branching" aspect of the gitflow that Atlassian talks about, though. For me, feature branching's the best way to do most projects.
Gitflow Workflow | Atlassian Git Tutorial
