合并时规范Git花括号格式(同一行与下一行)约定



我对Git非常陌生(我已经使用TFS大约十年了,并且已经研究了几天Git(,我正在进行原型开发,将我们的开发团队切换到使用Azure Repos而不是TFS。

问题:我遇到的一个常见问题(也是我最不喜欢的问题类型之一(是合并,当一名程序员重新格式化代码文件,使其具有与以前不同的大括号格式规则(即同一行与下一行(,并且合并逻辑显示数百个更改(每个大括号更改一个(时,我无法轻易判断实际的逻辑更改在哪里当我去diff或签入文件时,在代码文件中。我知道这不应该发生,但有些程序员无论如何都会这样做。

问题:我最近了解到,Git可以通过使用crlf设置来规范windows和mac/linux开发人员系统之间的行结尾(问题(,我想知道Git中是否有一些功能可以规范代码格式约定,比如大括号新行与同行样式?

所需解决方案:我希望Git回购始终使用一个大括号样式(我们将作为一个团队决定(,然后当开发人员合并代码时,它会自动格式化为约定的回购格式,然后,当开发人员从repo中提取代码时,它会被格式化为他们喜欢的样式,这样同一行和下一行就可以平静地生活,并且将代码文件从一种格式化约定切换到另一种格式约定的丑陋合并问题将永远得到解决。有办法做这样的事吗?

解决方案是使用不同的工具,而不是git。我知道有一个版本控制的研究项目,它存储语法树而不是文本行,并在结账时根据用户偏好格式化代码,就像你所问的那样,但它在大约15年前就被放弃了。

您的团队可以在提交之前调用一个脚本(或者git预提交挂钩?(,该脚本运行代码格式化程序以使用团队的首选格式。然后,在提取之后,任何开发人员都会使用自己喜欢的设置运行代码格式化程序。但我不认为他们可以修复显示团队标准的git-diff。

您可以使用一个git hook shell脚本来检查所有已更改的文件,并对其应用mvn-premiser:https://github.com/HubSpot/prettier-maven-plugin

最新更新