Im schönen Git-Buch von Jon Loeliger, das ich gerade lese, steht, dass jeder Commit auf ein Tree-Objekt zeigt, das das komplette Repository darstellt. (Git speichert Dateien bei Änderung komplett neu, anders als SVN welches nur die Unterschiede speichert um Platz zu sparen). Will man nun zwei Branches zusammen-mergen, müsste es dann doch ausreichen beide Branch-Heads zu vergleichen und die Unterschiede in einen der beiden zu integrieren. Stattdessen lese ich, dass eine Merge-Basis nötig ist, bei der beide Branches auf dem selben Stand waren, um alle Commits seit dem Zeitpunkt einzeln? in einen der beiden Branches zu integrieren. Warum ist das nötig, wenn doch jeder Commit alle benötigten Daten als Kopie enthält? Es klingt so, als ob Git in jedem Commit nur Unterschiede speichern würde, obwohl es doch alle Daten in Kopie speichert. Gibt es hier jemanden, der verstanden hat, wie das genau abläuft?
:
Verschoben durch User
Daniel R. schrieb: > Git speichert Dateien bei Änderung komplett neu Ich stelle diese Prämisse in Frage und damit hat sicher der Rest der Frage erledigt. zusätzlich möchte ich dieses Video empfehlen: https://www.youtube.com/watch?v=1ffBJ4sVUb4
JJ schrieb: > Daniel R. schrieb: >> Git speichert Dateien bei Änderung komplett neu > > Ich stelle diese Prämisse in Frage und damit hat sicher der Rest der > Frage erledigt. > > zusätzlich möchte ich dieses Video empfehlen: > https://www.youtube.com/watch?v=1ffBJ4sVUb4 Danke für den Link. Tatsächlich soll für jede veränderte Datei in einem Commit ein neues Blob-Objekt erstellt werden. Der neue Tree im Commit zeigt dann auf die neuen Blobs veränderter Dateien und auf die alten Blobs unveränderter Dateien. Laut dem Buch: -Speichert SVN (u.a.) Veränderungen an Dateien um Speicherplatz zu sparen. -Müssen bei SVN um ein Diff zwischen zwei Commits zu ermitteln, sämtliche dazwischenliegenden Commits angesehen werden, alle Diffs zwischen diesen gesammelt werden und zusammen gemerged werden, um dem Benutzer den Gesamt-Diff präsentieren zu können. (Kostet viel Zeit). -Ist jeder Tree in einem Git-Commit unabhängig von allen anderen Trees. -Gibt es im Git-Repository keine Diffs (Diff-Objekte wie bei SVN). -Benötigt Git für ein Diff zweier Commits keine dazwischenliegenden Commits. Git arbeite direkt auf Snapshots der Komplettzustände beider Versionen. Dieser einfache Unterschied im Speichersystem sei einer der wichtigsten Gründe dafür, dass Git so viel schneller ist als andere Versionskontrolsysteme. (Sinngemäß übersetzt).
Dies hat meine Frage beantwortet: https://www.slideshare.net/epatey/perforce-convergence-vs-divergence/10
Daniel R. schrieb: > Laut dem Buch: Wenn das so wirklich im Buch steht: wegwerfen :) Probier es mal hiermit: https://www.atlassian.com/git/tutorials Git speichert auch nur diffs, interessiert aber nicht wirklich fuer Dateien/Verzeichnisse sondern eben nur fuer den Inhalt. Hier mal etwas bunte Doku zu deiner ersten Frage bez. der "Merge Basis": https://www.atlassian.com/git/tutorials/using-branches
Skippy schrieb: > Git speichert auch nur diffs, interessiert aber nicht wirklich fuer > Dateien/Verzeichnisse sondern eben nur fuer den Inhalt. Ich habe diese Seite gefunden: https://stackoverflow.com/questions/10398744/does-git-store-diff-information-in-commit-objects Auf der steht: Git stores references to complete blobs and this means that with git, *only one commit is sufficient to recreate the codebase at that point in time*. Git does not need to look up information from past revisions to create a snapshot. Dieser Link: https://stackoverflow.com/questions/4129049/why-is-a-3-way-merge-advantageous-over-a-2-way-merge hat mir geholfen zu verstehen, dass die Merge-Basis nötig ist um bei einem Merge von zwei Branches herauszufinden welcher der vier Fälle wahr ist: 1) Eine Zeile (oder Wort, Datei, etc.) ist in beiden Branches noch im Originalzustand. Wird dann so ins Merge-Ergebnis übernommen. 2) Eine Zeile ist in einem Branch noch im Originalzustand, im anderen verändert. Dann wird die veränderte Variante ins Merge-Ergebnis übernommen. 3) Eine Zeile wurde in beiden Branches verändert und ist in beiden gleich und wird ins Merge-Ergebnis übernommen. 4) Eine Zeile wurde in beiden Branches verändert und zwar in unterschiedlicher Weise. Das ist dann ein Merge-Konflikt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.