0

Hi trying to implement TFS for my team (18 members).

I made two branches 1) Main branch 2) Dev branch

We are using Agile.

So there is a sprint every week. And on every Thursday i merge changes from Dev to main Branch.

Each developer works on different user story. if he completes a task and check in all changes (5 files). change set (e.g 62) is generated. But tester reported a bug while unit testing. Developer fix the error and check in 1 file. it generated a new change set (e.g 63).

Problem is when i am merging user story's change to main branch i am confused with which change set to move. (62,63....)

what i do is compare whole project. which is headache some times.

Can some one suggest better way. Or i am missing something? any blog that can help

Thanks

Fazal Wahid
  • 175
  • 2
  • 17

2 Answers2

1

If you have a single DEV branch, that implies that you should be merging the whole branch and all changes to MAIN (not cherry-picking, which is what you seem to be describing).

If you want the flexibility to merge only changesets relating to certain stories/bugs, then you should adopt a different branching pattern such as branch by feature.

Dylan Smith
  • 22,069
  • 2
  • 47
  • 62
  • Are you suggesting that i should create different branch for each user story. seems good but there are also much small fixes and changes every week (reported or suggested by clients). Yes for new development (new modules) branches but what to do for weekly fixes? – Fazal Wahid Jan 24 '15 at 07:59
  • No, he is suggesting that if you want to continue to be dysfunctional then you should at least introduce some riggor – MrHinsh - Martin Hinshelwood Jan 24 '15 at 09:34
-1

You need to change the way that you build and deliver software in order to deliver more successfully.

http://nakedalm.com/avoid-pick-n-mix-branching-anti-pattern/

What you are describing with picking changesets will consistently and continuously reduce the quality of your product.

If you implement a good definition of done and get your guys working in a team rather than independently you should have working software at the end of each sprint. Just before the Sprint review (just in time) you should merge everything from dev to main maybe using a changset as a watermark. If you have stories in your sprint that go towards features that are not ready yet then you should hide them behind feature flags and ship.

If this sounds to hard, or something that "will not work here", or you think "or product is more complicated than that", then you are likely suffering from significant technical debt and you need to pay that back untill you give your Product Owner the choice to release everything at the end of every sprint.

MrHinsh - Martin Hinshelwood
  • 23,409
  • 5
  • 46
  • 69