Wie kann ich die Schmerzen minimieren, wenn alle am Meister arbeiten?

123

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?

Monica Cellio
quelle
52
Verwenden Sie keine Schildkröte, sondern Git Extensions. Tortoise versucht zu verbergen, dass Git kein SVN ist und zerstört den größten Teil der Git-Größe. Ich habe die SVN-> Git-Umstellung zweimal durchgearbeitet, und die Git-Erweiterung war ein großartiges Werkzeug, um die Leute zum Nachdenken zu bewegen.
Wilbert
91
Git ist kein SVN. Wenn Sie versuchen, SVN mit Git zu replizieren, erhalten Sie nur alle Schmerzpunkte von SVN mit allen Schmerzpunkten von Git zusammen, ohne die Vorteile von beidem, es wird einfach nie funktionieren. Das größte Problem, das Sie haben, ist ein soziales Problem. Sie haben Teammitglieder, die sich weigern, neue Konzepte zu lernen. Sie können das nicht mit einer technischen Lösung lösen. Sie müssen zunächst von Ihren Teammitgliedern Buy-Ins erhalten, um Git-Konzepte zu erlernen, anstatt sie davon zu überzeugen, dass es wie SVN ist.
Lie Ryan
10
Ich weiß, dass Sie andere Apps nicht empfehlen, aber @Wilbert hat es richtig. TortoiseGit versucht Dinge zu verbergen, was sie meiner Erfahrung nach schmerzhafter macht. Wenn eine Benutzeroberfläche gewünscht wird, habe ich festgestellt, dass der einfachste Übergang (lesen Sie: Ich trainiere nicht-traditionelle Softwareteams für Tools und DevOps) über Atlassians SourceTree erfolgte (natürlich mit entsprechender Schulung). Ich habe auch GitFlow verwendet, um ihnen zu helfen, das Git-Modell zu verstehen (dies passt jedoch nicht für alle Teams).
JasCav
28
Ich bin ein bisschen überrascht, dass jeder an dem Master arbeitet, der der zentrale Grundsatz von Continuous Integration ist . Solange Sie über eine robuste Testsuite verfügen und jeder weiß, wann der Build beschädigt ist, kann die Arbeit mit dem Master für die Zusammenarbeit im Team von Vorteil sein. Feature-Verzweigungen (auf die so ziemlich alle anderen Workflows in gewissem Maße angewiesen sind) können ohne vorhandenen Schutz gleichermaßen destruktiv sein. Wahrscheinlich haben Sie hier einige tiefere Grundprobleme.
DanK
14
@ DanK, ich denke auch, dass der op die Wurzel des Problems falsch identifiziert hat. Wenn auf dem Master Personen Änderungen protokollieren und Sie zu einem Zweig wechseln, werden auf dem Zweig Änderungen protokolliert. Wenn Sie zu einzelnen Filialen wechseln, haben Sie Leute, die Probleme haben, in ihren Filialen zu fusionieren (oder die sich in ihrer Filiale entwickeln, ohne monatelang zu fusionieren).
user3067860

Antworten:

11

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. ;)

Mike M.
quelle
9
Nitpick: SourceTree ist keine integrierte Entwicklungsumgebung ...
Mathieu Guindon
Ich habe jetzt jemanden (außer mir), der diesen Workflow testet (mit Tortoise Git, meine ich), um alle Überraschungen / Probleme auszuräumen. Wenn ich keine annehme, plane ich, dies in ein paar Tagen dem Team zur Verfügung zu stellen.
Monica Cellio
Ich weiß, dass diese hochgelobte Antwort einen Großteil des gleichen Gebiets abdeckt wie diese, aber erst als ich das Rezept sah, das in dieser Antwort Schritt für Schritt dargelegt wurde, verstand ich wirklich, wie man es anwendet, also habe ich es verstanden akzeptiere dieses (für das Rezept, nicht die IDE :-)). Wir verfolgen diesen Prozess seit einigen Tagen ohne weitere Probleme. Wir werden uns auch mehr darauf konzentrieren, den "git way" zu erforschen und zu verstehen.
Monica Cellio
99

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 .

