Unser etwa zehnköpfiges Dokumentationsteam ist kürzlich von SVN zu Git gewechselt. In SVN haben alle am Master gearbeitet - ein Modell, das ich immer gehasst habe, aber ich konnte diese Änderung nicht herbeiführen. Im Rahmen der Umstellung auf Git haben wir uns darauf geeinigt, dies zu beheben, können es aber noch nicht (warten auf Build-Änderungen, die Builds aus beliebigen Zweigen zulassen). Inzwischen arbeiten alle am Meister. Ja, ich weiß, das ist schrecklich, glaub mir.

Wir haben jetzt viel mehr Probleme als bei der Verwendung von SVN, von denen einige durch das zweistufige Modell von Git (lokal und remote) verursacht werden. Manchmal legen die Leute fest, schieben aber nicht, oder sie ziehen und bekommen Konflikte mit ihren anstehenden lokalen Änderungen. Gestern hat jemand die letzten Änderungen - irgendwie - mit einer fehlerhaften Zusammenführung überfrachtet. Ich denke, das war die Zusammenführung, die Git macht, wenn Sie ziehen und herausragende Änderungen vornehmen. (Er konnte mir nicht genau sagen, was er getan hat, und da er eine GUI verwendet, kann ich nicht einfach seinen Shell-Verlauf überprüfen.)

Als der kompetenteste Git-Benutzer (lesen Sie: Ich habe es vorher verwendet, aber nicht für etwas sehr Kompliziertes), bin ich derjenige, der Richtlinien festlegt, die Werkzeuge lehrt und Unordnung beseitigt. Welche Änderungen kann ich daran vornehmen, wie wir die Tools verwenden, um einen gemeinsam genutzten, aktiven Master weniger fehleranfällig zu machen, bis wir auf die Entwicklung von Zweigen umstellen können?

Das Team verwendet Tortoise Git unter Windows. Wir verwenden Tortoise Git, weil wir zuvor Tortoise SVN verwendet haben. ( Ich persönlich benutze die Befehlszeile unter Cygwin für einige Operationen, aber das Team hat klargestellt, dass sie eine GUI benötigen, und wir werden diese verwenden.) Antworten sollten mit diesem Tool funktionieren, keine Ersetzungen vorschlagen.

Tortoise Git bietet "Commit & Push" als einzelne Operation an und ich habe ihnen geraten, dies immer zu tun. Es ist jedoch nicht atomar - es kann vorkommen, dass das Commit (das immerhin lokal ist) einwandfrei funktioniert, der Push jedoch nicht (z. B. aufgrund eines Konflikts oder eines Netzwerkproblems). In diesem Fall wird ein mehrdeutiger Fehler angezeigt. Ich habe ihnen geraten, das BitBucket-Commit-Protokoll zu überprüfen, wenn sie irgendwelche Zweifel an einem kürzlich erfolgten Commit haben, und zu pushen, wenn sie es nicht sehen. (Und um den Konflikt zu lösen, wenn das das Problem ist, oder um Hilfe zu bitten, wenn sie nicht wissen, was sie tun sollen.)

Das Team hat bereits die gute Angewohnheit, "früh und oft zu ziehen". Es scheint jedoch, dass Pull Konflikte verursachen kann, was ich für neu halte? Wenn nicht neu, viel häufiger als in SVN. Ich habe gehört, dass ich ändern kann, wie Git zieht (rebase statt merge), aber ich habe kein gutes Verständnis für die Kompromisse dort (oder wie man es in unserer Umgebung macht).

Der Server ist BitBucket (nicht Github). Ich habe die volle administrative Kontrolle über unser Repository, aber im Allgemeinen keine auf dem Server. Nichts davon ist veränderbar.

Die Quelldateien sind XML. Es gibt auch Grafikdateien, von denen jeder weiß, dass Sie sie nicht zusammenführen können, aber wir haben dort auch fast nie Kollisionen. Die Zusammenführungskonflikte stammen aus den XML-Dateien, nicht aus den Grafiken.

Welche Änderungen kann ich an unserer Verwendung von Git vornehmen, um den reibungslosen Ablauf des Master-Sharing für das Team zu gewährleisten, bis die Verwendung von Feature-Zweigen mit überprüften, testvalidierten Pull-Anforderungen möglich ist?

