Wirklich ein konkretes Beispiel, dass die Zusammenführung in Git einfacher als SVN?

Stack Overflow Frage Wie und/oder warum ist das Zusammenführen mit Git besser als in SVN? ist eine gute Frage mit einigen gute Antworten. Doch keiner von Ihnen zeigen ein einfaches Beispiel, wo merging in Git funktioniert besser als SVN.

Auf die chance, diese Frage wird geschlossen, da ein Duplikat ist, was ist

  1. Eine konkrete merge-Szenario
  2. Wie es schwierig ist im SVN?
  3. Wie die gleiche merge ist einfacher im Git?

Ein paar Punkte:

  • Keine Philosophie oder tief Erklärungen, was ein DVCS ist, bitte. Diese sind großartig, wirklich, aber ich glaube nicht, dass Ihre details zu verschleiern, die Antwort auf diese (IMHO) wichtige
  • I don ' T care über die "historischen " SVN" im moment. Bitte vergleichen Sie modernen Git (1.7.5) zu modernen SVN (1.6.15).
  • Nicht benennt bitte - ich weiß, dass Git erkennt, benennt und verschiebt, während SVN nicht. Das ist großartig, aber ich bin auf der Suche nach etwas tiefer, und Beispiel, die nicht die umbenennt oder verschiebt.
  • Kein Stellungswechsel oder andere 'fortgeschrittene' Git Betrieb. Nur zeigen Sie mir die bitte Zusammenführen.
  • Ich spreche nicht über die lokale Verzweigung an alle, noch die Leistung. Ich möchte verstehen, warum, wenn es weniger merge-Konflikte in git als svn.
  • Meinst du stackoverflow.com/questions/2475831/merging-hg-git-vs-svn nicht die Antwort auf Ihre aktuelle Frage? (oder stackoverflow.com/q/459891/6309 ?)
  • (oder stackoverflow.com/questions/2518779/... oder stackoverflow.com/questions/2544008/...) ... etc
  • danke. Während die meisten der Antworten, die Sie verbunden waren, nicht das was ich Suche, dieser scheint zu sein, ein gültiges Beispiel: stackoverflow.com/questions/459891/...
  • du meinst, dass stackoverflow.com/questions/2475831/merging-hg-git-vs-svn/... ist nicht eine tatsächliche detaillierten "zeigen Sie mir die merge-schon" - Beispiel??? Oder stackoverflow.com/questions/2544008/...?
  • jedoch, die mehr häufiges Beispiel ist @Greg die Antwort ... jetzt brauche ich nur ein konkretes Beispiel, dass. stackoverflow.com/questions/6172037/...
  • Ich aktualisiert meine Antwort ein paar Minuten vor, um auszuschließen, umbenennt/verschiebt. Ich weiß, git es bleibt einfach diese better by design (oder ein svn-Designfehler), aber ich möchte zu finden, die Beispiele nicht mit benennt, dass es auch nicht besser ... check out Greg ' s Antwort.
  • Ehrlich gesagt, ist die einfache Tatsache, dass Sie können verschieben Sie ein Verzeichnis direkt aus dem OS, ohne Schrauben up-SVN, da hast du verschieben .svn herum ist genug für die meisten Entwickler zu wechseln, um ein DVCS in Eile 😉
  • git hat viele Vorteile, siehe auch stackoverflow.com/questions/871/... ich bin nur frustriert, dass ich immer gehört, wie git besser Zusammenführen, und sah einige Beispiele zu umbenennen, aber ich glaube, ich bin immer noch fehlt eine gute einfache "Kern" - Beispiel ohne verschmilzt.
  • Wenn stackoverflow.com/questions/459891/... ist ein gültiges Beispiel nicht warum posten Sie als Antwort auf Ihre Frage und akzeptieren Sie es?
  • es ist ein gültiges Beispiel, aber es ist nicht so mainstream. Ich bin eigentlich viel mehr interessiert @Greg die Antwort auf diese Frage, denn dies ist das argument, das ich immer gehört ... wir müssen nur, es zu hacken, etwas zu finden, die konkrete kanonische Beispiel für alle mal.
  • Schöne Frage. Meiner Meinung nach das Zusammenführen der Mächte von git sind in der Regel overpraised 🙂 Und ich habe gerade gegen einen weiteren queer-Verhalten von git, die nicht in der Lage zu tun, eine automatische merge-auf dem gleichen Zweig - siehe die Frage.

