¿Qué files generados por Visual Studio debo comprometer?

El problema que estoy enfrentando es que parece que algunos de los files generados por Visual Studio no son necesarios para las confirmaciones.

Además de las cosas obvias que no comprometer, ¿qué otros files no debería comprometer? ¿Tengo que confirmar files .manifest, etc.?

Una forma diferente de decirlo: ¿qué files son necesarios para recrear el proyecto en el que estoy trabajando y qué files se pueden generar automáticamente?

¡Gracias!

Los files que generalmente no comprometo son: *.suo y *.user . Integro la mayoría de los otros files.

Los files binarys pueden comprometerse o no según la política de su empresa. En teoría, debería ser capaz de volver a crearlos a partir del código fuente, pero en la práctica es una buena idea tener una copy exacta de todo lo que ha enviado a un cliente. Entonces, al less para las versiones, los binarys deberían estar comprometidos.

En general, es un poco difícil enumerar específicamente los files, ya que depende en gran medida del tipo de proyecto que tenga y de las herramientas que use para la autogeneración del código.

En general, el file .suo es algo que es específico del usuario y no debe registrarse.

Sin embargo, la manera más fácil que puedo sugerirte es

  1. No revise ningún file que no esté seguro de que necesite.
  2. Tome una copy de todos los files de su control de origen en una nueva location.
  3. Construye la solución.

Si se construye, genial. De lo contrario, agregue files hasta que lo haga.

Es un poco de testing y error, pero lo más probable es que sea solo una vez.

Otra opción es descubrir realmente para cada tipo de file desconocido exactamente lo que hace y luego decidir si es necesario o no y, en consecuencia, excluir / include. Para esto, si publica las extensiones de los files de los que no está seguro, ¡google / SO puede ayudar!

Personalmente, no creo en comprometer binarys en absoluto, incluso para lanzamientos. Me parece innecesario, como en nuestro caso, cada lanzamiento tiene una label asociada. Por lo tanto, get el código exacto que se lanzó es solo cuestión de get el código asociado con la label y comstackrlo. Además, dado que la implementación generalmente se realiza a través de files de configuration, siempre que tenga la configuration msi / exe (y siempre que mantenga copys de security de las versiones), tener todos los binarys registrados en el control de la fuente parece un poco exagerado