it-swarm.com.de

Wie kann ich Git-Schmerzen minimieren, wenn alle am Master arbeiten?

Unser Dokumentationsteam von ungefähr zehn Personen 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 bewirken. Im Rahmen der Umstellung auf Git haben wir vereinbart, dies zu beheben, können dies jedoch noch nicht tun (wir warten auf Build-Änderungen, die Builds aus beliebigen Zweigen ermöglichen). In der Zwischenzeit arbeiten alle am Master. Ja, ich weiß, das ist schrecklich, glauben Sie mir.

Wir sehen 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 verpflichten sich die Leute, drücken aber nicht, oder sie ziehen und bekommen Konflikte mit ihren anstehenden lokalen Änderungen. Gestern hat jemand die letzten Änderungen - irgendwie - mit einer fehlgeschlagenen Zusammenführung blockiert. Ich denke, das war die Zusammenführung, die Git durchführt, wenn Sie ziehen und herausragende Änderungen vornehmen. (Er konnte mir nicht genau sagen, was er getan hat, und weil er eine grafische Benutzeroberfläche verwendet, kann ich nicht einfach seine Shell-Historie überprüfen.)

Als der kompetenteste Git-Benutzer (lesen Sie: Ich habe es schon einmal verwendet, aber nicht für etwas sehr Kompliziertes) bin ich die Person, die Richtlinien festlegt, die Tools lehrt und Unordnung beseitigt. Welche Änderungen kann ich an der Verwendung der Tools vornehmen, um einen gemeinsam genutzten, aktiven Master weniger fehleranfällig zu machen, bis wir zur Entwicklung in Zweigen wechseln können?

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

Tortoise Git hat "Commit & Push" als einzelne Operation verfügbar und ich habe ihnen gesagt, dass sie das immer tun sollen. 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 erhalten sie einen mehrdeutigen Fehler. Ich habe ihnen gesagt, sie sollen das BitBucket-Commit-Protokoll überprüfen, wenn sie irgendwelche Zweifel an einem kürzlich durchgeführten Commit haben, und, falls sie es nicht sehen, Push. (Und um den Konflikt zu lösen, wenn dies 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 bei 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 es in unserer Umgebung gemacht wird).

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

Die Quelldateien sind XML. Es gibt auch Grafikdateien, von denen jeder weiß, dass sie nicht zusammengeführt werden können, aber wir haben dort 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, damit der Sharing Master für das Team reibungsloser verläuft, bis wir Feature-Zweige mit überprüften, testvalidierten Pull-Anforderungen verwenden können?

126
Monica Cellio

Bisher war SourceTree das beste IDE, um die Konzepte zu erlernen, da es alle relevanten Dialoge und Optionen zeigt, die Sie auf jeder Stufe haben. Die Standardoptionen sind normalerweise in Ordnung. Spielen Sie nicht mit Rebase herum usw. Folgen Sie einfach dem normalen Fluss:

  • Ziehen Sie vom Master, nur 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 zu Konflikten).
  • Bearbeiten Sie alle Dateien, bis die Konflikte behoben sind. Dies bedeutet, dass sich die Datei im richtigen Zustand 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 gemeinsam mit ihnen zu lösen.

Investieren Sie viel Zeit, um alle dazu zu bringen, den Ablauf zu verstehen. Andernfalls kann es eine Weile dauern, bis sie sich damit wohl fühlen, während sie den Hauptzweig tatsächlich verschrauben. Beispiel: "Meine Datei anstelle der Fernbedienung verwenden", um einen Konflikt zu lösen, ist nur ein Kick alle Änderungen, die von anderen Personen vorgenommen wurden.

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, etwas Chaos zu beseitigen, was normal ist. ;)

11
Mike M.

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

  • Benutze niemals --force es sei denn, Sie wissen wirklich , was Sie tun.
  • Entweder commit oder stash Ihre laufenden Arbeiten vor jedem pull.
  • Es ist normalerweise einfacher, wenn Sie pull direkt vor einem Push.

