Verwendung von Git mit Visual Studio

Question

Als langjähriger Visuelles SourceSafe Benutzer (und Hasser) diskutierte ich den Wechsel zu SVN mit einem Kollegen; er schlug vor, die Git stattdessen. Denn anscheinend kann es als Peer-to-Peer ohne einen zentralen Server verwendet werden (wir sind ein 3-Entwickler-Team).

Ich habe allerdings nichts über Tools gefunden, die Git mit Visual Studio integrieren - gibt es so etwas?

Welche Technologien sind für die Verwendung von Git mit Visual Studio verfügbar? Und was muss ich über deren Unterschiede wissen, bevor ich beginne?

Answer 1

Im Januar 2013 hat Microsoft angekündigt dass sie alle ihre ALM-Produkte mit vollständiger Git-Unterstützung ausstatten. Sie haben ein Plugin veröffentlicht für Visual Studio 2012, das die Integration von Git-Source-Control ermöglicht.

Alternativ dazu gibt es ein Projekt namens Git-Erweiterungen das Add-Ins für Visual Studio 2005, 2008, 2010 und 2012 sowie die Integration des Windows Explorer umfasst. Es wird regelmäßig aktualisiert und ich habe es bei einigen Projekten verwendet und finde es sehr nützlich.

Eine weitere Möglichkeit ist Git-Source-Control-Anbieter .

Answer 2

Ich verwende Git mit Visual Studio für meine Portierung von Protocol Buffers nach C#. Ich verwende die grafische Benutzeroberfläche nicht - ich habe lediglich eine Befehlszeile sowie Visual Studio geöffnet.

Im Großen und Ganzen ist das in Ordnung - das einzige Problem ist, wenn Sie eine Datei umbenennen wollen. Sowohl Git als auch Visual Studio möchten lieber, dass sie derjenige waren, der ihn umbenannt hat. Ich denke, dass die Umbenennung in Visual Studio ist der Weg zu gehen, obwohl - nur vorsichtig sein, was Sie auf der Git-Seite danach tun. Obwohl dies in der Vergangenheit ein wenig mühsam war, habe ich gehört, dass es auf der Git-Seite eigentlich ziemlich nahtlos sein sollte, weil es bemerken kann, dass der Inhalt größtenteils derselbe sein wird. (Normalerweise nicht ganz dasselbe - man neigt dazu, eine Datei umzubenennen, wenn man die Klasse umbenennt, IME.)

Aber im Grunde - ja, es funktioniert gut. Ich bin ein Git-Neuling, aber ich kriege es dazu, alles zu tun, was ich brauche. Stellen Sie sicher, dass Sie eine Git-Ignore-Datei für bin und obj und *.user haben.

Answer 3

Git-Source-Control-Anbieter ist ein neues Plug-in, das Git in Visual Studio integriert.

Answer 4

Ich habe mich bei der Arbeit ein wenig damit befasst (sowohl mit Subversion als auch mit Git). Visual Studio verfügt über eine API zur Integration von Versionskontrollsystemen, die es ermöglicht, Versionskontrolllösungen von Drittanbietern in Visual Studio zu integrieren. Allerdings machen sich die meisten Leute aus mehreren Gründen nicht die Mühe, dies zu tun.

Erstens geht die API davon aus, dass Sie einen Arbeitsablauf mit gesperrtem Checkout verwenden. Es gibt eine Menge Haken darin, die entweder sehr teuer zu implementieren sind oder einfach keinen Sinn machen, wenn Sie den moderneren Edit-Merge-Workflow verwenden.

Der zweite (damit zusammenhängende) Punkt ist, dass Sie bei der Verwendung des Edit-Merge-Workflows, den sowohl Subversion als auch Git fördern, nicht wirklich brauchen Integration von Visual Studio. Der Clou an der Integration von SourceSafe in Visual Studio ist, dass Sie (und der Editor) auf einen Blick erkennen können, welche Dateien Ihnen gehören, welche ausgecheckt werden müssen, bevor Sie sie bearbeiten können, und welche Sie nicht auschecken können, selbst wenn Sie es wollen. Dann kann es Ihnen dabei helfen, das Revisionskontroll-Voodoo zu machen, das Sie tun müssen, wenn Sie eine Datei bearbeiten wollen. Nichts davon ist Teil eines typischen Git-Workflows.

Wenn Sie Git (oder typischerweise SVN) verwenden, finden alle Interaktionen zur Revisionskontrolle entweder vor oder nach der Entwicklungssitzung statt (sobald alles funktioniert und getestet wurde). An diesem Punkt ist es wirklich kein Problem, ein anderes Tool zu verwenden. Sie müssen nicht ständig hin- und herwechseln.

Answer 5

Ich finde, dass Git, da es mit ganzen Bäumen arbeitet, weniger von der IDE-Integration profitiert als Versionskontrollwerkzeuge, die entweder dateibasiert sind oder einem Checkout-Edit-Commit-Muster folgen. Natürlich gibt es Fälle, in denen es schön ist, auf eine Schaltfläche zu klicken, um die Historie zu überprüfen, aber ich vermisse das nicht sehr.

Das eigentliche Muss ist, dass Sie Ihre .gitignore-Datei mit den Dingen füllen, die nicht in einem gemeinsamen Repository sein sollten. Meine enthält in der Regel (neben anderen Dingen) das Folgende:

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

aber das ist stark auf C++ ausgerichtet und nutzt kaum oder gar nicht die Funktionalität eines Klassenassistenten.

Mein Nutzungsverhalten sieht in etwa wie folgt aus.

1. Code, Code, Code in Visual Studio.

2. Wenn Sie zufrieden sind (sinnvoller Zwischenpunkt für die Übergabe des Codes), wechseln Sie zu Git, führen die Änderungen durch und überprüfen die Diffs. Wenn etwas offensichtlich falsch ist, wechseln Sie zurück zu Visual Studio und beheben Sie es, ansonsten übertragen Sie es.

Jedes Zusammenführen, Verzweigen, Umbasieren oder andere ausgefallene SCM-Maßnahmen lassen sich in Git einfach von der Eingabeaufforderung aus durchführen. Visual Studio ist in der Regel ziemlich glücklich mit Dingen, die sich darunter ändern, obwohl es manchmal einige Projekte neu laden muss, wenn Sie die Projektdateien erheblich geändert haben.

Ich finde, dass die Nützlichkeit von Git die geringfügigen Unannehmlichkeiten einer fehlenden vollständigen IDE-Integration überwiegt, aber das ist bis zu einem gewissen Grad Geschmackssache.