Branching and Team Project Guidance … looking for “your” input!

We are busy working on articles, which we are also planning to use for a refresh of the branching and team project guidance.

The list of topics we are working on includes:

  1. Advanced Branching topics

    • Feature Teams branching scenario

    • Common Code Sharing branching scenario

    • DevDiv (dogfooding) type branching scenario

    • Architecture tooling and modelling branching scenario

    • Team Project topics

          • Team Project Collection strategies

          • Team Project strategies

          • Conceptual Team Project archiving strategies

        Have you got input, strong feeling/opinions, experience or other input you can share with us in terms of these topics? If yes, please add your feedback as a comment to this post, so that we have transparency and another avenue for stirring more discussions 🙂

        … a branching scenario we are trying to avoid.
        Photo taken in Bahrain in the middle of the sandy dessert … or rather in the middle of the desert 🙂

        Comments (3)

        1. Tschissler says:

          Hi Willy,

          I'd like to have some discussion on best practices for multiple Scrum-Teams working on the same PBL and delivering one Done at the end of the sprint. How can they use branching to do Scrum of Scrum and integrating the results of the different teams. Do you think this is a interesting topic for this guide? If you are interested, I can add some experiences and ideas on this but others should add their point of view as well to get a broader coverage.

          Thomas Schissler

        2. Some ideas i have lately thought about related to Branching.

          If you have several branches and features in development, then how to minimize and optimize the complexity of merging between those branches. It is subjective, but i think there are best practices. Like merge as often as possible – which direction and why. IF you have Dev branch and two Features, then its important to merge from Dev to Feature as often as possible if the Dev branch changes, to minimize the complexity of merging back to dev later. And the other way around i guess, although sometimes the features cannot be merged to DEV unless they are complete.

          There are also best practices in merging/checkin of changes. Should be refactoring only and no logic changes at the same time. Things have to be in steps to avoid the complexity of merging between branches and checking into branches.

          I guess these dont fully qualify as advanced branching techniques, but they are valuable tips and eareas where these tips matter.

          Also Branching related to release management. I think it needs way more explanation on how to use the branches for releasing multiple versions of products while servicing them as well.

        3. fboiton says:

          I Agree with Taavi Koosaar with the usage of branching as release management option… also you could include branching to handle development, testing, staging and production. At work we use to keep in the trunk all versions released to testing environment, a tag for the production release version and a development branch. From the development branch we create new branches applying one of the branching techniques as needed

        Skip to main content