InformationsquelleAutor ripper234 | 2011-05-30
  1. 22

    Vom praktische Perspektive, die Verschmelzung traditionell "schwer" wegen dem, was ich nenne die "big bang "merge" - problem. Angenommen, ein Entwickler hat die Arbeit sich auf einige code für eine Weile und hat sich nicht verpflichtet, Ihre Arbeit noch (vielleicht ist der Entwickler gewöhnt ist, in der Subversion gegen trunk, und nicht Begehen unfertigen code). Wenn die Entwickler endlich begeht, es gibt eine Menge von änderungen, die alle aufgerollt in einem commit. Für die anderen Entwickler, die Zusammenführen möchten Ihre Arbeit mit diesem "big bang" Begehen, ist das VCS tool ist nicht genug Informationen darüber, wie die ersten Entwickler haben bis zu dem Punkt, das Sie begangen, so bekommst du nur "hier ist ein riesiger Konflikt in dieser ganzen Funktion, gehen fix it".

    Auf der anderen Seite, ist die übliche Stil in der Arbeit mit Git und anderen DVCS, die günstigen lokalen Niederlassungen, ist zu verpflichten, regelmäßig. Sobald Sie das getan haben, ein bit der Arbeit, die ziemlich viel Sinn macht, Sie auszuführen. Es muss nicht perfekt sein, aber es sollte eine zusammenhängende Einheit arbeiten. Wenn Sie wieder kommen, um zu verschmelzen, haben Sie immer noch, dass die Geschichte von kleineren begeht, die zeigt, dass wie, die Sie von den ursprünglichen Zustand auf den aktuellen Zustand. Wenn der DVCS geht zu verschmelzen diese mit der Arbeit anderer, hat es eine Menge mehr Informationen darüber, welche änderungen vorgenommen wurden, wenn, und Sie am Ende immer kleinere und weniger Konflikte.

    Der Punkt ist, dass Sie noch treffen können, die Verschmelzung ein schweres problem mit Git von einem einzigen großen Knall zu Begehen, nur, nachdem Sie haben etwas fertig. Git ermutigt Sie, um kleinere begeht (indem er Sie so schmerzlos wie möglich), die Zukunft der Zusammenführung einfacher.

    • Dies ist eine große motivation, und ich habe gehört, diese Argumente vor und glauben, dass Sie richtig sind. Sind Sie auf ein konkretes Beispiel, das illustriert diese?
    • Vielleicht ist es wahr in Darcs, aber es ist nicht wahr, im Git, weil Git für die Zusammenführung der Auffassung, im üblichen Fall nur drei Versionen: unsere, Ihre und Vorfahren (merge-base).
    • Nur zur info - wenn du/jemand destilliert diesem Anwendungsfall in einem konkreten Beispiel, ich nehme Ihre Antwort, weil ich glaube, das ist das beste Beispiel.
    • Mit Subversion, verwende ich die Funktion Zweigen für was git hat lokale Niederlassungen. So viele Menschen sagen, dass Sie sich nicht verpflichten, unerledigte arbeiten in Subversion - aber es ist einfach nicht wahr. Ich kann das gleiche tun mit Subversion jeden Tag und es ist nicht mehr teuer. Ich sehe keinen Vorteil hier, unter Berücksichtigung der Zusammenführung.
    • Betrug erkannt. Gezeigte Szenario ist nicht ein problem von Subversion per se, sondern nur der "Affe mit Handgranate" Fall
    • Ich mag die "Affe mit Handgranate" Ausdruck, aber ich denke, es ist hier ungültig. Die Frage ist, ob man (Git) ist einfacher als die anderen (SVN) auf das Thema der Zusammenführung. Es macht absolut Sinn, dass man tests ein paar verschiedene Szenarien (Extreme/commons/rare), um den gesamten Fall. Es ist durchaus wahrscheinlich, dass die Zusammenlegung ist identisch mit der "commit jede Stunde" Fall, aber es ist einfacher, mit Git, wo Begehen, passiert öfter. Die Frage fragt nach einer konkreten Szenario - Sie scheinen zu sein, Bestand darauf, das Szenario muss "typisch" - die Frage nicht und es gibt keinen Grund, um ihn zu begrenzen.

    InformationsquelleAutor Greg Hewgill
  2. 16

    Kann ich nur sagen, ein kleines experiment waren Git war NICHT besser als Subversion (gleiche Probleme).

    Wunderte ich mich über diesen Fall:
    Beginnen Sie mit zwei ästen "mytest1" und "mytest2" beide basieren auf den gleichen commit.
    Sie haben eine C-Datei, die enthält eine Funktion blub().
    In der Abteilung mytest1, die Sie bewegen, "blub()" an eine andere position in der Datei und Begehen.
    In der Abteilung mytest2 Sie ändern blub() und commit.
    Auf einem ast mytest2 Sie versuchen, verwenden Sie "git merge mytest1".

    Scheint zu geben einen merge-Konflikt.
    Ich hoffte, dass Git würden erkennen, dass "blub()" verschoben wurde mytest1 und dann in der Lage sein, um auto-merge der änderungen in mytest2 mit dem Umzug in mytest1. Aber zumindest, wenn ich versuchte dies nicht automatisch funktionieren...

    Während ich also voll verstehen, dass Git ist viel besser zu verfolgen, was übertragen wurde und was noch nicht zusammengeführt wurde, doch ich Frage mich auch, ob es "Reine" merge Fall, in dem Git ist besser als SVN...

    Nun, da diese Frage wurde Lauschangriff mich für eine lange Zeit war ich wirklich versucht, erstellen Sie ein konkretes Beispiel, wo Git ist besser, in der Erwägung, dass die Verschmelzung im SVN schlägt fehl.

    Habe ich einen gefunden hier https://stackoverflow.com/a/2486662/1917520, aber dies beinhaltet ein umbenennen und die Frage hier war für einen Fall ohne umbenennen.

    So, hier ist ein SVN-Beispiel, das im Grunde versucht diese:

    bob        +-----r3----r5---r6---+
          /               /     \