Abgesehen davon werde ich darauf hinweisen, dass es bei der verteilten Versionskontrolle keine Rolle spielt, ob Ihr "offizielles" Repo Zweige 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 meine Firma ein völlig anderes zentrales VCS verwendete. Wenn sie lokale Zweige für ihre Features erstellen und Fehler beim Zusammenführen mit ihrem lokalen master machen, ist es viel einfacher, dies zu beheben, ohne auf das Reflog oder eine andere Magie einzugehen.

98
Karl Bielefeldt

Ist es möglich, dass jeder einen Tag braucht, um Git zu lernen?

Von Fachleuten, die Computer verwenden, sollte wirklich erwartet werden, dass sie ein neues Tool erlernen. Obwohl es möglich ist, in jedem VCS viele Fehler zu machen, sollten sie das Tool so verwenden, wie es für die Verwendung vorgesehen ist.

Der beste Weg, dies einzuführen, besteht darin, jeden dazu zu bringen, an seinem eigenen Zweig zu arbeiten, wenn er eine Änderung vornimmt (so kurz wie möglich), und die Basis neu zu erstellen, 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, um kompliziertere Vorgänge auszuführen.

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

67
MarkJL

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

Das größte Problem ist, dass jeder ist am Master arbeitet. 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/verlangen, dass Änderungen an separaten Zweigen vorgenommen werden, sind Sie in einer viel besseren Verfassung. Mit Zweigen können Sie Folgendes erzielen:

  • Erzwingen Sie, dass keine Pushs direkt an master zulässig sind.
  • Erzwingen Sie durch Bitbucket, dass Pull-Anforderungen werden erstellt und haben vor dem Zusammenführen mindestens eine Genehmigung . Dies stellt sicher, dass jemand die Änderungen betrachtet, und macht das Zusammenführen selbst weniger schmerzhaft, da die Benutzeroberfläche Konflikte mit der Remote-Version des Codes anzeigt, nicht mit dem, was der Benutzer auf dem Desktop hat. Dies verhindert das Szenario "Commit erfolgreich, aber Push fehlgeschlagen".
  • 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, legales Scraping oder sogar automatisierte Übersetzung (Export von STRING_DEF-Dingen in eine CSV-Datei), die aus diesem Build erstellt werden könnte. Oder vielleicht auch nicht, hängt von Ihrer Arbeit ab.
  • Ermöglichen Sie es den Leuten, einfacher an mehreren verschiedenen Dingen gleichzeitig zu arbeiten. Ja, das kann auch mit Stashes gemacht werden, aber es ist etwas chaotischer und irgendetwas sagt mir, dass Sie diese auch nicht verwenden.

Wenn Sie keine Verzweigung verwenden können , können Sie ein merge-and-Push - Skript schreiben, das einige der Schwachstellen beseitigen kann. Vielleicht würde es überprüfen, ob der Benutzer auf dem Master nicht im Rückstand ist, ein Abrufen und Ziehen durchführen und dann die Zusammenführung versuchen ( möglicherweise mit --no-commit --no-ff ) und so weiter.

26
Dan1701

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

Es mag für Sie offensichtlich sein, aber ehemalige SVN-Benutzer wissen möglicherweise nicht, dass sie versuchen können, eine Zusammenführung mehrmals zu lösen. Dies kann die Anzahl der Hilfeflags verringern, die Sie erhalten.

Wenn Sie in SVN an trunk arbeiten, werden Änderungen nicht festgeschrieben. Dann würden Sie einen svn update Machen. An diesem Punkt würden sich Ihre Veränderungen für immer mit den Veränderungen anderer Menschen vermischen. Es gab keine Möglichkeit, es rückgängig zu machen (afaik), also hatten Sie keine andere Wahl, als einfach alles manuell zu überprüfen und zu hoffen, dass das Repo in einem guten Zustand war. Wenn Sie sich wirklich viel wohler fühlen, wiederholen Sie einfach die Zusammenführung.

