Usando o Git com o Visual Studio

Como um usuário do Visual SourceSafe de longa data (e odiador), eu estava discutindo a mudança para o SVN com um colega; ele sugeriu usar o Git em vez disso. Já que, aparentemente, ele pode ser usado como peer-to-peer sem um servidor central (só temos uma equipe de 3 desenvolvedores).

Eu não consegui encontrar nada sobre ferramentas que integram o Git com o Visual Studio, entretanto – existe tal coisa?

Quais tecnologias estão disponíveis para usar o Git com o Visual Studio? E o que eu preciso saber sobre como eles diferem antes de eu começar?

    Em janeiro de 2013, a Microsoft anunciou que está adicionando suporte total ao Git em todos os seus produtos ALM. Eles publicaram um plug-in para o Visual Studio 2012 que adiciona a integração do controle de origem do Git.

    Como alternativa, existe um projeto chamado Git Extensions que inclui suplementos para o Visual Studio 2005, 2008, 2010 e 2012, bem como a integração com o Windows Explorer. É regularmente atualizado e tendo usado em alguns projetos, eu achei muito útil.

    Outra opção é o Git Source Control Provider .

    Eu uso o Git com o Visual Studio para minha porta de Protocol Buffers para C #. Eu não uso a GUI – apenas mantenho uma linha de comando aberta, assim como o Visual Studio.

    Na maior parte, tudo bem – o único problema é quando você quer renomear um arquivo. Tanto o Git quanto o Visual Studio prefeririam que eles fossem o renomeados. Eu acho que renomeá-lo no Visual Studio é o caminho a percorrer – basta ter cuidado com o que você faz no lado do Git depois. Embora isso tenha sido um pouco trabalhoso no passado, ouvi dizer que, na verdade, ele deve ser bem simples no lado do Git, porque pode perceber que o conteúdo será basicamente o mesmo. (Não inteiramente o mesmo, normalmente – você tende a renomear um arquivo quando está renomeando a class, IME.)

    Mas basicamente – sim, funciona bem. Eu sou um novato do Git, mas posso fazê-lo para fazer tudo o que eu preciso. Certifique-se de ter um arquivo git ignore para bin e obj e * .user.

    O Git Source Control Provider é um novo plug-in que integra o Git com o Visual Studio.

    Eu olhei para isso um pouco no trabalho (tanto com o Subversion quanto com o Git). Visual Studio na verdade tem uma API de integração de controle de origem para permitir que você integre soluções de controle de origem de terceiros no Visual Studio. No entanto, a maioria das pessoas não se incomoda com isso por alguns motivos.

    A primeira é que a API praticamente supõe que você esteja usando um stream de trabalho de check-out bloqueado. Há muitos ganchos nele que são muito caros para implementar, ou simplesmente não fazem sentido quando você está usando o stream de trabalho de mesclagem de edição mais moderno.

    O segundo (que está relacionado) é que quando você está usando o stream de trabalho de edição e mesclagem que o Subversion e o Git encorajam, você realmente não precisa da integração do Visual Studio. A coisa mais importante sobre a integração do SourceSafe com o Visual Studio é que você (e o editor) pode ver rapidamente quais arquivos você possui, que devem ser verificados antes de editar, e que você não pode verificar mesmo se quiser. Em seguida, ele pode ajudá-lo a fazer o vodu de controle de revisão que você precisa fazer quando quiser editar um arquivo. Nada disso faz parte de um stream de trabalho típico do Git.

    Quando você está usando o Git (ou o SVN normalmente), todas as interações de controle de revisão acontecem antes ou depois da session de desenvolvimento (depois de ter tudo funcionando e testado). Nesse ponto, não é muito doloroso usar uma ferramenta diferente. Você não está constantemente tendo que mudar de um lado para outro.

    Acho que o Git, trabalhando em trees inteiras, beneficia menos da integração do IDE do que as ferramentas de controle de origem que são baseadas em arquivos ou seguem um padrão checkout-edit-commit. É claro que há casos em que pode ser bom clicar em um botão para fazer um exame de histórico, mas não sinto muita falta disso.

    O verdadeiro dever é fazer com que seu arquivo .gitignore esteja cheio das coisas que não deveriam estar em um repository compartilhado. O meu geralmente contém (entre outras coisas) o seguinte:

    *.vcproj.*.user *.ncb *.aps *.suo 

    mas isso é fortemente inclinado pelo C ++ com pouco ou nenhum uso de qualquer funcionalidade de estilo de assistente de class.

    Meu padrão de uso é algo como o seguinte.

    1. Código, código, código no Visual Studio.

    2. Quando feliz (ponto intermediário sensato para cometer código, mude para Git, altere o palco e revise os diffs. Se alguma coisa estiver obviamente errada, volte para o Visual Studio e corrija, caso contrário, confirme.

    Qualquer mesclagem, ramificação, rebase ou outro material sofisticado do SCM é fácil de fazer no Git no prompt de comando. O Visual Studio normalmente fica feliz com as coisas que estão mudando, embora às vezes possa precisar recarregar alguns projetos se você alterou os arquivos do projeto de forma significativa.

    Eu acho que a utilidade do Git supera qualquer inconveniente menor de não ter a integração completa do IDE, mas é, até certo ponto, uma questão de gosto.

    A Microsoft anunciou o Git para o Visual Studio 2012 (atualização 2) recentemente. Eu ainda não brinquei com isso, mas esse vídeo parece promissor.

    Aqui está um rápido tutorial sobre como usar o Git do Visual Studio 2012.

    Também não perca o TortoiseGit … https://tortoisegit.org/

    Há um Visual Studio Tools para Git da Microsoft. Ele suporta apenas o Visual Studio 2012 (atualização 2).

    O Visual Studio 2013 suporta nativamente o Git.

    Veja o anúncio oficial .

    O suporte do Git feito pela Microsoft no Visual Studio é bom o suficiente para o trabalho básico (commit / fetch / merge e push). Meu conselho é apenas para evitar isso …

    Eu prefiro GitExtensions (ou em menor proporção SourceTree ). Porque ver o DAG é realmente importante para mim entender como o Git funciona. E você está muito mais consciente do que os outros contribuidores do seu projeto fizeram!

    No Visual Studio, você não pode ver rapidamente a diferença entre os arquivos ou confirmar, nem (adicionar ao índice) e confirmar apenas parte das modificações. Navegue sua história não é bom também … Tudo o que termina em uma experiência dolorosa!

    E, por exemplo, GitExtensions é empacotado com plugins interessantes: background fetch, GitFlow, … e agora, continuous integration !

    Para os usuários do Visual Studio 2015 , o Git está tomando forma se você instalar a extensão GitHub. Mas uma ferramenta externa ainda é melhor 😉

    O TortoiseGit amadureceu e recomendo especialmente se tiver usado o TortoiseSVN.

    A mais nova versão do Git Extensions suporta o Visual Studio 2010 agora (junto com o Visual Studio 2008 e Visual Studio 2005 ).

    Eu achei que fosse bastante fácil de usar com o Visual Studio 2008 e a interface parece ser a mesma no Visual Studio 2010.

    A solução mais simples que realmente funciona bem é adicionar os comandos do TortoiseGit como ferramentas externas.

    Solução para adicionar uma barra de ferramentas Git (TortoiseGit) ao Visual Studio

    Como manipulado por Jon Rimmer, você pode usar GitExtensions. O GitExtensions funciona no Visual Studio 2005 e no Visual Studio 2008, mas também funciona no Visual Studio 2010 se você copiar e configurar manualmente o arquivo .Addin.

    Atualmente existem 2 opções para o Git Source Control no Visual Studio (2010 e 12):

    1. Provedor de Controle de Fonte Git
    2. Provedor do Microsoft Git

    Eu tentei os dois e encontrei o primeiro a ser mais maduro e tem mais resources. Por exemplo, ele funciona muito bem com as extensões git e git de tartaruga e até mesmo expõe seus resources.

    Nota : Independentemente da extensão utilizada, certifique-se de ativá-la em Tools -> Options -> Source control -> Plugin Selection para que ela funcione.

    A partir de 2013-02-11, o plug-in do Microsoft Git para o Visual Studio 2012 também deve funcionar com a versão Express .