anna     / +-r2----r4----+--+     \
        / /                 \     \
trunk  r1-+-------------------r7-- Conflict

    Die Idee hier ist:

    • Anna und Bob sind beide Entwickler mit Ihren eigenen Niederlassungen (erstellt in r2,r3).
    • Anna hat einige änderungen (r4),
    • Bob hat einige änderungen (r5).
    • Bob führt die änderungen von Anna in seinen Zweig; das gibt Konflikte, die Bob-fixes und dann begeht (r6).
    • Annas änderungen zusammengeführt werden zurück in den Kofferraum (r7).
    • Bob versucht zu verschmelzen seine änderungen zurück auf den Stamm zu und dies wiederum gibt einen Konflikt.

    Hier ist ein Bash Skript, produziert, die diesen Konflikt (mit SVN 1.6.17 und auch SVN 1.7.9):

    #!/bin/bash
cd /tmp
rm -rf rep2 wk2
svnadmin create rep2
svn co file:///tmp/rep2 wk2
cd wk2
mkdir trunk
mkdir branches
echo -e "A\nA\nB\nB" > trunk/f.txt
svn add trunk branches
svn commit -m "Initial file"
svn copy ^/trunk ^/branches/anna -m "Created branch anna"
svn copy ^/trunk ^/branches/bob  -m "Created branch bob"
svn up 
echo -e "A\nMA\nA\nB\nB" > branches/anna/f.txt
svn commit -m "anna added text"
echo -e "A\nMB\nA\nB\nMB\nB" > branches/bob/f.txt
svn commit -m "bob added text"
svn up
svn merge --accept postpone ^/branches/anna branches/bob
echo -e "A\nMAB\nA\nB\nMB\nB" > branches/bob/f.txt
svn resolved branches/bob/f.txt
svn commit -m "anna merged into bob with conflict"
svn up
svn merge --reintegrate ^/branches/anna trunk
svn commit -m "anna reintegrated into trunk"
svn up
svn merge --reintegrate --dry-run ^/branches/bob trunk

    Den letzten "--dry-run" erzählt Sie, dass es einen Konflikt. Wenn Sie stattdessen versuchen Sie zuerst zu verschmelzen Anna Wiedereingliederung in Bob ' s-Filiale dann bekommst du auch ein Konflikt; also, wenn Sie ersetzen die letzten svn merge mit 

    svn merge ^/trunk branches/bob

    zeigt dies aber auch Konflikte.

    Hier ist das gleiche mit Git 1.7.9.5:

    #!/bin/bash
cd /tmp
rm -rf rep2
mkdir rep2
cd rep2
git init .
echo -e "A\nA\nB\nB" > f.txt
git add f.txt
git commit -m "Initial file"
git branch anna
git branch bob
git checkout anna
echo -e "A\nMA\nA\nB\nB" > f.txt
git commit -a -m "anna added text"
git checkout bob
echo -e "A\nMB\nA\nB\nMB\nB" > f.txt
git commit -a -m "bob added text"
git merge anna
echo -e "A\nMAB\nA\nB\nMB\nB" > f.txt
git commit -a -m "anna merged into bob with conflict"
git checkout master
git merge anna
git merge bob

    Den Inhalt f.txt Veränderungen wie diese.

    Erste version

    A
A
B
B

    Annas änderungen

    A
MA
A
B
B

    Bob die änderungen in der

    A
MB
A
B
MB
B

    Nachdem Annas Zweig zusammengeführt wird Bob ' s-Filiale

    A
MAB
A
B
MB
B

    Wie so viele Menschen bereits darauf hingewiesen: Das problem ist, dass subversion kann mich nicht erinnern, dass Bob bereits gelöst Konflikt. Also, wenn Sie versuchen, jetzt verbindet Bob ' s-Filiale in den Kofferraum, dann musst du erneut den Konflikt zu lösen.

    Git arbeitet völlig anders. Hier einige grafische Darstellung was git tut

    bob         +--s1----s3------s4---+
           /               /     \