Karl Bielefeldt
quelle
51
Immer pullvorher pushist ein guter Rat, aber ich würde einen Schritt weiter gehen und vorschlagen, dass Sie überlegen, ob Sie können, pull --rebasewenn Sie dies tun.
Anaximander
20
@anaximander, ich würde empfehlen, dass entweder jeder --rebase oder nobody ...
keuleJ
12
@TemporalWolf Das haben sie mir auch über den Kuchen erzählt ...
BlackVegetable
15
@anaximander "Dann haben Sie den Konflikt nicht gelöst, und Sie tun es falsch. In diesem Fall können sie nicht mit Rebase vertraut werden". Sie sagen also, Sie haben noch nie einen Zusammenführungskonflikt durcheinander gebracht? Es muss nett sein, auf einer Codebasis zu arbeiten, die so einfach ist, dass Sie diese Verallgemeinerung vornehmen können. Hier ist die Einstellung von Linus, die ich persönlich angenehmer finde als alle diese Schwarz-Weiß-Ansätze.
Voo
10
"Verwenden --forceSie es nur, wenn Sie wirklich wissen, was Sie tun." Ich würde noch weiter gehen. Das Umschreiben des Verlaufs im "Haupt" -Repository von allen Personen mit Ausnahme der vertrauenswürdigsten Personen nicht zulassen . Ob Sie das zumindest teilweise können, hängt von Ihrem Hosting ab, aber BitBucket hat die Option.
jpmc26
68

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.

MarkJL
quelle
37
"Wenn Tortoise im Grunde genommen GIT vor ihnen verbirgt und so tut, als wäre es SVN, dann ist Tortoise vielleicht das falsche Werkzeug." diese. Ich weiß, dass OP gesagt hat, dass es das Tool nicht ersetzen soll, aber wenn es die Funktionsweise von GIT in irgendeiner Weise beeinträchtigt, ist dies ein Nachteil für das persönliche Wachstum Ihrer Entwickler und für Ihre betriebliche Effizienz. Ihr Team wird Ihr VCS weiterhin missbrauchen, wenn es es nicht versteht.
2. Februar,
3
Eine weitere hilfreiche Git-Lernressource ist Learn Git Branching . Es zeigt einen visuellen Baum und verfügt zusätzlich über eine Sandbox, mit der Sie eine Reihe von Befehlen verspotten und sehen können, welche Art von Baum resultiert.
TemporalWolf
4
Es hat viel länger als einen Tag gedauert, bis alle im Entwicklerteam Git gelernt hatten (und sie sind nicht düster oder faul), also nahm ich an, dass dies auch für das Doc-Team zutreffen würde. Ich werde einen Blick auf die hier in Kommentaren erwähnten Sites werfen (vielleicht sollten sie in dieser oder einer anderen Antwort sein?).
Monica Cellio
3
Sie werden Git erst lernen, wenn Sie alle Fehler begangen haben und den Schmerz von widersprüchlichen Zusammenführungen und Abstürzen hatten. Sie müssen lediglich den oben beschriebenen kurzen Ablauf des Erstellens eines Zweigs erlernen, indem Sie diesen Zweig umbasieren, um alle Änderungen von master und einzubeziehen ihre Niederlassung wieder in Master zusammenführen. Jedes andere Lernen, das sie tun können, wenn sie versuchen, den Schmerz, auf den sie in diesem Fluss stoßen, zu beseitigen (es wird einige geben). Zumindest hat das Doc-Team nicht die Sorge, die Codebasis zu knacken.
MarkJL
1
@ 2rs2ts Tortoise Git ist eine außergewöhnliche Git-Gui. Ich installiere es auf allen meinen Windows-Boxen und bin mit der git-Befehlszeile sehr vertraut. Das Mergetool ist eines der besten, die ich je benutzt habe. Ich habe viele unerfahrene Benutzer mit Tortoise Git zum Gittern gebracht. Das größte Problem ist, dass einige der erweiterten Git-Optionen nur mit einem einfachen Kontrollkästchen angezeigt werden. Eine Option wie --force push könnte also durch einfaches Aktivieren eines Kontrollkästchens in der Push-GUI erfolgen. Dies ist wahrscheinlich, was das, was getan wurde, die Arbeit verloren hat. Ich benutze Tortoise nicht viel, aber es gibt ein paar Dinge, die es wirklich einfacher machen.
Gnash117
26

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.