Bisher war SourceTree die beste IDE, um sich mit den Konzepten vertraut zu machen, da es alle relevanten Dialogfelder und Optionen auf jeder Stufe anzeigt. Die Standardoptionen sind normalerweise in Ordnung.

• Ziehen Sie vom Meister, um sicherzugehen, dass Sie auf dem neuesten Stand sind
• Ändern Sie Ihre Dateien
• Übernehmen Sie Ihre Änderungen (das ist nur lokal)
• Ziehen Sie erneut vom Master (dies führt dazu, dass Konflikte auftreten).
• Bearbeiten Sie alle Dateien, bis die Konflikte behoben sind. Dies bedeutet, dass sich die Datei im richtigen Status befindet, den Sie festschreiben möchten (keine <<<<< HEAD- und >>>> Master-Nachrichten in der Rohdatei).
• Übernehmen Sie die Zusammenführungsänderungen
• drücken

Wenn jeder dieses Rezept befolgt, sollte es ihm gut gehen.

Jedes Mal, wenn jemand eine größere oder zentrale Änderung vornimmt, informieren Sie die anderen Benutzer, dass sie sich lokal verpflichten und vom Master abrufen sollen, damit sie später nicht zu viele Konflikte bekommen und die erste Person immer noch da ist, um die Konflikte zusammen mit ihnen zu lösen.

Investieren Sie viel Zeit, um alle zu veranlassen, den Ablauf zu verstehen. Andernfalls könnten sie sich eine Weile zurechtfinden und sich beim eigentlichen Verschrauben des Hauptzweigs damit wohlfühlen. Zum Beispiel wird "Meine Datei anstelle von Remote verwenden", um einen Konflikt zu lösen, nur zum Scheitern verurteilt alle von anderen Personen vorgenommenen Änderungen

Git ist ein schwer zu erlernendes System, besonders wenn Sie mit Svn aufgewachsen sind, geduldig sind und ihnen Zeit geben, es richtig zu lernen. Mit neuen Benutzern können Sie manchmal einen Tag damit verbringen, Unordnung aufzuräumen, was normal ist. ;)

Es gibt drei wichtige Dinge, an die Sie denken sollten, wenn Sie in derselben Branche arbeiten wie jemand anderes:

• Verwenden --forceSie es nur , wenn Sie wirklich wissen, was Sie tun.
• Entweder commitoder stashdeine laufende Arbeit vor jeder pull.
• Normalerweise geht es einfacher, wenn Sie pulldirekt vor einem push.

Im Übrigen möchte ich darauf hinweisen, dass es bei der verteilten Versionskontrolle egal ist, ob Ihr "offizielles" Repo Filialen verwendet oder nicht. Dies hat keinerlei Einfluss darauf, was einzelne Benutzer in ihren lokalen Repos tun. Früher habe ich git verwendet, um lokale Niederlassungen zu erhalten, als mein Unternehmen ein völlig anderes zentrales VCS verwendete. Wenn sie lokale Zweige für ihre Features erstellen und Fehler mit ihren lokalen zusammenführen master, ist es viel einfacher, Fehler zu beheben, ohne auf das Reflog oder eine andere Magie einzugehen .

Kann sich jeder einen Tag Zeit nehmen, um Git zu lernen?

Von Computernutzern sollte erwartet werden, dass sie ein neues Tool erlernen, und obwohl es möglich ist, in jedem VCS viele Fehler zu machen, sollten sie das Tool so verwenden, wie es entwickelt wurde, um verwendet zu werden.

Der beste Weg, dies einzuführen, besteht darin, dass jeder an seinem eigenen Zweig arbeitet, wenn er eine Änderung vornimmt (so kurz wie möglich) und sich wieder zusammenfügt, wenn er fertig ist. Dies ist nicht allzu weit von der aktuellen Arbeitsweise entfernt und führt einen einfachen Workflow ein, an den sie sich gewöhnen können, bis sie sich sicher genug fühlen, kompliziertere Operationen auszuführen.

Ich benutze keine Fenster, aber wenn Tortoise im Grunde genommen GIT vor ihnen verbirgt und so tut, als wäre es SVN, dann ist Tortoise vielleicht das falsche Werkzeug.

Manchmal muss sich das, was Sie tun, ändern.