anna      / +-s1----s2----+--+     \
         / /                 \     \
master  s1-+-------------------s2----s4

    s1/s2/s3/s4 sind die Schnappschüsse des working directory git nimmt.

    Hinweise:

    • Wenn anna und bob erzeugen Ihre Entwicklung äste, diese werden
      NICHT erstellen begeht unter git. git wird nur daran erinnern, dass
      in beiden Zweigen zunächst beziehen sich auf den gleichen commit-Objekt als
      der master-Zweig. (Diese Begehung wiederum beziehen sich auf die s1-snapshot).
    • Als anna realisiert Ihre änderung, dadurch wird eine
      neue snapshot "s2" + ein commit-Objekt.
      Ein commit-Objekt enthält:

      • Einen Verweis auf die Momentaufnahme (s2 hier)
      • Eine commit-Nachricht
      • Informationen über die Vorfahren (andere commit-Objekte)
    • Wenn bob implementiert seine änderung, wird dies eine weitere Momentaufnahme
      s3 + ein commit-Objekt
    • Wenn bob führt annas änderungen in seiner Entwicklung Zweig
      dadurch wird noch ein weiteres snapshot s4 (mit einer Zusammenführung von seinem
      änderungen und anna ' s verpasst) + noch ein weiteres commit-Objekt
    • Wenn anna verschmelzen Ihre änderungen wieder in den master branch, dies wird
      ein "fast-forward" merge-in dem gezeigten Beispiel, da der Meister
      hat sich nicht geändert in der Zwischenzeit. Was "fast-forward" hier bedeutet, ist,
      dass der master wird einfach auf die s2 Schnappschuss von anna
      ohne die Zusammenlegung nichts. Mit solchen "fast-forward" - es wird
      nicht noch ein weiteres commit-Objekt. Die "master" - Zweig wird nur
      direkt beziehen sich nun auf das Letzte commit von der "anna" - Zweig
    • Wenn bob nun verschmilzt, seine Veränderungen in den Kofferraum, passiert Folgendes:
      • git finden heraus, dass das Begehen von anna erstellt
        die s2 ist ein snapshot ist eine (direkte) Vorfahren für bobs Begehen,
        die erstellt der snapshot s4.
      • weil das git wieder "Vorspulen" im master-branch zu
        der Letzte commit von der "bob" - Zweig.
      • wieder wird das auch nicht erstellen Sie ein neues commit-Objekt.
        Die "master" - Zweig wird einfach hingewiesen werden kann, die letzten commit
        der "bob" - Zweig.

    Hier ist die Ausgabe von "git-ref-log", was zeigt all dies:

    88807ab HEAD@{0}: merge bob: Fast-forward
346ce9f HEAD@{1}: merge anna: Fast-forward
15e91e2 HEAD@{2}: checkout: moving from bob to master
88807ab HEAD@{3}: commit (merge): anna merged into bob with conflict
83db5d7 HEAD@{4}: commit: bob added text
15e91e2 HEAD@{5}: checkout: moving from anna to bob
346ce9f HEAD@{6}: commit: anna added text
15e91e2 HEAD@{7}: checkout: moving from master to anna
15e91e2 HEAD@{8}: commit (initial): Initial file

    Wie Sie sehen können aus dieser:

    • wenn wir gehen, um anna ' s development branch (HEAD@{7}) wir nicht ändern
      zu einem anderen Begehen, halten wir das Begehen; git nur daran erinnert, dass
      wir sind jetzt auf einen anderen Zweig
    • Bei HEAD@{5} wir bewegen uns zu bob ' s erste Zweig; damit verschieben sich die arbeiten
      kopieren, um den gleichen Zustand wie der master-Zweig, weil bob hat sich nicht geändert
      alles noch
    • Bei HEAD@{2} wir bewegen uns zurück zum master-branch, also dem gleichen commit
      Objekt alles begann.
    • Head@{1},HEAD@{0} zu zeigen, die "schnell-vorwärts" führt, die nicht schaffen
      neue commit-Objekte.

    Mit "git cat-file-HEAD@{8} -p" können Sie überprüfen die vollständigen details der ursprünglichen commit-Objekt. Für das obige Beispiel, ich habe:

    tree b634f7c9c819bb524524bcada067a22d1c33737f
author Ingo <***> 1475066831 +0200
committer Ingo <***> 1475066831 +0200

Initial file

    Den "Baum" Linie kennzeichnet die
    snapshot-s1 (==b634f7c9c819bb524524bcada067a22d1c33737f)
    auf die diese verpflichten sich bezieht.

    Wenn ich "git cat-file-HEAD@{3} -p" ich:

    tree f8e16dfd2deb7b99e6c8c12d9fe39eda5fe677a3
parent 83db5d741678908d76dabb5fbb0100fb81484302
parent 346ce9fe2b613c8a41c47117b6f4e5a791555710
author Ingo <***> 1475066831 +0200
committer Ingo <***> 1475066831 +0200

anna merged into bob with conflict

    Diese oben zeigt die commit-Objekt, bob erstellt beim Zusammenführen von anna-Zweig. Wieder der "Baum" Zeile bezieht sich auf die erstellten snapshot (s3 hier). Zusätzlich ist zu beachten die "Eltern" - Linien. Die zweite beginnt mit "übergeordneten 346ce9f" später erzählt, git, wenn Sie versuchen, Seriendruck zurück, bob ' s Entwicklungs-branch in den master branch, dass diese Letzte commit von bob hat anna die letzten commit als ein Vorfahre. Dies ist der Grund, warum git weiß, dass das Zusammenführen von bob Entwicklungs-branch in den master branch ist ein "fast-forward".

    • Warten. Warum tut dies zu demonstrieren Subversion ist besser als Git für diesen workflow? Ich denke, Git ' s Verhalten ist bevorzugt, da es einfach erkennt Bob bereits den Konflikt aufgelöst (wirklich, aufgezeichnet, wie der Konflikt gelöst), und schnell vor dem commit. Die eigentliche Frage ist, was passiert, wenn Anna will Zusammenführen Ihrer änderungen zurück in den trunk, nicht ahnend, dass Bob bereits integriert Ihre änderungen, und dann einige. Git noch erzählt Anna gibt es einen Konflikt, das ist wichtig.
    • OK, meine Antwort mag verwirrend sein: Der erste Teil bezieht sich auf ein experiment, auf das Reine Zusammenführen von wo git + svn sind die gleichen (in einer Filiale, die Sie bewegen, eine Funktion, die in einem anderen Zweig, ändern Sie eine Funktion, wenn Sie merge git + svn beide geben ein Konflikt). Die zweite Teil (was Sie bezeichnen) tatsächlich Antworten auf die gestellte Frage: Es gibt ein Beispiel, wo git ist definitiv besser als svn. Also ja: der 2. Teil der Antwort zeigt einen Fall, wo git ist besser.
    • Ah, danke. Ich muss mich wohl falsch verstanden, die wichtige Linie. War bis spät. Nur eine kurze Beobachtung. Block verschieben Erkennung ist wirklich ein Ergebnis der differenzberechnung-engine, nicht die version-control-system, per se. Sie können immer build a smarter Konfliktlöser auf der Oberseite des VCS, aber Git nicht standardmäßig, weil es versucht, bleibt die Sprache neutral. git blame -CCC tut dies.
    • Oh, ich wusste nicht, über die "-CCC - " - Schalter; nette :-). Ich bin mir bewusst, dass dies rein die Konfliktlöser, aber ich Frage mich, ob das Konfliktlöser in git besser war als in svn. Werden Sprache neutral: ich bin mir nicht sicher; wenn Sie hatte wirklich eine genaue Bewegung (keine anderen änderungen überhaupt) ein text-block (in meinem Beispiel eine Funktion), und jemand anderes ändert dies sagte Textblock, wäre das nicht noch sprachneutral ? Ich habe nicht daran dachte zu viel, vielleicht gibt es wirklich Fälle, in denen dies das falsche auto-resolution policy...
    • git überlegen ist, da svn svn verwendet snapshots, und git verwendet Differenzmengen. Sie sind nicht mathematisch äquivalente Darstellungen. Es ist der Unterschied zwischen einem integral und dessen Ableitung. Bitte sehen Sie sich die kurze 2-seitige essay "Integrale und Ableitungen" von Martin Pool, dem Schöpfer der bzr dvcs: sourcefrog.net/weblog/software/vc/derivatives.html Alles andere ist die tools auf der Oberseite des Systems, wie die differenzierende engine, die feeds in die Konfliktlöser.
    • Technisch ist es möglich, für ein änderungssatz-orientierten system zu einer schlechteren oder "nur als schlechter/guter" conflict resolver als einen snapshot-orientierte system. Dies ist, was macht den Unterschied zwischen den beiden so schwer zu sehen, weil wir dazu neigen zu denken, konkret anhand von Beispielen und nicht immer leicht zu abstrahieren, um Allgemeine. Für die historische Referenz, das ist der thread von 2005: gelato.unsw.edu.au/archives/git/0504/2279.html
    • Nachdem Sie nun gelernt haben, viel mehr über git ich kommentieren. git tatsächlich nutzt snapshots (keine änderungen). Der wirkliche Unterschied ist, dass git merkt sich das Verhältnis des snapshots (die snapshot erstellt wurde, aus dem anderen snapshot(s)). Diese Informationen fehlen in subversion, oder um genauer zu sein mit den letzten subversion-die information ist weit weniger abgeschlossen, als es im git. Das ist, warum git hat eine einfachere Zeit, um herauszufinden, wie eine Momentaufnahme entwickelt, und das ist, warum es eine bessere Idee, wie man merge verschiedene Schnappschüsse...
    • Was ist Ihre Quelle? Alle wesentlichen Operationen in git (und jeder distributed version control system, im wesentlichen) verwenden änderungen, wie die Daten-Struktur. Svn verwendet dagegen snapshots. So, während Svn 1.8 gebaut hat, ein paar Sachen unter der Haube zu verfolgen, die Beziehungen und während Git gebaut hat, ein paar Sachen unter der Haube zu verfolgen, die snapshots, die konzeptionell arbeiten mit änderungen ist grundsätzlich leistungsfähiger. Meine beste Quelle für diese Argumentation ist Martin Pool ' s bahnbrechenden essay "Integrale und Ableitungen" (Martin ist der Autor von bzr). sourcefrog.net/weblog/software/vc/derivatives.html
    • Hinweis an das Ende von Martin ' s Artikel, er beschreibt die Konvertierung zwischen den Darstellungen. Ich habe einige nehmen Anstoß an seiner Charakterisierung von Kalkül als einen Schritt über die algebra, obwohl. Die meisten meiner undergrad war, verbrachte Lehr-Kalkül als ein TA, und die echte Dünn es ist, dass es die wichtigsten Konzepte müssen die Schüler lernen, in Rechnung zu begeben. Zum Beispiel, es ist bekannt in der Bildung-Literatur auf Rechnung, dass das Verständnis, was eine Grenze ist, und was es bedeutet, "eine Grenze", ist ein "Schwellenwert-Konzept."
    • Das heißt, denken härter über Ihre Aussage, ich denke, deine Verwirrung kann aus der Tatsache, dass git speichert die änderungen chronologisch. So funktioniert Mercurial und bzr. Darcs ist ein verteiltes vcs, die einfach funktioniert mit patches, unabhängig von der chronologischen Reihenfolge. Siehe: darcs.net/DifferencesFromOtherDVCS
    • Auch unter diesem thread der Diskussion zu Ihrem logischen Abschluss, beachten Sie, dass das darcs-link erklärt, warum die differencing engine in darcs ist theoretisch leistungsfähiger als git ist, weil es entfernt die chronologische Bestellung Einschränkung auf das Mathe-problem. Weniger Einschränkungen, mehr Leistung (in der Regel).
    • Urghs: ich habe nicht gesucht zu lange in diesem thread. Warum habe ich das gesagt git verwendet "Schnappschüsse". Denn dies ist genau das, was git nicht. Meine Quelle ist einfach der source-code von git und das Verständnis, was es tut. Wenn Sie beziehen sich auf einen commit mit seiner SHA1-Prüfsumme, die Sie im Grunde sagen Sie git, dass Sie beziehen sich auf einen bestimmten snapshot des gesamten Arbeitsverzeichnis. Wenn Sie diff beiden SHA1-Prüfsummen, dann git berechnet den diff aus zwei Schnappschüsse, die Sie geben, um es (natürlich den Weg git dies handhabt, bedeutet, dass Sie finden sich SEHR schnell, wenn die zwei Dateien unterscheiden sich alle). Also keine änderungen im git; nur Momentaufnahmen.

    InformationsquelleAutor Ingo Blackman
  3. 6

    Ich habe keine konkreten Beispiele, aber jede Art von wiederholt merge ist schwierig, insbesondere sogenannte criss-cross merge.

       a
  /\
 b1  c1
 |\ /|
 | X |
 |/\|
 b2  c2

    Zusammenführen von b2 und c2

    Die wiki-Seite auf Subversion Wiki beschreiben Unterschiede zwischen mergeinfo basierend Assymmetrische Subversion merge (mit 'sync' und 'Reintegration' Richtungen) und merge tracking based symmetric merge-im DVCS hat einen Abschnitt "Symmetric Merge mit Criss-Cross-Merge"

    • Dies scheint konkret genug für mich! Es passiert die ganze Zeit in großen teams mit weniger stringente workflows: alle hacks entfernt, und in regelmäßigen Abständen zieht aus dem central repo oder von einem anderen Entwickler, der codiert das, was Sie brauchen.
    • WTF??? b2 == c2 - Seriendruck nicht benötigt werden. Lüge erkannt
    • Erste, Zusammenführen könnte böse sein, oder nur lösen Konflikte anders. Zweitens, die - - - - - Linie kann eine Reihe von nicht-überarbeitungen Zusammenführen, nicht gezeigt, um Graphen einfacher.
    • "Zusammenführen könnte böse sein" - ist einfach nur nutzlos null-Wert Wortlaut. ZEIGEN Sie MIR DAS ÜBEL!. Zweiter workflow verwende ich die meiste Zeit in langen-live-feature-Zweige für den Daten-Austausch ohne große Probleme - "Merge oft!!!"
    • Es tut mir Leid für die Verwendung von Fachsprache ohne Erklärung: böse merge ist ein merge-commit, wo einige Linien nicht aus entweder einem oder den anderen Elternteil (Verzweigung zusammengeführt oder Zweig zusammengeführt werden kann).
    • Das ist das, was ich schrieb: "ich habe keine konkreten Beispiele, aber jede Art von wiederholten Zusammenführen ist schwierig, insbesondere sogenannte criss-cross-Zusammenführen." Was ich weiß ist, dass die rekursiv merge - Algorithmus in git erstellt wurde, um sich mit diesem und ähnlichen Beispielen. Ich weiß nicht wenn Sie SVN merge-Algorithmus, basierend auf copyfrom-und merge(d)info-Eigenschaften können mit dieser situation umgehen.

    InformationsquelleAutor Jakub Narębski
  4. 4

    Das konkreteste Beispiel, das ich denken kann, ist die einfachste merge, der nicht zu merge-Konflikten. Allerdings (TL;DR) mit diesem Beispiel Git noch von Natur aus ein einfacheres Verfahren als mit Subversion. Können warum:

    Subversion

    Betrachten Sie das folgende Szenario in subversion; der Stamm und die Zweig:

       1  2  3
