Git - Everyone Pushing to Same Branch in Different Files

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

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

StackExchange DevOps Q#4633, answer score: 5