Das größte Problem ist , dass jeder ist auf Master arbeiten. Dies ist nicht typisch für die Codeentwicklung und könnte auch in Ihrem Fall das falsche Modell sein. Wenn Sie dies ändern können, indem Sie verlangen, dass Änderungen in separaten Zweigen vorgenommen werden, sind Sie in einer viel besseren Verfassung. Mit Zweigen können Sie Folgendes erreichen:

• Erzwinge, dass keine direkten Pushs mastererlaubt sind.
• Erzwingen Sie über Bitbucket, dass Pull-Anforderungen erstellt werden und vor dem Zusammenführen mindestens eine Genehmigung vorliegen . Dies stellt sicher, dass sich jemand die Änderungen ansieht, und macht die Zusammenführung selbst weniger schmerzhaft, da auf der Benutzeroberfläche Konflikte mit der Remoteversion des Codes angezeigt werden, unabhängig davon, was der Benutzer auf dem Desktop hat. Dies verhindert, dass das Szenario "Festschreiben erfolgreich, aber Push fehlgeschlagen" ausgeführt wird.
• Führen Sie vor dem Zusammenführen "Builds" für Ihr Repo aus. Mir ist klar, dass es sich um ein Doc-Repo handelt, aber vielleicht gibt es Rechtschreibprüfung, juristisches Scraping oder sogar automatisierte Übersetzung (STRING_DEF-Objekte in eine CSV-Datei exportieren), die aus diesem Build erstellt werden könnten. Oder vielleicht auch nicht, hängt von Ihrer Arbeit ab.
• Ermöglichen Sie es den Leuten, leichter an mehreren verschiedenen Dingen gleichzeitig zu arbeiten. Ja, das kann man auch mit Stashes machen, aber es ist ein bisschen chaotischer und irgendetwas sagt mir, dass Sie diese auch nicht benutzen.

Wenn Sie die Verzweigung nicht verwenden können, sollten Sie ein merge-and-pushSkript schreiben , mit dem einige der Probleme behoben werden können. Vielleicht würde es überprüfen, ob der Benutzer nicht hinter dem Master zurückliegt, einen Abruf durchführen und ziehen und dann die Zusammenführung ( möglicherweise mit--no-commit --no-ff ) versuchen und so weiter.

Betonen Sie, dass Sie Zusammenführungen wiederholen können

Es mag für Sie offensichtlich sein, aber ehemalige SVN-Benutzer sind sich möglicherweise nicht bewusst, dass sie versuchen können, eine Zusammenführung mehrmals zu lösen. Dies kann die Anzahl der von Ihnen empfangenen Hilfe-Flags verringern.

In SVN hätten trunkSie beim Abarbeiten von Änderungen nicht festgeschriebenes Herumsitzen. Dann würdest du eine svn update. An diesem Punkt würden sich Ihre Änderungen für immer mit den Änderungen anderer Personen vermischen. Es gab keine Möglichkeit, es rückgängig zu machen (afaik). Sie hatten also keine andere Wahl, als einfach alles manuell zu überprüfen und zu hoffen, dass sich das Repo in einem guten Zustand befand. Wenn Sie sich wirklich viel wohler fühlen, wiederholen Sie einfach die Zusammenführung.

Die Leute würden die gleiche Mentalität haben, auch wenn wir zum Schwitzen gingen. Dies führt zu vielen unbeabsichtigten Fehlern.

Glücklicherweise gibt es mit git einen Weg zurück, insbesondere weil Sie lokale Commits machen können. (Ich beschreibe später, wie dies in der Kommandozeile ausgedrückt wird)

Die Vorgehensweise hängt jedoch von den Werkzeugen ab. Ich finde, dass das Wiederherstellen eines Pulls in vielen GUIs nicht als einzelne Schaltfläche dargestellt wird, aber wahrscheinlich möglich ist. Ich mag dich benutze Cygwin. Meine Mitarbeiter verwenden Sourcetree. Da Sie BitBucket verwenden, ist es sinnvoll, dieses als GUI zu verwenden, da es von derselben Firma verwaltet wird: Atlassian. Ich vermute, es gibt eine engere Integration.

In Bezug auf zieht

