我是特别是在这个问题中询问的是行尾强制执行。默认情况下，用于Windows的git会使用“ checkout crlf，commit lf”进行安装，这对一堆（据我所知）仅由crlf结尾组成的源不起作用。
我不知道我是否会盲目地信任任何给定的开发人员即使在给定指令的情况下也能正确配置此配置，因此我正在考虑以下一项（或两项），但很好奇这里是否有人走了另一条路。
一个预提交的钩子，用于检查是否有任何lf行的结尾（或可能是所有lf行的结尾），并在该事件中拒绝。
分发给dev的安装脚本会填充全局使用“按原样，按原样”进行配置。
PS在撰写本文时，我想到从svn到git的初始转换可以采用默认方式，而且只要人们坚持使用默认方式就可以实现无缝转换。我曾经是.NET商店中使用git的开发人员，并且安装了非默认的“按原样，按原样”的git，所以我也在那里创建了自己的问题（他们在到达之前都已滚动默认值） 。因此，我仍然倾向于某种执行机制。
#1 楼
为了回答如何在本地执行某些操作的问题，您必须不遗余力地管理和强制执行每个开发人员工作站的状态，而且我通常认为开发人员应该是其开发的本地管理员机器，因为如果不是这样的话，他们只会花时间弄清楚我们如何获得这些特权。这可能是因为使用分布式版本控制时，您不需要关心本地配置的状态。您应该只关心配置的状态。假设您将git用作集中式版本控制系统，因为基本上每个人都会这样做，因为它最简单，所以我们只假定“您的”配置是保存在中央服务器上的代码副本。
如果是这种情况，那么您就不应该接受合并，就像您提到的那样，中断crlf / lf行尾。因此，当其他客户端尝试进行更改时，您会使用服务器端逻辑来强制执行此操作，该逻辑会拒绝使用可能破坏样式的选择来污染您的回购协议的请求。
#2 楼
我们需要使用github中的Pull请求到我们的主要dev或master分支的复审过程。在该审核过程中，如果许多文件之间存在空格或行尾差异，我们会将标记为需要更改的请求标记为更改，并坚持要求它们遵循为其提出请求的dev或master分支的格式。还有一些不错的工具，具体取决于您使用的语言和使用的CI工具，这些工具可以在构建过程或请求请求步骤中根据您设置的规则自动设置代码格式。这也有助于保持代码看起来一致，并在提交代码时最大程度地减少格式问题。
评论
您是否愿意详细说明所使用的工具？鉴于有多种方法可以实现此目的，并且我们有自己的方法，但尚未真正以这种方式实施，我很好奇您如何解决这一问题。
–ndarwincorn
17-4-25在5:15
我们正在使用打字稿，github和詹金斯。 Typescript对于这类事情有一个很好的生态系统。
–avi
17年4月26日在12:18
#3 楼
您可以使用每个存储库配置在每个存储库的基础上覆盖用户的配置。当在被认为是中央源的仓库上完成时，它应该与克隆一起传播并拉到其他仓库，包括本地仓库，从而集中覆盖本地配置。您可以通过中央仓库中的挂钩进一步执行此操作检查文件结尾是否应该是应该的，如果文件不是原始文件，则拒绝合并/推送。但是，这些钩子不会克隆到仓库，至少不是直接克隆，但这不是必需的，因为实际上只需要在中央仓库上强制执行规则。
在git init中使用模板可以确保创建您的存储库等于所有gitignore，gitattributes等文件，就像您想要的一样。
最后一件事，与您的问题没有直接关系，我在服用svn轻巧时发现了最大的摩擦点团队使用基于git的工作流程，以使它们习惯中间的额外存储库。我发现该可视提示表有助于解释哪个命令对哪个部分有什么影响。
希望对您有所帮助。
评论
在预接收钩子服务器端，这应该是可以处理的（确保crlf结尾，否则就失败），使用更新钩子，您还应该能够更新预合并。您正在使用哪种类型的git服务器？如果必须在工作站端完成此操作，则可以使用配置管理器，但难度更大，并且存在很多缺点。不得已而为之，就是不要使用CI，也不能强迫人们遵循程序我同意Tensibai，并补充说，您选择的选项应基于您认为应该强制执行的严格程度。提交前的钩子用于严格执行，而不是提交后的合规性报告。
谢谢Dave，我对客户端/限制器实施的理由是，这将减少我的整体工作量，并尽早发现错误。不在CM上的开发人员工作站，而是开发服务器都位于DSC中，因此添加起来将是微不足道的。编辑：还要感谢@Tensibai ...您能详细说明一下客户端看到的那些缺点吗？
主要是如果您强制使用全局钩子客户端，则最终可能会阻止需要l结尾的项目的工作。而且您必须以某种方式进行设置，不能确保每个人都遵循正确的设置。我敢肯定还有其他我不会想到的步枪
您最终做了什么来解决您的问题？