次の方法で共有

When would I use a Branch for Developer Scenario?

  • [アーティクル]

Question:

Any opinion on branch per developer approach? This is the first time I have come across it someplace and feel that there's just no reason too. I've been through the branching guidance and even use your article in MSDN magazine from earlier this year as reference. The development teams are offshore and not always experienced developers. I heard they want to use the developer branch as a code review area and then merge in later. Have you seen a branch by developer in practice or useful?

The short answer is if you see no reason (benefit) to adopting a specific branching pattern such as branch per developer, then don’t adopt that pattern. There is a cost to every branching strategy. But there is also a cost to not having a branching strategy that meets your needs.

Scenario One:

A team is comprised on an on-shore team and an off-shore team. During the on-shore team’s work day, they check code into an onshore development branch, which is a full child of Main. At night, they handoff their work to an off-shore team. The off-shore team is working in a separate development branch that is a full-child of the onshore team’s development The hand-off at night is a merge from the onshore branch to the offshore branch (always overwriting the target with the source if there is a conflict). In the morning, the offshore team does a handoff of their work back to the onshore team. Because the onshore team wants to review the changes done overnight by the offshore team, they will do a code review and selective merge from the offshore branch to the onshore branch.

Alternatively some teams uses shelvesets to support code reviews. The developer shelves changes and requests a code review. After a successful code review the developer will be permitted to check these changes into the development branch.

Scenario Two:

Consider this. You have a Scrum project. At the beginning of each Sprint, during the Sprint planning session, the team accepts a certain amount of work for the Sprint. Tasks (User Stories, Product Backlog Items, etc.) are moved from the Product Backlog to the Sprint Backlog. Work begins on the Sprint.

Each Sprint team member takes work from the Sprint backlog and begins work on that item. When done, the team member takes another item from the Sprint backlog. Each member of the Sprint team works in a similar fashion.

What happens if one developer, towards the middle or end of the Sprint takes on work from the Sprint backlog but is unable to complete it in time for the end of Sprint.

We will not, under the rules of Scrum, extend the Sprint until all items are done. We will also not release items (features) that are not done at the end of the Sprint. So what to do?

I presented some possible solutions at a recent Microsoft Engineering conference and again at an internal Technical Readiness conference. Some options:

· Have all developers work (check into) the same branch. At the end of each day each developer checks-in changes to the branch. At the end of the Sprint, separate the completed work from the unfinished work. Do this by cherry picking the changes for completed items as part of a merge from Development to Main.

· Have all developers work (check into) the same branch. Only check-in changes once a feature is complete. This means when a feature is complete there will be one mega check-in of all changes done in the course of implementing the particular feature. Instead of checking changes into the branch on a daily branch, shelve the changes at night (to get them onto the server) and then un-shelve them the following morning.

· Have each developer work on their own (private) branch. These private branches will be full-children of Main. At the end of each day, each developer checks in his/her changes to their private (developer) branch. When a feature is complete, the changes for that feature can be merged to Main and shared with the rest of the team. The developer begins work on the next item from the Sprint backlog. The developer can continue in the same (private) developer branch or start a new one to keep the second feature separate from the first, in the event that the second feature is not done at the end of the Sprint and needs to be held out of the release.

If you do not have a scenario similar to this, then you may not need or want separate developer branches.

Comments

  • Anonymous
    August 02, 2011
    The comment has been removed
  • Anonymous
    December 01, 2011
    Got a question not entirely related to this post (sorry!).  We have three different feature teams and work off three separate branches in TFS, merging from and back to main where appropriate.  My question is when merging from Main to a team branch, is the merge from Main on the server to the team branch locally?  Or is a latest local copy of Main needed to merge with the latest local copy of the team branch?  Thank you!  Lisa
  • Anonymous
    July 30, 2014
    Nathan, it works just fine.