Ich denke, Sie haben Recht, dass die Verschmelzung pulldie Leute durcheinander bringt. A ruft die Änderungen pulltatsächlich git fetchvom Server ab, gefolgt von git merge origin/<branchname>*, wodurch die Remote-Änderungen in Ihrer lokalen Zweigstelle zusammengeführt werden. ( https://git-scm.com/docs/git-pull )

Das Ergebnis ist, dass alle standardmäßigen Zusammenführungsbefehle mit pull arbeiten. Wenn bei dieser Zusammenführung Konflikte auftreten, können Sie den Vorgang abbrechen git merge --abort. Auf welche sollten Sie vor dem Zusammenführen zurückkehren? Dann können Sie es mit git pulloder erneut versuchen git merge origin/<branchname>.

Wenn Sie irgendwie lernen können, wie Sie die oben genannten Aufgaben mit dem GUI-Tool Ihrer Mitarbeiter erledigen können , werden die meisten Ihrer Probleme gelöst. Entschuldigung, ich kann nicht genauer sein.

* Ich verstehe, dass die Herkunft hier nicht immer der Fall ist.

Verwenden Sie git reflogdiese Option, um Probleme zu diagnostizieren

Ich muss wie Sie Probleme diagnostizieren, die meist durch den Missbrauch von GUI-Tools verursacht wurden. Ich finde, dass git reflogdies manchmal hilfreich sein kann, da dies eine ziemlich konsistente Liste von Aktionen im Repository darstellt. Obwohl es manchmal schwer zu lesen ist.

Eine Alternative

Da es sich um eine vorübergehende Situation handelt , können Sie einfach zu SVN zurückkehren, bis Sie den Prozess für die Einführung eingerichtet haben. Ich würde zögern, dies zu tun, da viele Orte sagen würden: "Wir haben es einmal versucht, aber es hat einfach nicht funktioniert ..." und es nie wirklich wieder aufgreifen.

Einige andere übliche Übergangsprobleme

• Die Leute löschten oft ihr Repo und klonen es erneut, weil sie überzeugt waren, dass ihr Repo in einem unbrauchbaren Zustand war. Normalerweise wurde dies dadurch verursacht, dass der lokale und der entfernte Unterschied aus den Augen verloren wurden. Sowohl die GUI-Tools als auch die CLI zeigen dies nicht gut an. In der CLI finde ich git log --decorateden einfachsten Weg, um die Unterschiede zu überblicken. Aber wenn es dem Meister (zum Beispiel) zu haarig wird, können Siegit reset --hard origin/master

Ein möglicher Mechanismus, dass viele Open - Source - Teams übernommen hat, ist das Forking Modell zu verwenden - https://www.atlassian.com/git/tutorials/comparing-workflows (achten Sie darauf , klar zu artikulieren , wenn ein Forking git Workflow diskutieren ) .

In diesem Fall hat jeder Entwickler oder jedes Sub-Team einen eigenen Zweig des Repositorys, den er aus BitBucket auscheckt. BitBucket stellt hierfür einen Mechanismus bereit , bei dem zusätzlich zur Standard-Remote ein "Upstream" -Ursprung festgelegt wird. Sie müssen sich daran erinnern, den Upstream abzurufen "und" Remote / Upstream / Master zusammenführen ".

Es wird möglicherweise Ihre Build-Mechanismus-Probleme lösen, da die Build-Tools möglicherweise auf den Master in einem anderen Projekt, dh dem Fork, verweisen.

Sie könnten dann den meisten Leuten die Möglichkeit nehmen, direkt auf das Master-Projekt zu pushen und so ein kleineres Team von Leuten zu bilden, die Rollen prüfen und genehmigen. Siehe https://www.atlassian.com/git/tutorials/making-a-pull-request

Der Ort, an dem Sie nachlesen können, ob vor dem Push-Vorgang so gut wie alle gewünschten Überprüfungen durchgeführt wurden, befindet sich im Abschnitt zum Git-Buch über Hooks ( https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks ). Sie können Pre-Commit- und Pre-Push-Hooks verwenden, um beispielsweise einige Tests für das vorgeschlagene Commit auszuführen, um sicherzustellen, dass die Arbeit gültig ist usw. - das einzige Problem bei clientseitigen Hooks besteht darin, dass Entwickler sie deaktivieren oder nicht aktivieren können Sie.

Beide vorgelagerten Fetch / Merge & Hooks sind in TortoiseGit verfügbar.

Das hört sich zwar nicht intuitiv an, hört mich aber an:

Ermutigen Sie sie, mit git zu experimentieren

Eines der interessanten Dinge an git ist, dass es überraschend einfach ist, einen lokalen Betrieb vollständig sicher zu machen. Als ich anfing, Git zu verwenden, war eines der Dinge, die ich tat , das ganze Verzeichnis als Backup zu zippen, falls ich etwas vermasselt habe. Ich habe später herausgefunden, dass dies ein riesiger Kludge ist und eigentlich fast nie notwendig ist, um Ihre Arbeit zu schützen, aber es hat den Vorteil, sehr sicher und sehr einfach zu sein, auch wenn Sie nicht wissen, was zum Teufel Sie tun und wie Der Befehl, den Sie versuchen möchten, wird sich herausstellen. Das einzige, was Sie vermeiden müssen, wenn Sie dies tun, ist push. Wenn Sie nichts pushen, ist dies eine 100% sichere Möglichkeit, alles auszuprobieren, was Sie wollen.

Die Angst, Dinge auszuprobieren, ist eines der größten Hindernisse für das Erlernen von Git. Es gibt Ihnen so viel Kontrolle über alles, dass es ein bisschen entmutigend ist. Die Realität ist, dass Sie sich für den Großteil Ihres täglichen Gebrauchs an ein paar sehr sichere Operationen halten können, aber es ist einiges zu erforschen, welche Befehle dies sind.

Indem sie ihnen ein Gefühl der Sicherheit geben , sind sie viel eher bereit, selbst herauszufinden, wie sie Dinge tun können. Und sie werden viel mehr die Möglichkeit haben, einen persönlichen Arbeitsablauf auf ihrem lokalen Computer zu finden, der für sie funktioniert. Und wenn nicht jeder die gleiche Sache tut lokal , das ist in Ordnung, solange sie auf Standards einhalten , was sie schieben . Wenn es erforderlich ist, das gesamte Repo zu komprimieren, bevor eine Operation durchgeführt wird, damit sie sich so fühlen, ist dies in Ordnung. Sie können auf bessere Weise Dinge erledigen, während sie gehen und Dinge ausprobieren. Alles, um sich dazu zu bringen, Dinge auszuprobieren und zu sehen, was sie bewirken.

Dies bedeutet nicht, dass Training wertlos ist. Im Gegenteil, Training kann Ihnen helfen, Merkmale, Muster und Normen kennenzulernen. Aber es ist kein Ersatz für Hinsetzen und tatsächlich tun Sachen in Ihrer täglichen Arbeit. Weder Git noch SVN sind Dinge, über die man einfach in eine Klasse gehen kann und von denen man dann alles weiß. Sie müssen sie verwenden , um Ihre Probleme zu lösen, um sich mit ihnen vertraut zu machen und welche Funktionen für welche Probleme gut geeignet sind.

Hören Sie auf, sie davon abzuhalten, die Vor- und Nachteile von GIT zu lernen

Ich erwähnte, nichts zu pushen, was tatsächlich gegen eines der Dinge verstößt, die Sie ihnen beigebracht haben: immer "Commit & Push". Ich glaube, Sie sollten aufhören, ihnen zu sagen, sie sollen das Gegenteil tun. Git hat grundsätzlich 5 "Stellen", an denen Ihre Änderungen vorgenommen werden können:

• Auf der Festplatte, nicht festgeschrieben
• Inszeniert, aber nicht verpflichtet
• In einem lokalen Commit
• In einem lokalen Versteck
• Remote-Repositorys (Es werden immer nur Commits und Tags zwischen verschiedenen Repositorys verschoben und abgerufen.)

Anstatt sie zu ermutigen, alles in einem Schritt zu ziehen und zu schieben, ermutigen Sie sie, diese 5 verschiedenen Orte zu nutzen. Ermutigen Sie sie,

• Holen Sie sich Änderungen, bevor sie etwas festschreiben.

• Treffen Sie eine Entscheidung, wie mit den abgerufenen Änderungen umgegangen werden soll. Optionen sind:

  • Übernehmen Sie die lokalen Änderungen und setzen Sie sie dann auf die abgerufenen Änderungen.
  • Übernehmen Sie die lokalen Änderungen und führen Sie dann eine Zusammenführung mit den abgerufenen Änderungen durch.

  • Verstecken Sie die Änderungen, führen Sie sie zusammen, heben Sie die Verankerung auf und lösen Sie alle Konflikte.

    Es gibt noch andere Sachen, aber ich werde hier nicht darauf eingehen. Beachten Sie, dass ein Pull im wahrsten Sinne des Wortes nur ein Abruf und eine Zusammenführung ist. Es ist nicht wie sie; es ist ihnen. ( --rebaseÄnderungen werden von fetch + merge nach fetch + rebase übertragen.)

• Stellen Sie ihre Änderungen in Szene und überprüfen Sie sie anschließend.
• Übernehmen Sie die bereitgestellten Änderungen, und überprüfen Sie dann das Commit.
• Separat schieben.

Dies wird sie ermutigen, ihre Arbeit zu überprüfen, bevor sie öffentlich zugänglich gemacht wird, was bedeutet, dass sie ihre Fehler früher abfängt. Sie werden sehen , die begehen und denken : „Warten Sie, das ist nicht das, was ich wollte“ , und im Gegensatz zu SVN, können sie gehen zurück und versuchen Sie es erneut , bevor sie schieben.

Sobald sie sich an die Idee gewöhnt haben, zu verstehen, wo sich ihre Änderungen befinden, können sie entscheiden, wann sie Schritte überspringen und bestimmte Operationen kombinieren sollen (wann sie ziehen sollen, weil Sie bereits wissen, dass Sie Fetch + Merge möchten oder wann sie auf diese Commit & Push-Option klicken müssen). .

Dies ist einer der enormen Vorteile von git gegenüber SVN, und git wurde unter Berücksichtigung dieses Verwendungsmusters entwickelt. Im Gegensatz dazu geht SVN von einem zentralen Repository aus. Daher ist es nicht verwunderlich, wenn die Tools für Git nicht für denselben Workflow optimiert sind. Wenn Ihr Commit in SVN falsch ist, können Sie nur ein neues Commit durchführen, um den Fehler rückgängig zu machen.

Dies zu tun wird natürlich zur nächsten Strategie führen:

Ermutigen Sie sie, lokale Niederlassungen zu nutzen

Lokale Niederlassungen erleichtern die Arbeit an gemeinsam genutzten Dateien erheblich. Ich kann alle Änderungen, die ich möchte, in meiner eigenen Branche vornehmen, und es wird niemanden betreffen, da ich sie nicht vorantreibe. Wenn es dann soweit ist, kann ich alle die gleichen Merge- und Rebase-Strategien verwenden, nur einfacher:

• Ich kann meine lokale Niederlassung neu gründen, was das Zusammenführen zu einer trivialen Angelegenheit macht.
• Ich könnte ein einfaches Zusammenführen (Erstellen eines neuen Commits) in master verwenden, um die Änderungen meiner lokalen Niederlassung in das Commit zu übernehmen.
• Ich kann meine gesamte lokale Niederlassung zu einem einzigen Commit für Master zusammenfassen, wenn ich der Meinung bin, dass meine Niederlassung zu chaotisch ist, um sie zu retten.

Die Verwendung lokaler Niederlassungen ist auch ein guter Anfang, um eine systematische Verzweigungsstrategie zu entwickeln. Es hilft Ihren Benutzern, die eigenen Verzweigungsanforderungen besser zu verstehen, sodass Sie eine Strategie auswählen können, die auf den Anforderungen und dem aktuellen Verständnis- / Fähigkeitsniveau des Teams basiert und nicht nur in Gitflow vorbeischaut, weil jeder davon gehört hat.

Zusammenfassung

Kurz gesagt, Git ist kein SVN und kann nicht so behandelt werden. Du musst:

• Beseitigen Sie die Angst, indem Sie zum sicheren Experimentieren ermutigen.
• Helfen Sie ihnen zu verstehen, wie sich git unterscheidet, damit sie sehen können, wie sich dadurch ihr normaler Arbeitsablauf ändert.
• Helfen Sie ihnen, die verfügbaren Funktionen zu verstehen, damit sie ihre Probleme leichter lösen können.

Dies alles hilft Ihnen dabei , die Nutzung von Git schrittweise zu verbessern, bis Sie den Punkt erreicht haben, an dem Sie mit der Implementierung einer Reihe von Standards beginnen können.

Spezielle Eigenschaften

Auf kurze Sicht könnten die folgenden Ideen hilfreich sein.

Rebase

Sie haben Rebase erwähnt und dass Sie es in Ihrer Frage nicht wirklich verstehen. Also hier ist mein Rat: Probieren Sie aus, was ich gerade beschrieben habe. Nehmen Sie einige Änderungen lokal vor, während eine andere Person Änderungen vornimmt. Übernehmen Sie Ihre Änderungen lokal . Packen Sie Ihr Repository-Verzeichnis als Backup. Holen Sie sich die Änderungen der anderen Person. Führen Sie jetzt einen Rebase-Befehl aus und sehen Sie, was mit Ihren Commits passiert! Sie können endlose Blog-Posts lesen oder Schulungen zu Rebase erhalten und wie Sie es verwenden sollten oder nicht, aber nichts davon ist ein Ersatz dafür, es live in Aktion zu sehen. Also probieren Sie es aus.

merge.ff=only

Dies wird eine Frage des persönlichen Geschmacks sein, aber ich werde es zumindest vorübergehend empfehlen, da Sie bereits erwähnt haben, dass Sie Probleme mit der Konfliktbehandlung haben. Ich empfehle Einstellung merge.ffzuonly :

git config --global merge.ff only

"ff" steht für "Schnellvorlauf". Eine schnelle Zusammenführung ist, wenn git Änderungen von verschiedenen Commits nicht kombinieren muss. Der Zeiger des Zweigs wird einfach auf eine neue Festschreibung entlang einer geraden Linie im Diagramm verschoben.

In der Praxis verhindert dies, dass Git jemals automatisch versucht, Merge-Commits zu erstellen. Wenn ich also lokal ein Commit durchführe und dann die Änderungen anderer Personen übernehme, anstatt zu versuchen, ein Merge-Commit zu erstellen (und den Benutzer möglicherweise zur Bewältigung von Konflikten zu zwingen), schlägt das Merge einfach fehl. Tatsächlich hat git nur a ausgeführt fetch. Wenn Sie keine lokalen Commits haben, wird die Zusammenführung normal fortgesetzt.

Auf diese Weise können Benutzer Benutzer die verschiedenen Festschreibungen überprüfen, bevor sie versuchen, sie zusammenzuführen, und sie zwingen, eine Entscheidung darüber zu treffen, wie sie am besten kombiniert werden sollen. Ich kann zurückgreifen, mit dem Zusammenführen fortfahren ( git merge --no-ffum die Konfiguration zu umgehen), oder ich kann sogar das Zusammenführen meiner Änderungen für den Moment aufschieben und später erledigen. Ich denke, dieser kleine Geschwindigkeitsschub wird Ihrem Team helfen, die falschen Entscheidungen über Zusammenschlüsse zu vermeiden. Sie können Ihr Team deaktivieren lassen, sobald es die Zusammenführung besser beherrscht.

Ich habe genau das gleiche SVN -> Git-Erlebnis in meiner Firma durchlaufen und aus meiner Erfahrung heraus ist das einzige Heilmittel Zeit. Lassen Sie sich an die Werkzeuge gewöhnen, Fehler machen und zeigen, wie man sie behebt. Ihre Geschwindigkeit wird für eine Weile leiden, und die Leute werden die Arbeit verlieren, und jeder wird ein bisschen nervös sein, aber das ist die Natur, etwas so grundlegendes wie Ihr VCS zu ändern.

Trotzdem stimme ich allen zu, die der Meinung sind, dass TortoiseGit so früh in der Übergangsphase eher ein Hindernis als eine Hilfe ist. TortoiseGit ist ... im besten Fall keine großartige GUI. Indem Sie im Namen der Einfachheit verdecken, wie GIT tatsächlich funktioniert, verhindern Sie auch, dass Ihre Mitarbeiter ein Verständnis für grundlegende GIT-Konzepte wie das Zwei-Phasen-Commit erlangen.

Wir haben die (ziemlich drastische) Entscheidung getroffen, Entwickler zu zwingen, eine Woche lang die Befehlszeile (git bash oder posh-git ) zu verwenden, und das hat Wunder gewirkt, um zu verstehen, wie git tatsächlich funktioniert und wie es sich von SVN unterscheidet. Es mag drastisch klingen, aber ich schlage vor, Sie probieren es einfach aus, weil es dieses Verständnis für das Git-Modell schafft - und sobald sie das nicht mehr haben, können Ihre Mitarbeiter damit beginnen, beliebige GUI-Fassaden über Git zu verwenden, die sie mögen.

Schlussbemerkung: Es wird einige Ihrer Mitarbeiter geben, die beinahe sofort befürchten, wie Schwachsinn funktioniert, und es wird einige geben, die es niemals tun werden. Bei der letzteren Gruppe müssen Sie nur die mystischen Beschwörungsformeln lernen, damit der Code von Ihrem lokalen Computer auf den Server gelangt, damit jeder ihn sehen kann.

Nun, kürzlich habe ich den folgenden Workflow angepasst, um den Master-Zweig niemals zu füllen:

1) Jeder verwendet seine eigene Filiale, die in der Regel eine Kopie der Master-Filiale ist.

