我们公司使用git来跟踪文档/代码更改，有几个人进行更改并推送到中央仓库。一般来说，大多数人都是git或命令行工具的新手。对于他们，我们有脚本在更改后更新或发布他们的本地仓库。
是否有任何工作流程可以更好地适应这些情况，以最大限度地减少发生的合并冲突，这些冲突必须由对git更有经验的人进行整理？
答案 0 :(得分：4)
Git不是正确开发实践的替代品。它不会为您编码更好。
如果两个开发人员触及完全相同的代码，git无法使他们的工作变得更容易，如果这是一个合并冲突，无论你是否在分支机构，它都将是一个。
短期解决方案：使用适当的本地和远程分支来封装不同功能的工作。使用分支差异（或github pull请求）来查看功能集并帮助检查差异和冲突。
长期：修复代码，使其适应您的团队，反之亦然，并使用适当的开发实践。
答案 1 :(得分：2)
没有什么神奇的。主要是纪律。
如果人们在与某些“主要”回购或分支合并之前必须做拉动请求或等待提交审核之类的事情，请尽量缩短审核时间。
您应该尝试缩短分支生命周期，但这实际上取决于您正在处理的项目类型。
规则规定所有提交必须尽可能小。制定一项规则，即提交必须只改变一件事。不要将化妆品变化（如空白）与功能变化和重大重构混合在一起。 （不要完全禁止空格更改 - 只需将它们与其他更改分开。）
除了版本控制本身之外，尝试以减少他们在同一周左右更改相同代码的可能性的方式将任务分配给编码人员。
答案 2 :(得分：2)
合并冲突的首要原因是每次合并之间的时间 每次合并之间等待的时间越长，您就越可以看到合并冲突。
您可以通过选择merge workflow（例如git flow）来最小化这一点，该rebase before merging将提倡每个功能的分支，并促进任务的隔离。
但只要涉及 common 文件集（在两个不同的开发中），最终会出现合并冲突，尤其是等待时间过长的情况。
因此，使用分布式 VCS，请学习定期发布（推/拉），并学会 Better, simpler example of 'semantic conflict'? 。
这不仅会减少冲突的数量，还会减少语义冲突的数量：那些是似乎自动（没有冲突）的合并，但是产生了代码不正确。
请参阅“{{3}}”。
答案 3 :(得分：0)
这里写的一篇文章将帮助您更好地理解，＃34; A successful Git branching model＆＃34;。它声明你应该分开不同类型的分支，包括：