Die Leute würden die gleiche Mentalität haben, selbst wenn wir zu Git wechseln würden. 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 angezeigt wird, aber wahrscheinlich möglich ist. Ich mag es, wenn du Cygwin benutzt. Meine Mitarbeiter verwenden Sourcetree. Da Sie BitBucket verwenden, ist es sinnvoll, dies 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 Zusammenführung in pull die Leute durcheinander bringt. Ein pull ist tatsächlich git fetch, Das die Änderungen vom Server abruft, gefolgt von git merge Origin/<branchname> *, Das die Remote-Änderungen in Ihrem lokalen Zweig zusammenführt. ( https://git-scm.com/docs/git-pull )

Das Ergebnis ist, dass alle Standard-Zusammenführungsbefehle mit Pull arbeiten. Wenn diese Zusammenführung Konflikte aufweist, können Sie mit git merge --abort Abbrechen. Was Sie vor Ihrer Zusammenführung zurückbringen sollte. Dann können Sie es entweder mit git pull Oder git merge Origin/<branchname> Erneut versuchen.

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

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

Verwenden Sie git reflog, Um Probleme zu diagnostizieren

Ich muss wie Sie Probleme diagnostizieren, die hauptsächlich durch den Missbrauch von GUI-Tools entstehen. Ich finde, dass git reflog Manchmal hilfreich sein kann, da dies eine ziemlich konsistente Spur von Aktionen im Repository ist. Obwohl es manchmal schwer zu lesen ist.

Eine Alternative

Da Ihre Situation vorübergehend ist, können Sie einfach zu SVN zurückkehren, bis der Prozess zum Rollout eingerichtet ist. Ich würde zögern, dies zu tun, da viele Orte weiterhin sagten: "Wir haben es einmal mit Git versucht, aber es hat einfach nicht funktioniert ..." und es nie wirklich wieder aufgreifen.

Einige andere häufige Übergangsprobleme

  • Die Leute löschten und reklonierten oft ihr Repo, weil sie davon überzeugt waren, dass sich ihr Repo in einem unbrauchbaren Zustand befand. 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. In der CLI finde ich git log --decorate Den einfachsten Weg, um die Unterschiede zu überblicken. Aber wenn es beim Master zu haarig wird (zum Beispiel), können Sie git reset --hard Origin/master
12
jmathew

Ein möglicher Mechanismus, den viele Open-Source-Teams übernommen haben, ist die Verwendung des Forking-Modells - https://www.atlassian.com/git/tutorials/comparing-workflows ( Stellen Sie sicher, dass Sie dies klar ausdrücken, wenn Sie einen Forking-Git-Workflow besprechen.).

In diesem Fall hat jeder Entwickler oder jedes Subteam seine eigene Abzweigung des Repositorys, aus dem sie auschecken BitBucket bietet hierfür einen Mechanismus, zusätzlich zur Standardfernbedienung einen "Upstream" -Ursprung festlegen - sie müssen daran denken, regelmäßig "Upstream abzurufen" und "Remote/Upstream/Master zusammenzuführen".

Dies wird möglicherweise Ihre Probleme mit dem Erstellungsmechanismus lösen, da die Erstellungswerkzeuge möglicherweise auf den Master in einem anderen Projekt, d. H. Der Verzweigung, gerichtet sind.

Sie könnten dann den meisten Personen die Möglichkeit nehmen, direkt auf das Masterprojekt zu pushen, und daraus ein kleineres Team von Personen mit Überprüfungs- und Genehmigungsrollen machen. Siehe https://www.atlassian.com/git/tutorials/making-a-pull-request

Der Ort, an dem Sie nachlesen können, ob vor dem Push fast alle wünschenswerten Überprüfungen durchgeführt werden, finden Sie im Abschnitt zum Git-Buch unter 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 durchzuführen, um sicherzustellen, dass die Arbeit gültig ist usw. - Das einzige Problem bei clientseitigen Hooks sind Entwickler kann sie deaktivieren oder nicht aktivieren.

Sowohl Upstream-Fetch/Merge als auch Hooks sind in TortoiseGit verfügbar.

8
Steve Barnes

Das klingt nicht intuitiv, aber hör mir zu:

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 gesamte Verzeichnis komprimieren als Backup für den Fall, dass ich etwas vermasselt habe. Ich habe später herausgefunden, dass dies ein enormer Aufwand ist und fast nie notwendig ist, um Ihre Arbeit zu schützen, aber es hat den Vorteil, sehr sicher und sehr einfach zu sein , selbst wenn Sie nicht wissen, was zum Teufel Sie tun und wie der Befehl, den Sie versuchen möchten, ausfällt. 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 dir so viel Kontrolle über alles, was irgendwie entmutigend ist. Die Realität ist, dass Sie sich für den größten Teil Ihres täglichen Gebrauchs an einige sehr sichere Vorgänge halten können. Um herauszufinden, welche Befehle dies sind, müssen Sie jedoch einige Untersuchungen durchführen.

Indem sie ihnen ein Gefühl von Sicherheit geben , sind sie viel eher bereit, herauszufinden, wie sie Dinge selbst tun können. Und sie werden weitaus mehr in der Lage sein, auf ihrem lokalen Computer einen persönlichen Arbeitsablauf zu finden, der für sie funktioniert. Und wenn nicht jeder das Gleiche tut lokal, ist das in Ordnung, solange sie sich an Standards halten, mit denen sie Push. Wenn Sie das gesamte Repo komprimieren müssen, bevor Sie eine Operation ausführen, damit sie sich so fühlen, ist das in Ordnung. Sie können bessere Wege finden, um Dinge zu tun, während sie gehen und Dinge ausprobieren. Alles, um sich selbst zum Starten zu bringen versuchen Zeug und sehen, was es tut.

Dies bedeutet nicht, dass Training wertlos ist. Im Gegenteil, Schulungen können Ihnen helfen, Funktionen, Muster und Normen kennenzulernen. Aber es ist kein Ersatz für das Sitzen und eigentlich tun Zeug in Ihrer täglichen Arbeit. Weder Git noch SVN sind Dinge, über die man einfach in eine Klasse gehen kann und über die man dann alles weiß. Sie müssen 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ör 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, dass sie dies tun sollen, und ihnen sagen, dass sie das Gegenteil tun sollen. Git hat im Grunde 5 "Stellen", an denen Ihre Änderungen sein 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 gezogen.)

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

  • Rufen Sie Änderungen ab, bevor sie etwas festschreiben.
  • Treffen Sie eine Entscheidung wie mit den abgerufenen Änderungen umzugehen ist. Optionen sind:

    • Übernehmen Sie ihre lokalen Änderungen und setzen Sie sie dann zusätzlich zu den abgerufenen Änderungen neu.
    • Übernehmen Sie die lokalen Änderungen und führen Sie dann eine Zusammenführung mit den abgerufenen Änderungen durch.
    • Verstecken Sie ihre Änderungen, führen Sie sie zusammen, lösen Sie sie und lösen Sie alle Konflikte.

      Es gibt noch andere Sachen, aber ich werde hier nicht darauf eingehen. Beachten Sie, dass ein Pull wörtlich nur ein Abruf und eine Zusammenführung ist. Es ist nicht wie sie; es ist sie. (Vorbeigehen --rebase ändert Pull von Fetch + Merge zu Fetch + Rebase.)

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