Nennen wir den Master-Zweig "master" und meinen eigenen Zweig "my_master".

Ich habe gerade meinen Zweig vom Meister gemacht, also ist es genau das gleiche. Ich beginne in meinem eigenen Zweig an einer neuen Funktion zu arbeiten, und wenn dies erledigt ist, gehe ich wie folgt vor.

Aktuell auf meinem Zweig, gerade mit dem Programmieren fertig

git add . && git commit -m "Message" && git push

Kehren Sie zum Hauptzweig zurück

git checkout master

Ziehen Sie, wenn es nicht aktuell ist

git pull

Geh zurück zu meiner eigenen Filiale

git checkout my_master

Füge den neuesten Master zu meiner eigenen Filiale hinzu

git merge master

Beheben von Konflikten und Zusammenführungen

Teste alles nochmal

Wenn alles in meinem eigenen Zweig zusammengeführt und repariert ist, schieben Sie es

git push

Kehren Sie zum Hauptzweig zurück

git checkout master

Mit meiner Filiale verschmelzen

git merge my_master

Konflikte können nicht auftreten, da sie in Ihrer eigenen Filiale durch vorherige Zusammenführung behoben wurden

Meister schieben

git push

Wenn dies von allen befolgt wird, ist der Hauptzweig sauber.

