Uważam, że Git, działający na całych drzewach, czerpie mniejsze korzyści z integracji IDE niż narzędzia kontroli źródła, które są albo oparte na plikach, albo stosują się do wzorca kasa-edycja-zatwierdzenie. Oczywiście zdarzają się sytuacje, w których może być miło kliknąć przycisk, aby dokonać przeglądu historii, ale nie tęsknię tak bardzo.
Rzeczywistym obowiązkiem jest zapełnienie pliku .gitignore rzeczy, które nie powinny znajdować się we współdzielonym repozytorium. Mój ogólnie zawiera (między innymi):
*.vcproj.*.user
*.ncb
*.aps
*.suo
ale jest to mocno stronnicze w C ++, przy niewielkim lub zerowym wykorzystaniu funkcji stylu klasowego.
Mój wzorzec użytkowania jest podobny do następującego.
Kod, kod, kod w Visual Studio.
Kiedy jest szczęśliwy (rozsądny punkt pośredni do zatwierdzenia kodu, przełącz się na Git, zmieniaj etapy i sprawdzaj różnice. Jeśli coś jest oczywiście źle, wróć z powrotem do Visual Studio i napraw, w przeciwnym razie zatwierdź.
Wszelkie operacje scalania, rozgałęziania, rebase i inne wymyślne operacje SCM są łatwe w Git z wiersza poleceń. Visual Studio jest zwykle dość zadowolony z rzeczy, które się pod nim zmieniają, chociaż czasem może wymagać ponownego załadowania niektórych projektów, jeśli znacząco zmieniono pliki projektów.
Uważam, że użyteczność Git przewyższa wszelkie drobne niedogodności związane z brakiem pełnej integracji IDE, ale jest to do pewnego stopnia kwestia gustu.