Git Branching and Merging Strategy for a Shared Team Resource

Hello to All,

My team is facing a source control workflow challenge with Git when it comes to having a shared resource.

Here is the team make-up:

  • Sprint Team #1
  • Sprint Team #2
  • _ Shared _ DBA across teams
  • Dev. Lead (Myself)

Now, each sprint we have available the following branches:

  1. Master (Representative of Production)
  2. Hotfix (Copy of master for push/pull of hotfixes)
  3. Release (What will be deployed next release; reconciliation of all further branches below)
  4. sprint/release team #1 branch (Represents all consolidated code for team #1; changes per sprint and reconciled to release branch at end of sprint)
  5. sprint/release team #2 branch (Represents all consolidated code for team #2; changes per sprint and reconciled to release branch at end of sprint)
  6. shared resource branch (For shared DBA)
  7. Other personal branches for developers (not to be considered authoritative for reconciliation)

See attached for diagrammed version of the branching structure above

The problem is that the shared DBA needs to constantly and consistently make changes across teams for SQL-related items. In addition, for just SQL related items his changes need to be considered authoritative. His changes are localized to a specific folder, if that helps.

Is there either a workflow or git configuration that will allow for the shared resource to effectively work either on his own branch while allowing for the team to effectively collaborate with his changes?

Thank you for your time.

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!

Thank you for this write-up! Reviewing but looks great so far. Will ask questions when done.

1 Like