您如何执行git行为，包括本地（特别是在Windows上）？

我正在把这个.NET商店从svn转移到git，并指出了一些我想解决的辅助问题，然后再进行切换。

我特别要问的一个问题是行尾强制执行。默认情况下，用于Windows的git使用“ checkout crlf，commit lf”安装，对于一堆仅由crlf结尾组成的源（据我所知），它不起作用。

我不知道我会盲目地信任任何给定的开发人员即使在给定指令的情况下也能正确配置此功能，因此我正在考虑以下一项（或两项），但很好奇这里是否有人走了另一条路。

• 一个预提交钩子，用于检查是否有任何lf行的结尾（或可能是所有lf行的结尾），并在该事件中拒绝。
• 分发给开发人员的安装脚本，使用“原样，原样”填充全局配置。

PS在撰写本文时，我想到从svn到git的初始转换可以采用默认方式，而且只要人们坚持使用默认值，那么转换也将是无缝的。曾经是.NET商店中使用git的开发人员，并且安装了非默认的“按原样，按原样”的git，所以我也在那里创建了自己的问题（他们在到达之前就已滚动默认值） 。所以我仍然倾向于某种执行机制。

为了回答如何在本地执行某些操作的问题，您必须不遗余力地管理和强制执行每个开发人员工作站的状态，而且我通常认为开发人员应该是其开发的本地管理员机器，因为如果不是这样的话，他们只会花时间弄清楚我们如何获得这些特权。

这可能是因为使用分布式版本控制时，您不需要关心本地配置的状态。你应该只关心的状态你的配置。假设您将git用作集中式版本控制系统，因为这是每个人最简单的方法，因此基本上每个人都会这样做，那么我们仅假设“您的”配置是保存在中央服务器上的代码副本。

如果是这种情况，那么您就不应该接受您提到的合并crlf / lf行尾的合并。所以，你强制执行时，一些其他客户端试图推动修改您与拒绝污染请求，服务器端逻辑您与回购其可能打破文体选择。

我们需要使用github中的Pull请求到我们的主要dev或master分支的复审过程。在该审核过程中，如果许多文件之间存在空格或行尾差异，我们会将标记为需要更改的请求标记为更改，并坚持要求它们遵循为其提出请求的dev或master分支的格式。

还有一些不错的工具，具体取决于您使用的语言和CI工具，这些工具可以在构建过程或请求请求步骤中根据您设置的规则自动设置代码格式。这也有助于保持代码看起来一致，并在提交代码时最大程度地减少格式问题。

您可以使用每个存储库配置在每个存储库的基础上覆盖用户的配置。当在被认为是中央源的仓库上完成时，它应该与克隆一起传播，并拉到其他仓库，包括本地仓库，从而集中覆盖本地配置。

您可以通过中央存储库中的钩子进一步强制执行此操作，以检查文件结尾是否应该是它们应该的样子，并拒绝合并/推送（如果不是原始的）。但是，这些钩子不会克隆到仓库，至少不会直接克隆，但这不是必需的，因为实际上只需要在中央仓库上强制执行规则。

使用git init中的模板，可以确保创建的回购协议等于所有gitignore，gitattributes等文件，就像您想要的那样。

最后一件事，与您的问题没有直接关系，当我把svn saavy团队带到基于git的工作流程时，我发现最大的摩擦点是如何使他们习惯于中间的额外回购。我发现该视觉提示表有助于解释哪个命令对哪个部分有什么影响。

希望这能有所帮助。