…--o--o--o              trunk
          \4  5
           o--o         branches/feature_1

    Zusammenführen, können Sie verwenden Sie den folgenden Befehl in subversion:

    # thank goodness for the addition of the --reintegrate flag in SVN 1.5, eh?
svn merge --reintegrate central/repo/path/to/branches/feature_1

# build, test, and then... commit the merge
svn commit -m "Merged feature_1 into trunk!"

    In subversion Zusammenführen der änderungen erfordert eine andere Begehen. Dieses ist zum veröffentlichen der änderungen, die der merge hat mit der Anwendung der änderungen auf den feature-branch virtuelle Verzeichnis zurück in den Kofferraum. So, alle arbeiten mit dem Stamm kann es nun verwenden, und die revision graph sieht aus wie so in der Art wie dieses:

       1  2  3      6
…--o--o--o------o       /trunk
          \4  5/
           o--o         /branches/feature_1

    Können sehen, wie dies im git.

    Git

    In Git das merge-commit ist wirklich nicht notwendig, da die Zweige verherrlicht Lesezeichen auf die revision graph. Also mit der gleichen Art von revision graph-Struktur es Art sieht aus wie dieser:

             v-- master, HEAD

   1  2  3
…--o--o--o
          \4  5
           o--o

              ^-- feature_branch

    Mit dem Kopf, die derzeit auf dem master-Zweig führen wir ein einfaches mischen mit dem feature-branch:

    # Attempt a merge
