c# - usar - ¿Cómo trato con los archivos de Visual Studio en Git?
usar git en visual studio (2)
Normalmente trabajo con .NET usando Git para el control de versiones. En mi equipo, trabajamos en paralelo y con frecuencia comprometemos nuestro código para integrarlo en la aplicación. Todo está bien, PERO la solución de Visual Studio y los archivos de proyecto. Encontramos dos formas:
- Nunca cometer esos archivos, cada uno tiene su propio
- Incluir esos archivos en la versión del sistema.
Ambas formas tienen ventajas y desventajas, pero básicamente luchamos cada vez que nos retiramos del repositorio central. Aquí encontramos algunos problemas adicionales: (en parentesis, la referencia a la lista anterior)
- Tenemos que incluir los archivos de otros en el proyecto (1) o incluir los más nuevos (2)
- Si trabajamos en diferentes arquitecturas (x86 / x64) tenemos que cambiar manualmente los archivos
.csproj(2) - Mismos problemas respondidos para referencias y paquetes NuGet
y así. ¿Hay un flujo de trabajo adecuado que pueda usar?
Cometer archivos .sln y .csproj suele ser la mejor práctica (como en esta respuesta ), pero la fusión requiere cierta atención.
Consulte " ¿Por qué mis archivos .csproj se .csproj después de un git rebase ? ".
(vea abajo) *.csproj -text merge=union
*.sln -text merge=union v
O puedes renunciar a .csproj y regenerarlos localmente como en este tweet .
Otra razón para ignorar esos archivos csproj es si se regeneran, como en este contexto
yellowblood advierte ( en los comentarios ) sobre un problema de conflicto grave con el archivo csproj cuando se usa con la estrategia merge=union .
Eso hace eco del artículo " Fusionar conflictos en archivos csproj ".
Es por eso que hay una sugerencia de que VS IDE debe admitir patrones de archivo en archivos de proyecto (para no modificar el archivo .csproj si se agrega un nuevo archivo .cs que se ajuste a ese patrón).
Se ha sugerido que si Visual Studio ordenaba primero sus elementos, eso ayudaría a mitigar el problema.
Eso ayuda a reducir los conflictos incidentales causados por el tipo de elementos aparentemente no deterministas de Visual Studio.
Pero no hace que el problema de los conflictos de fusión desaparezca.
En nuestro proyecto verificamos estos en el control de versiones. Comenzamos con el .gitignore de github y un archivo simple .gitattributes :
# Auto detect text files and perform LF normalization
* text=auto
# Custom for Visual Studio
*.cs diff=csharp
Esto se debe a que la estrategia de combinación de union puede ser realmente peligrosa para estos archivos; consulte Conflictos de combinación en archivos csproj para obtener información detallada sobre por qué esto no siempre es seguro y probablemente no es lo que usted desea.
Por lo general, siempre tendrás conflictos de combinación, pero son muy fáciles de manejar rápidamente en Visual Studio. Un caso de ejemplo es agregar un nuevo proyecto vacío a una solución y cometerlo, y luego hacer que varios miembros del equipo agreguen diferentes archivos al proyecto.
En teoría, podría tener definido un controlador de combinación personalizado que maneje mejor la combinación de XML, pero aún no he visto que alguien más lo haya hecho.