Dies wird sie ermutigen, ihre Arbeit zu überprüfen vorher Sie wird allen öffentlich zugänglich gemacht, was bedeutet, dass sie ihre Fehler früher erkennen. Sie werden das Commit sehen und denken: "Warte, das ist nicht das, was ich wollte", und anders als in SVN können sie zurück und es erneut versuchen, bevor sie pushen.

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

Dies ist tatsächlich einer der enormen Vorteile von git gegenüber SVN, und git ist entworfen unter Berücksichtigung dieses Verwendungsmusters. Im Gegensatz dazu geht SVN von einem zentralen Repository aus. Daher ist es nicht verwunderlich, wenn das Tool für Git nicht für denselben Workflow optimiert ist. Wenn in SVN Ihr Commit falsch ist, ist Ihr einziger wirklicher Rückgriff ein neues Commit, um den Fehler rückgängig zu machen.

Dies führt natürlich zur nächsten Strategie:

Ermutigen Sie sie, local Zweige zu verwenden

Lokale Zweige lindern tatsächlich viele Probleme bei der Arbeit an gemeinsam genutzten Dateien. Ich kann alle gewünschten Änderungen in meinem eigenen Zweig 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 meinen lokalen Zweig neu gründen, was das Zusammenführen mit dem Master trivial macht.
  • Ich könnte eine einfache Zusammenführung (Erstellen eines neuen Commits) im Master verwenden, um die Änderungen meiner lokalen Niederlassung in diese zu übernehmen.
  • Ich kann meinen gesamten lokalen Zweig zu einem einzigen Commit für den Master zusammenführen, wenn ich denke, dass mein Zweig zu chaotisch ist, um ihn zu retten.

