Git 合并维护版本的策略

我的团队（10人）使用SVN维护一个代码库，我们正在主干上开发下一个主要版本，同时修复分支中最新发布版本的bug

目前，我们的策略是，当我们在维护分支中进行修复时，我们提出两张罚单，一张在分支中修复，另一张在主干中修复。然后我们在这两个地方测试修复

由于我们几乎不希望在维护分支中进行不进入主干的修复，因此更简单的方法是定期将分支中的所有更改合并到主干中，而无需专门跟踪或测试单个修复。那么，我们何时合并或多久合并都无关紧要，只要合并是在新版本发布之前完成的

我们没有任何显著的自动化测试覆盖率（尽管代码是C#，所以至少它是编译的和强类型的）

---

所以我的问题是，一般认为更严格的方法是最佳实践还是过于迂腐？人们是否有效地使用“更懒惰”的方法？有没有我没有考虑过的替代方案？如果我使用的是git，这会让整个事情变得更简单吗？

最后一行太基于观点了！我已经在SVN中通过主干中的所有修复和分支的每日合并完成了这项工作。如果你经常合并，合并并不可怕。每个人都必须标记与分支机构相关的更改。谢谢。如果你说的是从主干到分支的合并，我想这是功能分支，这不完全是一回事。但我认为，更频繁地合并，这一点我肯定会接受。现在我坐在这里，有130个要合并的更改和30个冲突，我希望我没有让它走这么远。按照时间顺序，把它们合并成小块，最早的一个。检查哪些文件会因每次更改而受到影响，以便您可以提前发现潜在冲突，并分别在其中合并/检查这些冲突。对于真正的冲突，请无情地让开发人员检查手动合并是否正确。这是一个维护分支。并不是主干上的所有更改都是相关的，这就是为什么您需要让开发人员标记它是否应该合并。是否有其他人提出单独的错误跟踪通知单，并在主干中的更改被合并后重新测试？这是我很想避免的事情，但由于我们没有自动化测试，我在那里犯了偏执狂的错误