Git - Everyone Pushing to Same Branch in Different Files

Question

Database team is implementing code changes, using Visual Studio SSDT database projects with Git source control. Everyone is pushing to main Release branch with code review (only 5 developers on the team). All the database coworkers are only allowed pushing to different files only (tables, sprocs, functions), etc. The way work is assigned, none of us push or work the same sql file. Eventually all good changes from Release (currently in Work) are merged into Master branch (Production Ready).

Code Review ---> Push to Release Branch (Currently in work during Sprint) ---> Merge to Master Production Ready Branch

(a) What are the negative consequences of utilizing this strategy in Git?

(b) For cleaner history, should everyone Rebase ReleasePublic Remote into ReleaseLocal, or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.

Note: I agree, it would be annoying only if we are working on the same file and pushing changes. Alternative Strategy to create different feature branches and then merge into main branch. We are refraining from this strategy since each developer has 10 dba admin related changes a day, creating many branches and merges is time consuming and cumbersome-

https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Answer 1

This is not a "strategy". This is a sure way toward chaos.

The idea behind "trunk branch", which means having one branch for integration, does not mean that everyone should be pushing their changes to this branch directly. It only means that his branch is the place where integration happens.

Why do you even need two branches, Release and Master? What benefit does this bring? Probably just the benefit of confusing git history into an incomprehensible mess so that no one knows what is happening.

Stop this madness!

• Make each change on its own pull-request branch (call it feature branches if you like).
• Make sure that these pull-requests are not merged into the main integration branch before the code there goes through some minimal code-review.
• Restrict from pushing directly to your integration branch.
• For cleaner history, make sure that the pull-request branch if first rebased on top of integration.
• Make sure that merges of pull-requests are not fast-forwarded and clearly visible in history.

The above will allow for several benefits,

• Higher quality and less "human error" mistakes.
• Learning and teaching each other cool dba tricks (during code reviews).
• Keeping the integration branch green most of the time (it works!).
• High trust that you are not shooting yourself in the leg using your process.
• Way less "oops, I overwrote your change" kind of merges.
• High trust that new team members are not going to mess things up.
• Git history that is a thing of beauty and a joy forever.

And more ...

Prettier explanation of the "Feature Branch Workflow" is available on the Atlassian Git website here https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

Answer 2

I believe there are several anti-patterns in your workflow.

1. Having different developpers pushing to different files to avoid conflicts is to hard of a constraint to be sustainable in the long run.
Consequences:

• you will not be able to propose coherent tasks to your devs for long
• there will certainly be complexity in the code introduced merely because of the process and not because of business requirements

2. Late merging to master branch
Consequences:

• you will discover merge issues, technical and business bugs late
• chances are you may not be able to keep your schedule

Your development process should be business oriented, not tech oriented. You should ask yourself: How can we bring value to users faster?

The answer to this question is actually the alternative strategy that you talk about! But this cannot be implemented without some change in your workflow and very probably in your organisation.

Also, please note that trunc based development cannot be a standalone thing: it has to be paired with feature toggling.

So this is nothing easy here, and nothing to rollout without a serious methodology.

Bottom line is:

You ask yourself very good questions, and you really should be going forward on this line of thought. However what seems to be ahead of you looks like a team transformation; something to be done with some fire power and / or team mates that are consumed agilists.