git merge feature_branch

# build, test, and then... I am done with the merge

    ... und es wird Vorlauf den Zweig über dem commit-wo Zweiges gerichtet ist. Möglich ist dies, da Git weiß, dass das Ziel der Zusammenführung ist eine direkte Nachfahrin und die current-Zweig nur braucht, um all die Veränderungen, die geschehen. Die revision graph wird am Ende Aussehen wie diese:

       1  2  3  4  5
…--o--o--o--o--o
               ^-- feature_branch, master, HEAD

    Die änderungen nicht benötigen eine neue commit-wie alle git getan hat, ist bewegen Sie den Zweig Verweise weiter nach vorne. Alles, was Links ist, dies zu veröffentlichen, um die öffentliche repository, wenn Sie irgendwelche:

    # build, test, and then... just publish it
git push

    Abschluss

    Angesichts dieses einfache Szenario können Sie geltend machen zwei Dinge den Unterschied zwischen Subversion und Git:

    • SVN erfordert mindestens ein paar Befehle der Abschluss der Zusammenführung und Kräfte Sie zu veröffentlichen zusammenzuführen, als einen zu Begehen.
    • Git benötigt nur einem Befehl und hat nicht zwingen Sie veröffentlichen Ihr verschmelzen.

    Gegeben, dass dies die einfachste merge-Szenario ist es schwer zu argumentieren, dass subversion ist einfacher als git.

    In schwieriger merge-Szenarien, git bietet auch Ihnen die Möglichkeit zu Stellungswechsel Zweig, produziert eine einfachere revision graph auf Kosten der Geschichte umschreiben. Sobald Sie den Dreh raus, aber, und vermeiden Sie die Veröffentlichung der Geschichte schreibt von Dingen, die bereits veröffentlicht, es ist nicht wirklich so schlimm von einer Sache zu tun.

    Interaktive rebases außerhalb des in der Frage aber um ehrlich zu sein, es ermöglicht Ihnen die Fähigkeit zu ordnen, zu Stauchen und zu entfernen verpflichtet. Ich würde nicht freiwillig wechseln wollen zurück zum Subversion-wie die Geschichte umschreiben nicht möglich ist, durch design.

    InformationsquelleAutor Spoike
  5. 2

    Halten die Antwort, kurz - Im DVCS , da Sie eine lokale Quellcodeverwaltung, wenn etwas geschraubt bekommen in der merge-Prozess (was wird wohl passieren in großen fusioniert), kann man immer rollback zu einem vorherigen lokalen version, die die änderungen, die Sie gemacht haben, bevor Sie das Zusammenführen und versuchen Sie es dann erneut.

    Also im Grunde können Sie tun, verschmelzen, ohne die Angst, dass Ihre lokalen änderungen könnten beschädigt werden, während des Prozesses.

    • Nicht wirklich eine Antwort auf die Frage. Was ist anders in einem DVCS aus dem SVN in deinem Beispiel nicht offensichtlich ist.
    InformationsquelleAutor TheGreyMatter
  6. 2

    Sieht aus wie es ist ein Mythos, dass die Zusammenlegung in Git einfacher, als in SVN...

    Beispielsweise Git kann nicht merge in eine funktionierende Struktur, die änderungen, im Gegensatz zu SVN.

    Betrachten Sie das folgende einfache Szenario:
    Sie haben einige änderungen im working tree und wollen zu integrieren, remote-änderungen, ohne dass Sie Ihre eigenen.

    SVN: update, [Konflikte].

    Git: stash, fetch, rebase, stash pop, [Konflikte lösen], [stash drop wenn es Konflikte].

    Oder kennen Sie einen einfacheren Weg, in Git?

    Btw, diesen Anwendungsfall zu sein scheint, so wichtig, dass IntelliJ einmal umgesetzt das fehlende "Projekt Aktualisieren" - Funktionalität für Git (analogon zu "SVN update"), die automatisiert die manuellen Schritte, die oben beschrieben:

    Wirklich ein konkretes Beispiel, dass die Zusammenführung in Git einfacher als SVN?

    • "Git kann nicht merge in eine funktionierende Struktur, die änderungen, im Gegensatz zu SVN." Tun, mit einem system erlaubt eine einfache lokale commits, wäre dumm. Sie wollen Begehen Ihre lokalen änderungen zuerst, dann die anderen.
    • Hallo Martin. Nein, ich will erste änderungen Zusammenführen von Mitarbeitern in meinem Arbeitsbereich, um sicherzustellen, dass meine änderungen sind immer noch richtig Arbeit auf Sie. Wie sonst kann die Zusammenarbeit funktionieren? Leider Git nicht bieten einen einfachen Weg, das zu erreichen. Nicht sehen, wie lokale commits können hier helfen.
    • git-Weg, solche Dinge zu erstellen, die lokalen Zweige, so dass der workflow ist wie folgt: a) beenden Sie Ihr Teil; b) sich zu verpflichten, lokal (nicht drücken); c) ziehen (führt die merge); d) Prüfung; e) schieben. Und im Allgemeinen sind Sie richtig: git ist in der Regel nicht in der Lage zu verschmelzen übernommene änderungen (fragte ich Fragen vor einigen Jahren, und anscheinend gibt es keinen Fortschritt in der git mit einer solchen Funktion, oder ich bin mir dessen nicht bewusst).
    • Also sagen Sie die git zwingt Sie, um eine Filiale, um Ihre eigenen lokalen änderungen als eigenständige Begehen, ohne "pre-merge" aus jedem anderen Ort. Warum das immer plus? Ist es nicht ein weiterer git minus?
    • mit git können Sie commit lokal und ohne anlegen einer Verzweigung , so dass es nicht Kraft, die Sie zum erstellen von Zweigen, wenn Sie nicht wollen. Der wichtigste Punkt meiner früheren Bemerkung über das Zusammenführen, was git kann automatisch nur, nachdem Sie ein commit für Ihre änderungen (lokal).
    InformationsquelleAutor Eugen Labun
  7. 1

    Wenn Sie ausschließen "Merge-Hölle Umgestalteten" Sie nicht bekommen fair Proben, weil Sie einfach nicht existieren

    InformationsquelleAutor Lazy Badger
Schreibe einen Kommentar