The basic git branching workflow is this:

1. Pick a base branch
2. Make a new branch from the base to keep your changes on
3. Make the changes
4. Do whatever testing and review you need
5. Merge the new branch into the base branch
6. Optionally:  delete the new branch

So let’s say that you have the following setup at the start of sprint S:

• Team 1 has branch team-1-development pointing to current-release
• Team 2 has branch team-2-development pointing to current-release

As the sprint continues, members of Team 1 and Team 2 follow the basic git workflow by:

1. Pick their team’s base branch: either team-1-development or team-2-development
2. Make a new branch from the base to keep their changes on
3. Make the changes
4. Merge the new branch back into the base branch

So your shared resource has two options when doing their work:

• Start from a team’s base branch
• Start from their own base branch

So let’s say that in sprint S, the teams request the following:

• Team 1 requests the shared resource create X
• Team 2 requests the shared resource update Y with Z

If the two changes are independent, in other words they can be developed completely separately from each other, then the shared resource could choose to do the following for Team 1’s request:

1. Pick Team 1’s base branch team-1-development
2. Make a new branch from the base to keep their changes on
3. Make the changes
4. Merge the new branch back into the base branch

And then do the same for Team 2’s request, just replace team-1-development with team-2-development.

But if the two changes are dependent, in other words something in “update Y with Z” will require the work from “create X” to be done first, then the shared resource could choose to do the following:

1. Pick current-release as the base branch
2. Make a new branch from the base to keep their changes on, let’s call it shared-resource-1-development
3. Make the changes to create X
4. Merge the new branch  into team-1-development

Now you might say, “Whoa! Waitaminute! This isn’t the basic git workflow at all, Lee! What are you trying to pull?” Well, it is the basic git workflow, just modified a little. You see, back up above I said that both Team 1 and the shared resource created their branches based on current-release. This means that when you merge shared-resource-1-development into team-1-development that git will compare the current state of shared-resource-1-development and team-1-development to current-release, merge both sets of changes (relative to current-release), and store the result in team-1-development. This is called a three-way merge.

Then when the shared resource moves on to the “update Y” task, they would:

1. Make the changes to shared-resource-1-development to update Y with Z
2. Merge the shared-resource-1-development branch into team-2-development

This results in another three-way merge into team-2-development which receives both the output of the “create X” task and the output of the “update Y” task.

The thing to keep in mind is that all of these are essentially the same workflow:

1. Pick a point to start your branch
2. Create a new branch from that starting point
3. Make changes
4. Merge your new branch into whatever branch you want to receive your new changes

Keep in mind that: The more your two branches have in common when merging, the easier the merge process will be.

I hope that helps!