Answers: <p>This is not a "strategy". This is a sure way toward chaos.</p>
  
  <p>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.</p>
  
  <p>Why do you even need two branches, <code>Release</code> and <code>Master</code>? 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.</p>
  
  <p>Stop this madness!</p>
  
  <ul>
  <li>Make each change on its own pull-request branch (call it feature branches if you like).</li>
  <li>Make sure that these pull-requests are not merged into the main integration branch before the code there goes through some minimal code-review.</li>
  <li>Restrict from pushing directly to your integration branch.</li>
  <li>For cleaner history, make sure that the pull-request branch if first rebased on top of integration.</li>
  <li>Make sure that merges of pull-requests are not fast-forwarded and clearly visible in history.</li>
  </ul>
  
  <p>The above will allow for several benefits,</p>
  
  <ul>
  <li>Higher quality and less "human error" mistakes.</li>
  <li>Learning and teaching each other cool dba tricks (during code reviews).</li>
  <li>Keeping the integration branch <strong>green</strong> most of the time (it works!).</li>
  <li>High trust that you are not shooting yourself in the leg using your process.</li>
  <li>Way less "oops, I overwrote your change" kind of merges.</li>
  <li>High trust that new team members are not going to mess things up.</li>
  <li>Git history that is a thing of beauty and a joy forever.</li>
  </ul>
  
  <p>And more ...</p>
  
  <p>Prettier explanation of the "Feature Branch Workflow" is available on the Atlassian Git website here <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow" rel="noreferrer">https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2018-07-30T05:24:42.343Z
Answers: thanks, I sense a lot of emotion behind it with lot of fundamentals/decorum, I just want to see what is wrong with strategy, we have code reviews before pushing into release branch, this will compensate for all the 7 benefits we have above, human error, teaching, green integration brach,  writing over, etc..
Answers: MarkAllison
Answers: CC BY-SA 4.0
Answers: 2018-07-30T05:25:33.020Z
Answers: received a different answer here, https://stackoverflow.com/questions/51586594/git-database-everyone-pushing-to-same-branch-in-different-files
Answers: MarkAllison
Answers: CC BY-SA 4.0
Answers: 2018-07-31T05:43:48.800Z
Answers: I think I will conduct your strategy after further research,For cleaner history, (a) should everyone Rebase ReleasePublic Remote into ReleaseLocal, (b) or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.
Answers: MarkAllison
Answers: CC BY-SA 4.0
Answers: 2018-08-05T15:09:36.913Z
Answers: @Evgeny I disagree with the PR model for this use case. It is just delaying integration. When a PR is finally ready for merge there will be merge conflicts. This requires the developer to rebase. If it took sometime for the PR to be reviewed, the developer that made the change would most likely have lost context which delays again. Does the PR go under any automated builds? I personally would not want to review a PR that has not go through CI. Developers can work in tandem and rebase. But really it is what works for the team so experiment.
Answers: Robert
Answers: CC BY-SA 4.0
Answers: 2018-08-05T20:59:27.683Z
Answers: @Hmm First of all, definitely do CI builds on all PRs. Even more than this, when doing the build - first merge master onto the PR branch on the CI server, and only then do the build. Second, delaying integration is just a policy of the organisation - some orgs leave PRs open for weeks, others leave PRs open for maximum two days and never (ever) more than that. It is just a policy, you decide how you want to do it.
Answers: Evgeny Zislis
Answers: CC BY-SA 4.0
Answers: 2018-07-30T05:07:37.387Z
Answers: 2018-07-30T05:07:37.387Z
Answers: Evgeny Zislis
Answers: <p>I believe there are several anti-patterns in your workflow.</p>
  
  <p><strong>1.</strong> Having different developpers pushing to different files to avoid conflicts is to hard of a constraint to be sustainable in the long run.<br>
  <strong>Consequences:</strong></p>
  
  <ul>
  <li>you will not be able to propose coherent tasks to your devs for long</li>
  <li>there will certainly be complexity in the code introduced merely because of the process and not because of business requirements  </li>
  </ul>
  
  <p><strong>2.</strong> Late merging to <code>master</code> branch<br>
  <strong>Consequences:</strong></p>
  
  <ul>
  <li>you will discover merge issues, technical and business bugs late</li>
  <li>chances are you may not be able to keep your schedule</li>
  </ul>
  
  <p>Your development process should be <strong>business</strong> oriented, not <strong>tech</strong> oriented. You should ask yourself: <em>How can we bring value to users faster?</em></p>
  
  <p>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.</p>
  
  <p>Also, please note that trunc based development cannot be a standalone thing: it has to be paired with feature toggling.</p>
  
  <p>So this is nothing easy here, and nothing to rollout without a serious methodology.</p>
  
  <p><strong>Bottom line is:</strong></p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-08-01T15:04:26.870Z
Answers: 2018-08-01T15:04:26.870Z
Answers: avi.elkharrat
Body: <p>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).</p>
  
  <p>Code Review ---> Push to Release Branch (Currently in work during Sprint) ---> Merge to Master Production Ready Branch</p>
  
  <p>(a) What are the negative consequences of utilizing this strategy in Git?</p>
  
  <p>(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.</p>
  
  <p>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-</p>
  
  <p><a href="https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow" rel="nofollow noreferrer">https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow</a></p>
  
Tags: <git><sql>
Title: Git - Everyone Pushing to Same Branch in Different Files
UserDisplayName: MarkAllison
ThreadText: # Git - Everyone Pushing to Same Branch in Different Files
  
  (Asked by: username_0 on 2018-07-30)
  
  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>
  
  **Tags:** git, sql
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-07-30. Score: 5
  
  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>
  
  > **Comments:**
  > **username_0**: thanks, I sense a lot of emotion behind it with lot of fundamentals/decorum, I just want to see what is wrong with strategy, we have code reviews before pushing into release branch, this will compensate for all the 7 benefits we have above, human error, teaching, green integration brach,  writing over, etc..  
  > **username_0**: received a different answer here, https://stackoverflow.com/questions/51586594/git-database-everyone-pushing-to-same-branch-in-different-files  
  > **username_0**: I think I will conduct your strategy after further research,For cleaner history, (a) should everyone Rebase ReleasePublic Remote into ReleaseLocal, (b) or conducting Pull? (Fetch/Merge), I would think Rebase is answer for cleaner history.  
  > **username_2**: @username_1 I disagree with the PR model for this use case. It is just delaying integration. When a PR is finally ready for merge there will be merge conflicts. This requires the developer to rebase. If it took sometime for the PR to be reviewed, the developer that made the change would most likely have lost context which delays again. Does the PR go under any automated builds? I personally would not want to review a PR that has not go through CI. Developers can work in tandem and rebase. But really it is what works for the team so experiment.  
  > **username_1**: @Hmm First of all, definitely do CI builds on all PRs. Even more than this, when doing the build - first merge master onto the PR branch on the CI server, and only then do the build. Second, delaying integration is just a policy of the organisation - some orgs leave PRs open for weeks, others leave PRs open for maximum two days and never (ever) more than that. It is just a policy, you decide how you want to do it.  
  
  ---
  
  ### Answer by username_3 on 2018-08-01. Score: 1
  
  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.
  
  
  ---
  
  