Dan1701
quelle
3
Wir werden aus all den Gründen, die Sie angesprochen haben, zur Verzweigung übergehen (insbesondere aber kontrollierte PRs und die Möglichkeit, Konflikte in der Verzweigung vor dem Zusammenführen zu lösen). Könnten Sie mehr darüber sagen, wie ein Merge-and-Push-Skript angegriffen werden kann?
Monica Cellio
6
Ich bin mit diesem Rat nicht einverstanden. Langfristige Feature-Zweige können viel verheerender sein als die Arbeit mit dem Master (was passieren wird, wenn Sie keinen guten Workflow haben). Martin Fowler hat einen tollen Artikel zu diesem Thema. Am Ende des Tages hat das OPs-Team ein Problem mit der Workflow-Zusammenarbeit, kein Git-Problem. Ich würde argumentieren, dass mehr Zweige dieses Problem nur verschlimmern werden.
DanK
6
Langfristige Feature-Zweige sind nicht das, was ich befürwortet (noch erwähnt) habe. Ich bin damit einverstanden, dass sie schlecht für die "regelmäßige" Entwicklung sind und hier nicht besser wären. Regelmäßige "Ravioli" -Zweige mit kleinen Änderungssätzen, die vor dem Zusammenführen überprüft / getestet werden können, sind sehr nützlich und wären hier nicht weniger nützlich, nur weil es sich aus den in der Antwort genannten Gründen um ein Dokumentationsrepo handelt.
Dan1701
3
Klar, ich verstehe, was Sie sagen, und ich bin theoretisch nicht anderer Meinung , aber mit den hier beschriebenen Problemen der Zusammenarbeit, auch mit den besten Absichten, denke ich, dass sich alle Niederlassungen des OP-Teams versehentlich in lang laufende Niederlassungen verwandeln werden . Letztendlich ist es hier nicht das Hauptproblem, an einem Haupt- oder Feature-Zweig zu arbeiten. Das Problem ist ein allgemeiner Mangel an Verständnis für die Vor- und Nachteile eines verteilten VCS und ein Mangel an Zusammenarbeit / Zusammenhalt zwischen den Entwicklern. Feature-Verzweigungen alleine werden das nicht beheben, aber IMO verschärft es.
DanK
2
Wir stehen kurz davor, dies in den Chat zu verschieben, aber wenn Sie sich immer in einem Feature-Zweig befinden, sind Sie noch nicht mit Ihrer Arbeit fertig. Sie müssen mit der versendeten Filiale zusammengeführt (oder in diesem Fall veröffentlicht) werden. Dies ermöglicht die Einführung automatisierter Überprüfungen und Schutzmaßnahmen für die Probleme, mit denen das Team konfrontiert ist. Ein Feature-Zweig unterscheidet sich grundlegend von der Arbeit am Master, da die meisten Tools (mindestens Bitbucket) so eingerichtet sind, dass Pull-Anforderungen mit den erforderlichen Genehmigungen und Pre-Merge-Builds als Teil des Verzweigungsmodells zulässig sind master.
Dan1701
12

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
jmathew
quelle
2
Zu Ihrem letzten Punkt: Für einen schnellen, strukturellen Überblick finde ich git log --oneline --decorate --graphideal. So sehr, dass ich einen Shell-Alias ​​für diese genaue Kombination definiert habe.
cmaster
1
+1 für Ihre Antwort, ich finde nur die vorgeschlagene Alternative ist schlecht, aus dem Grund, den Sie erwähnt haben. Sie werden Schmerzen haben, auch wenn Sie zu SVN zurückkehren und dann in Zukunft zum Schwachkopf gehen. Die Leute im Team werden das neue, andere, schmerzhafte Werkzeug nur lernen, wenn sie keine andere Wahl haben. Erst nach dem Gebrauch und wenn sie dumme Fehler gemacht haben, werden sie zu schätzen beginnen, was git kann.
CodeMonkey
8

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.

