¿Cómo aplica el comportamiento de git, incluso a nivel local (particularmente en Windows)?

Me estoy enfocando en mover esta tienda .NET de svn a git, y he identificado algunos problemas auxiliares para los que me gustaría tener una solución antes de activar el interruptor.

Lo que estoy preguntando en particular en esta pregunta es la ejecución de final de línea. Por defecto, git para Windows se instala con 'checkout crlf, commit lf', que no funcionará para un montón de fuentes que (hasta donde yo sé) está compuesto exclusivamente por terminaciones crlf.

No sé si confiaría ciegamente en un desarrollador dado para configurar esto correctamente, incluso si recibiera instrucciones, por lo que estoy considerando uno (o ambos) de los siguientes, pero tenía curiosidad por saber si alguien aquí había tomado otra ruta.

• Un enlace de precompromiso que verifica si hay terminaciones de línea lf (o tal vez todas las terminaciones de línea lf), y rechaza en ese caso.
• Un script de instalación distribuido a los desarrolladores que llena la configuración global con 'as-is, as-is'.

PD: Mientras escribía esto, se me ocurrió que la conversión inicial de svn a git podría comprometerse de la manera predeterminada y, siempre y cuando las personas se apegaran a la predeterminada, eso también sería bastante perfecto. Después de haber sido un desarrollador que usa git en una tienda .NET que instaló git con los 'no-predeterminados', tal como están, también he creado mis propios problemas allí (todos habían implementado los predeterminados antes de mi llegada) . Así que todavía me estoy inclinando hacia algún tipo de mecanismo de aplicación.

Para responder a la pregunta de cómo hacer cumplir algo localmente, no puede hacerlo sin hacer un gran esfuerzo para administrar y hacer cumplir el estado de cada estación de trabajo de desarrolladores, y generalmente opino que los desarrolladores probablemente deberían ser administradores locales en su desarrollo máquina porque si no lo están, simplemente pasarán su tiempo pensando en cómo obtener esos privilegios de todos modos.

Y eso probablemente se deba a que no debería tener que preocuparse por el estado de la configuración local al usar el control de versión distribuido. Solo debe preocuparse por el estado de su configuración. Asumiendo que está usando git como un sistema de control de versiones centralizado, porque eso es lo que básicamente todos hacen de todos modos porque es más fácil, entonces supongamos que "su" configuración es la copia del código guardado en el servidor central.

Si este es el caso, entonces no debe aceptar fusiones que, como mencionó, rompan las terminaciones de línea crlf / lf. Por lo tanto, hace cumplir eso cuando algún otro cliente intenta impulsar cambios con una lógica del lado del servidor que rechaza la solicitud de contaminar su repositorio con sus elecciones estilísticas potencialmente rotas.

Requerimos un proceso de revisión usando solicitudes Pull en github en nuestras ramas principales de desarrollo o maestras. Durante ese proceso de revisión, marcaremos las solicitudes de extracción como que requieren cambios si muchos archivos tienen espacios en blanco o diferencias de final de línea, e insistiremos en que sigan el formato del desarrollador o la rama maestra para la que están realizando la solicitud de extracción.

También hay algunas buenas herramientas según los idiomas que use y las herramientas de CI que use, que pueden, durante el proceso de compilación o el paso de solicitud de extracción, formatear automáticamente el código según las reglas que configure. Eso también ayuda a mantener el código de forma coherente y a minimizar los problemas de formato al confirmar el código.

Podrías usar configuración por repositorio para anular la configuración del usuario por repositorio. Cuando se realiza en el repositorio considerado como la fuente central, debe propagarse con clones y obtener otros repositorios, incluidos los locales, anulando centralmente la configuración local.

Puede aplicar esto más a través de ganchos en su repositorio central para verificar que las terminaciones de los archivos sean lo que deben ser y rechazar la fusión / inserción si no fuera kosher. Sin embargo, estos ganchos no se clonarán con el repositorio, al menos no directamente, pero esto no es necesario ya que las reglas realmente solo deben aplicarse en el repositorio central.

Usando plantillas en tu git init , puede asegurarse de que sus repositorios se creen de la misma manera que todos los archivos gitignore, gitattributes, etc. tal como usted quiere que sean.

Lo último, no directamente relacionado con su pregunta, encontré el mayor punto de fricción cuando llevé a svn saavy team a un flujo de trabajo basado en git: qué hacer que se acostumbren al repositorio adicional en el medio. Encontré que esta hoja de referencia visual ayudó un poco a explicar qué comando tenía qué efecto en qué parte.

Espero que esto haya ayudado un poco.