Die Verwendung lokaler Niederlassungen ist auch ein guter Anfang, um eine systematische Verzweigungsstrategie zu entwickeln. Es hilft Ihren Benutzern, ihre eigenen Verzweigungsbedürfnisse besser zu verstehen, sodass Sie eine Strategie auswählen können, die auf den Bedürfnissen und dem aktuellen Verständnis/Können des Teams basiert, und nicht nur Gitflow einbinden, weil jeder davon gehört hat.

Zusammenfassung

Kurz gesagt, Git ist keine SVN und kann nicht so behandelt werden. Du brauchst:

  • Beseitigen Sie die Angst, indem Sie sicheres Experimentieren fördern.
  • Helfen Sie ihnen zu verstehen, wie sich Git unterscheidet, damit sie sehen können, wie sich dadurch ihr normaler Workflow ändert.
  • Helfen Sie ihnen, die verfügbaren Funktionen zu verstehen, damit sie ihre Probleme leichter lösen können.

Dies alles wird Ihnen helfen, schrittweise eine bessere Git-Nutzung zu erreichen, bis Sie den Punkt erreichen, an dem Sie mit der Implementierung einer Reihe von Standards beginnen können.

Spezielle Features

Kurzfristig könnten die folgenden Ideen hilfreich sein.

Rebase

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

merge.ff=only

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

git config --global merge.ff only

"ff" steht für "schneller Vorlauf". Eine schnelle Vorwärtszusammenführung liegt vor, wenn git keine Änderungen aus verschiedenen Commits kombinieren muss. Der Zeiger des Zweigs wird nur entlang einer geraden Linie im Diagramm auf ein neues Commit verschoben.

In der Praxis wird dadurch verhindert, dass Git jemals automatisch versucht, Zusammenführungs-Commits zu erstellen. Wenn ich also etwas lokal festschreibe und dann die Änderungen eines anderen abrufe, anstatt zu versuchen, ein Zusammenführungs-Commit zu erstellen (und den Benutzer möglicherweise zu Konflikten zu zwingen), schlägt die Zusammenführung einfach fehl. Tatsächlich hat git nur ein fetch ausgeführt. Wenn Sie keine lokalen Commits haben, wird die Zusammenführung normal fortgesetzt.