Steve Barnes
quelle
Eigentlich keine schlechte Idee. Es klingt auch so, als würde dieses Team von einem Merge Master profitieren, bis es sich wohler fühlt. +1
Greg Burghardt
2
BitBucket verfügt über eine Gabel-Synchronisationsfunktion, die Gabeln nach Möglichkeit automatisch vorspult. Es ist sehr praktisch, heute abzweigen und nächste Woche vom Ursprung zu ziehen, ohne sich jemals Gedanken über den Upstream zu machen.
Piedar
3

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.

jpmc26
quelle
2

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.

Ian Kemp
quelle
1

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.

TanguyB
quelle
0

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.

Joshua
quelle
Wenn Sie dies tun, können Sie genauso gut bei SVN bleiben. In der gleichen Zeit wie in der Zeit der Automobile, in der man mit Pferdekutschen bleiben durfte. Natürlich können Sie Ihr Auto mit der gleichen Geschwindigkeit fahren wie mit einer Pferdekutsche. Aber alles, was Sie damit erreichen, ist, sich selbst zu behindern und die Leute, die in der Lage sind, ein Auto zu fahren, wütend auf Sie zu machen. Lerne dein Auto zu fahren. Jetzt.
cmaster
@cmaster: Für uns war der größte Vorteil von Git der Verlust des Servers, der nicht die gesamte Versionskontrollhistorie verliert. (Es ist uns passiert - wir hatten Backups, aber das Bandlaufwerk fing an, Bänder zu essen, als wir versuchten, wiederherzustellen.)
Joshua
@cmaster: Wir haben seitdem damit begonnen, einige andere nützliche Git-Funktionen einzuführen, aber das Ändern der Verzweigung wird wahrscheinlich nicht verwendet.
Joshua
@cmaster Der Unterschied zwischen einem langsamen Autofahren und einem Pferdefahren besteht darin, dass Sie durch Autofahren darauf vorbereitet werden, schneller zu fahren. Reiten tut das nicht. Nicht jeder, der in ein Auto springt, muss das Gas geben, um die ersten paar Male, in denen er drin ist, 100 km / h zu fahren.
jpmc26
@ jpmc26 Als ich meine ersten Fahrstunden nahm, wurde ich gebeten, mit Sicherheit 30 km / h zu fahren, und ich glaube, dass diese Lektion auch eine kurze Strecke mit 50 km / h beinhaltete. Das ist definitiv mehr als eine typische Pferdekutsche. Und das Gleiche gilt für git: Sie lernen im Allgemeinen vom ersten Tag an, sich zu teilen und zusammenzuführen. Das ist ein wesentlicher Bestandteil der Verwendung git. Vermeiden Sie dies und missbrauchen Sie das Werkzeug genauso, wie Sie ein Auto missbrauchen, wenn Sie nicht mehr als 15 km / h fahren.
CMASTER
-3

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.

gnasher729
quelle
4
Das ersetzt "master" nur durch "development", mit dem zusätzlichen Risiko, dass Benutzer nach einem Standard-Checkout nicht in den Entwicklungszweig wechseln. Ich bevorzuge GitLab Flow , ein fröhliches Medium zwischen dem harten GitFlow und dem spärlichen GitHub Flow.
Cees Timmerman
@CeesTimmerman Wenn Sie nicht Gitflow mögen, könnten Sie interessieren ONEFLOW auch.
jpmc26