Como usuario de Visual SourceSafe desde hace mucho tiempo (y odioso) estaba discutiendo el cambio a SVN con un colega; él sugirió usar Git en su lugar. Ya que, aparentemente, puede ser usado como peer-to-peer sin un servidor central (sólo tenemos un equipo de 3 desarrolladores).
No he podido encontrar nada sobre herramientas que integren Git con Visual Studio, sin embargo, ¿existe tal cosa?
Si no, ¿alguien puede informar sobre sus experiencias con Git en Visual Studio?
En enero de 2013, Microsoft anunciado que están añadiendo el soporte completo de Git en todos sus productos ALM. Tienen publicó un plugin para Visual Studio 2012 que añade la integración del control de la fuente Git.
Alternativamente, hay un proyecto llamado Extensiones de Git que incluye complementos para Visual Studio 2005, 2008, 2010 y 2012, así como la integración con el Explorador de Windows. Se actualiza regularmente y, al haberlo usado en un par de proyectos, lo he encontrado muy útil.
Otra opción es Proveedor de control de fuentes Git .
Utilizo Git con Visual Studio para mi puerto de Buffers de Protocolo a C#. No uso la interfaz gráfica de usuario, sólo mantengo una línea de comandos abierta, así como Visual Studio.
En su mayor parte está bien, el único problema es cuando quieres renombrar un archivo. Tanto Git como Visual Studio preferirían que ellos fueron los que le cambiaron el nombre. Creo que renombrarlo en Visual Studio es la manera de hacerlo, pero ten cuidado con lo que haces después en el Git. Aunque esto ha sido un poco doloroso en el pasado, he oído que en realidad debería ser bastante fluido en el lado Git, porque puede notar que los contenidos serán en su mayoría los mismos. (No del todo el mismo, normalmente - tiendes a renombrar un archivo cuando renuncias a la clase, IME.)
Pero básicamente sí, funciona bien. Soy un novato en Git, pero puedo hacer que haga todo lo que necesito. Asegúrate de tener un archivo de ignorar a Git para bin y obj, y *.user.
He investigado esto un poco en el trabajo (tanto con Subversión como con Git). Visual Studio tiene un API de integración de control de fuentes que permite integrar soluciones de control de fuentes de terceros en VS. Sin embargo, la mayoría de la gente no se molesta en ello por un par de razones.
La primera es que la API asume que estás usando un flujo de trabajo de pago bloqueado. Hay un montón de ganchos en ella que son de alguna manera caros de implementar, o simplemente no tienen sentido cuando se utiliza el flujo de trabajo más moderno de edición-fusión.
La segunda (que está relacionada) es que cuando usas el flujo de trabajo de edición-fusión que tanto Subversion como Git fomentan, realmente no necesita Integración de Visual Studio. Lo más importante de la integración de SourceSafe con VS es que tú (y el editor) pueden saber de un vistazo qué archivos tienes, cuáles deben ser revisados antes de que puedas editarlos, y cuáles no puedes revisar aunque quieras. Entonces puede ayudarte a hacer cualquier vudú de control de revisiones que necesites hacer cuando quieras editar un archivo. Nada de eso es ni siquiera parte del típico flujo de trabajo de Git.
Cuando usas Git (o SVN típicamente), tus interacciones de control de revisión tienen lugar antes de la sesión de desarrollo o después de ella (una vez que tienes todo funcionando y probado). En ese momento, no es demasiado doloroso usar una herramienta diferente. No tienes que cambiar constantemente de un lado a otro.
Encuentro que git, trabajando en árboles enteros como lo hace, se beneficia menos de la integración ideal que las herramientas de control de código fuente que están basadas en archivos o siguen un patrón de checkout-edit-commit. Por supuesto, hay casos en los que puede ser agradable hacer clic en un botón para hacer un examen de historia, pero no echo mucho de menos eso.
Lo que hay que hacer es llenar tu archivo .gitignore con las cosas que no deberían estar en un repositorio compartido. El mío generalmente contiene (entre otras cosas) lo siguiente:
*.vcproj.*.user
*.ncb
*.aps
*.suopero esto está fuertemente sesgado en C++ con poco o ningún uso de cualquier funcionalidad de estilo de mago de clase.
Mi patrón de uso es algo como lo siguiente.
1) Código, código, código en VS.
2) Cuando esté contento (punto intermedio sensible al código commit, cambie a git, escale los cambios y revise las diferencias. Si algo está obviamente mal, vuelve a VS y arréglalo, si no commit.
Cualquier fusión, ramificación, rebase u otro tipo de cosas elegantes de SCM es fácil de hacer en git desde la línea de comandos. VS normalmente está bastante contento con las cosas que cambian bajo él, aunque a veces puede necesitar recargar algunos proyectos si has alterado los archivos de proyecto de forma significativa.
Encuentro que la utilidad del git supera cualquier inconveniente menor de no tener una integración completa en el IDE, pero es, hasta cierto punto, una cuestión de gusto.
Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.