Wir haben also ein Team, das von TFS zu Git gewechselt ist und die alten Denkweisen beibehalten hat. Die allgemeinen Betriebsregeln sind mehr oder weniger gleich.

Ja, das bedeutet, dass jeder am Meister arbeitet. Das ist nicht so schlimm; und ein Team, das an TFS oder SVN gewöhnt ist, wird dies am natürlichsten finden.

Allgemeine Verfahren, um dies so schmerzfrei wie möglich zu gestalten:

1. git stash && git pull --rebase && git stash popjeden Morgen tun
2. Früh und oft ein Commit durchführen (muss nicht sofort gepusht werden; wir können zumindest diesen Vorteil von git frühzeitig nutzen)

3. Zum Drücken die folgende Schleife ausführen:

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Wenn alle am Master arbeiten, können Sie nichts tun. Die Dinge werden unweigerlich durcheinander geraten.

Sie sollten master für fertige Produkte verwenden, die an einen Kunden gesendet werden. Sie sollten die Entwicklung für die Weiterentwicklung nutzen, und Sie sollten nicht jemand Entwicklung schieben lassen. Der Standard ist, dass jeder von dev verzweigt, seine Änderungen vornimmt, sie von lokal zu seinem Zweig auf dem Server pusht und eine Push-Anfrage ausgibt. Dann überprüft jemand die Änderung und führt sie in die Entwicklung ein.

Um Konflikte zu vermeiden, führt jeder die Entwicklung vor dem Push in seinem eigenen Zweig zusammen und löst Konflikte in dieser Phase (sodass nur ein Entwickler vor Ort betroffen ist). Wenn das Zusammenführen in die Entwicklung zu Konflikten führen würde, wird es nicht zusammengeführt. Der Entwickler führt die Entwicklung erneut in seinem Zweig zusammen und schiebt sie erneut auf den Server. Anschließend wird es erneut überprüft.

Sie können Sourcetree zum Beispiel verwenden, um diese Arbeit ohne Schmerzen zu machen.