Dies gibt Benutzern die Möglichkeit, die verschiedenen Commits zu überprüfen, bevor sie versuchen, sie zusammenzuführen, und zwingt sie, eine Entscheidung zu treffen darüber, wie sie am besten kombiniert werden können. Ich kann neu zusammenfassen und mit dem Zusammenführen fortfahren (mit git merge --no-ff, um die Konfiguration zu umgehen), oder ich kann das Zusammenführen meiner Änderungen vorerst einfach verschieben und später bearbeiten. Ich denke, diese kleine Geschwindigkeitsbegrenzung wird Ihrem Team helfen, die falschen Entscheidungen über Zusammenschlüsse zu vermeiden. Sie können Ihr Team ausschalten lassen, sobald es die Zusammenführung besser beherrscht.

3
jpmc26

Ich habe genau die gleiche SVN -> Git-Erfahrung in meinem Unternehmen gemacht und meiner Erfahrung nach ist das einzige Mittel die Zeit. Lassen Sie die Leute sich an die Werkzeuge gewöhnen, lassen Sie sie Fehler machen und zeigen Sie ihnen, wie sie diese beheben können. Ihre Geschwindigkeit wird für eine Weile leiden und die Leute werden die Arbeit verlieren und jeder wird ein bisschen gereizt 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 es im Namen der Einfachheit verdeckt, wie Git tatsächlich funktioniert, verhindert es auch, dass Ihre Mitarbeiter die wichtigsten Git-Konzepte wie das Zwei-Phasen-Commit verstehen.

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 funktioniert unterscheidet sich von SVN. Es mag drastisch klingen, aber ich würde vorschlagen, dass Sie es einfach versuchen, weil es das Verständnis des Git-Modells schafft - und sobald sie das nicht mehr haben, können Ihre Mitarbeiter beginnen, beliebige GUI-Fassaden über Git zu verwenden, die sie mögen.

Schlussbemerkung: Es wird einige Ihrer Mitarbeiter geben, die fast sofort wissen, wie Git funktioniert, und es wird einige geben, die es niemals tun werden. Bei der letzteren Gruppe müssen Sie nur die mystischen Beschwörungsformeln beibringen, damit der Code von ihrem lokalen Computer auf den Server übertragen wird, damit jeder ihn sehen kann.

2
Ian Kemp

Nun, kürzlich habe ich den folgenden Workflow angepasst, um den Hauptzweig nie zu ficken:

1) Jeder verwendet seinen eigenen Zweig, der ursprünglich eine Kopie des Hauptzweigs ist.

Nennen wir den Hauptzweig "master" und meinen eigenen Zweig "my_master".

Ich habe gerade meinen Zweig vom Meister gemacht, also ist es genau das gleiche. Ich beginne mit der Arbeit an einer neuen Funktion in meinem eigenen Zweig. Wenn dies erledigt ist, gehe ich wie folgt vor.

Derzeit auf meinem Zweig, gerade fertig codiert

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

Gehen Sie zurück zum Hauptzweig

git checkout master

Ziehen, wenn es nicht aktuell ist

git pull

Geh zurück zu meiner eigenen Filiale

git checkout my_master

Führen Sie den neuesten Master in meiner eigenen Niederlassung zusammen

git merge master

Beheben Sie Konflikte und Zusammenführungen

Testen Sie alles noch einmal

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

git Push

Gehen Sie zurück zum Hauptzweig

git checkout master

Mit meiner Filiale zusammenführen

git merge my_master

Konflikte können nicht auftreten, da sie in Ihrem eigenen Zweig mit vorheriger Zusammenführung gelöst werden

Master drücken

git Push

Wenn alle dies befolgen, ist der Hauptzweig sauber.

1
TanguyB

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 Master 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 machen:

  1. tun git stash && git pull --rebase && git stash pop jeden Morgen
  2. früh und oft verpflichten (müssen nicht sofort pushen; wir können zumindest früh anfangen, diesen Vorteil von git zu 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.

0
Joshua