问题描述
团队正在使用Visual Studio SSDT数据库项目与Git源代码控制进行代码更改。团队中的所有人都在将更改推送到主Release分支，并进行代码审查（团队中只有5名开发人员）。所有数据库同事只允许推送到不同的文件（表、存储过程、函数等）。根据工作分配的方式，他们都不会推送或处理相同的SQL文件。最终，从Release分支（当前在工作中）合并的所有好的更改都会合并到Master分支（生产就绪）中。
工作流程： 代码审查 –> 推送到Release分支（当前在Sprint中工作） –> 合并到Master生产就绪分支
(a) 使用这种在Git中的策略会有什么负面后果？
(b) 为了更清晰的历史记录，每个人都应该将ReleasePublic远程重新设置为ReleaseLocal，还是进行Pull操作（Fetch/Merge）？我认为Rebase是更干净的历史记录的答案。
注意：我同意，如果我们正在同一个文件上工作并推送更改，那将会很烦人。另外，还有一种策略是创建不同的功能分支，然后合并到主分支中。但由于每个开发人员每天都有10个与dba管理员相关的更改，创建许多分支和合并会耗费时间且繁琐。
（参考链接：https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow）
解决方案
上述策略虽然有一些可行性，但在Git中还是存在一些反模式。下面提供了一些关于更好的团队协作和代码管理的建议。
反模式1：不同开发者推送到不同文件
问题： 将开发者限制在推送不同文件以避免冲突的做法是不可持续的，可能会导致任务分配不协调以及代码复杂性的增加。
解决方案： 推荐采用特性分支工作流。每个开发人员基于主分支（如master或main）创建自己的特性分支来进行开发，每个特性分支解决一个特定的问题。这种方法可以避免直接推送到主分支引起的冲突问题，同时也可以更好地跟踪每个功能的开发进度。
反模式2：延迟合并到主分支
问题： 将更改延迟合并到master分支可能会导致在较晚的阶段才发现合并问题和技术、业务缺陷。
解决方案： 推荐使用持续集成（CI）和特性分支工作流。每个特性分支开发完成后，通过CI自动构建和运行测试，确保代码质量。在特性分支通过代码审查后，将其合并到主分支。这样可以更早地发现问题，确保代码质量和可维护性。
推荐做法：特性分支工作流
特性分支工作流是一种推荐的团队协作方式，可以有效地管理代码更改并保持代码库的可维护性。
1. 对于每个新的功能、修复或任务，创建一个新的特性分支，命名格式可以是feature/feature-name、bugfix/bug-name等。
2. 在特性分支上进行开发，保持提交频率适中，不要等到整个任务完成后才提交。
3. 在特性分支开发完成后，通过CI进行自动构建和测试，确保代码质量。
4. 请求代码审查，确保代码符合团队的编码标准和最佳实践。
5. 在代码审查通过后，将特性分支合并到主分支（如master或main）。
6. 可以考虑使用--no-ff参数合并分支，以保留合并历史，更容易追踪每个特性的开发历程。
通过特性分支工作流，你可以实现以下好处：
– 每个特性的开发进程更加独立，降低冲突的可能性。
– 代码质量得到保障，通过CI自动化测试。
– 更早地发现并解决问题，避免延迟合并导致的麻烦。
– 更清晰的Git历史，方便跟踪每个特性的开发过程。
请注意，以上只是一些建议和最佳实践，具体的实施方式需要根据团队的情况和需求进行调整。同时，逐步转变团队的开发流程可能需要一些时间和培训，但这将为团队带来更高效、可维护的代码开发环境。
了解更多有关特性分支工作流的信息，可以参考Atlassian Git的详细说明：https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow。
请注意，在转变团队开发流程时，可能会涉及到一些挑战和调整。因此，建议你充分了