How can we improve Team Services?

Merge by Workitem

Allow users to select WorkItems and related changesets on Merge screen. Probably Merge candidate WIs will be required.

764 votes
Sign in
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Oğuz BayrakdarOğuz Bayrakdar shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


    Sign in
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      • JesseJesse commented  ·   ·  Flag as inappropriate

        Here's how I want to use merge by work item:
        Dev, QA, and Release branches in code. Each of these is set up to automatically deploy to the corresponding server environments. I gate merges to QA by work item. This way devs are free to get things into the Dev server build as needed. Only things that pass QA get merged by work item id to the release branch and thus bundled with the end of sprint deployment.

        Without merge by work item, this process is painful and arguably impossible from a practical perspective.

      • KyleKyle commented  ·   ·  Flag as inappropriate

        @Sarah Adler

        You can merge by Work Item in TFS/VS 2012. If you track the work item (like you can a changeset) you can use the visualisation to move it onto the next branch. see

        Only downside is you cant do this on multiple work items at once and also reporting/managing which branch(es) have which work items is non existant

      • Sarah AdlerSarah Adler commented  ·   ·  Flag as inappropriate

        Our team works by work item ids and we want a want to be able to say workitem ids 123, 234, 345 are going into build 7.8.2013.1. If we had merge by workitem we could easily merge all of the changesets related to those workitems and ensure the bulld contains the workitems and not have to translate workitems into changeset ids.

      • Rolf KristensenRolf Kristensen commented  ·   ·  Flag as inappropriate

        What is this madness, how can a version control system not keep track of what workitems has been released to production. And now I'm out of votes, because this **** VS2012 Team Explorer is a complete disaster. Arghhh

      • LinLin commented  ·   ·  Flag as inappropriate

        If you're not a Build Engineer you'll never understand how beneficial this feature would be. Unforntunately there are too few of us to really be heard. If I thought my congressman could help, I would write him.

      • Daniel MackayDaniel Mackay commented  ·   ·  Flag as inappropriate

        As merges can only currently be done at the changeset level, this encourages NOT checking into TFS regularly. Instead of doing many smaller check-ins a developer will instead hold back and do fewer but larger check-ins so that all the work is in a single changeset. This makes merging easier, but discourages regular check-ins. :-(

      • Mattias SköldMattias Sköld commented  ·   ·  Flag as inappropriate

        @Matthew Mitrik - Ive seen several teams working with Stories and task during a sprint, in the dev branch, and by the end of the spritn after story approval, they merge each approved Story into the main branch. Doing so takes a lot of time and effort away form productivity.

      • Paulo FerroPaulo Ferro commented  ·   ·  Flag as inappropriate


        This actually is one of the most time-saving features lacking in the product.
        The real cases can be any, the customer asks for a full version and there goes a full merge, or the customer gives a list of which features (Work Items) would like to see in the new version.

        The challenge of merging is not much, I think, the problem is that WIs are associated to the original branch and there will probabily be only one changeset with all changesets merged, so all WIs will be associated with this WI. From my point of view there should always be kept the original chengeset/WI association, if I have to do another merge of such WI there should only be the original changesets being merged. Even if it makes me merge allways from the original branch to the new destination branch or something.

        I'm not sure if my answer was clear but hope it helps in any way.

        Best regards and thanks for the great product

      • Oğuz BayrakdarOğuz Bayrakdar commented  ·   ·  Flag as inappropriate

        Hi Matt,

        Our developers are tracking thair daily jobs with WIs and yes they want to merge their features instead of changesets. For example two or three developers can code for a single feature. At the end of feature development they will have a single WI with 3 or more change sets for feature. Than they will want to merge single feature WI instead of 3 or more change sets.


      • Matthew MitrikMatthew Mitrik commented  ·   ·  Flag as inappropriate

        This is something that we're tracking on our product backlog, and I hope to make a more holistic improvement to the merge experience in the future. The current wizard approach is very limiting, and in order to better facilitate more advanced features like merging by work item and cherry-pick merging, we need something better.

        I'd love to hear examples of how people would like to use merge by work item. Would you use it to merge all of your features? Or would it be used only when porting select changes (i.e. bug fixes)?

        Program Manager | TFS Version Control

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        IBM Clearcase / Clearquest is suporting this feature for over years. And Jazz will too.

      Feedback and Knowledge Base