Frage Git Workflow und Rebase vs Fragen zusammenführen


Ich benutze Git jetzt seit ein paar Monaten bei einem Projekt mit einem anderen Entwickler. Ich habe mehrere Jahre Erfahrung mit SVNIch denke, ich bringe viel Gepäck mit in die Beziehung.

Ich habe gehört, dass Git hervorragend zum Verzweigen und Zusammenführen geeignet ist, und bis jetzt sehe ich es einfach nicht. Sicher, Verzweigen ist tot einfach, aber wenn ich versuche zu verschmelzen, geht alles in die Hölle. Nun, ich bin das von SVN gewöhnt, aber es scheint mir, dass ich gerade ein Unterversionssystem für ein anderes gehandelt habe.

Mein Partner sagt mir, dass meine Probleme von meinem Wunsch herrühren, Willy-Nilly zu verschmelzen, und dass ich Rebase anstelle von Merge in vielen Situationen verwenden sollte. Zum Beispiel, hier ist der Workflow, den er festgelegt hat:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature
git checkout master
git merge my_new_feature

Im Wesentlichen erstellen Sie einen Feature-Zweig, IMMER Rebase vom Master zum Zweig und Zusammenführung vom Zweig zurück zum Master. Wichtig zu beachten ist, dass der Zweig immer lokal bleibt.

Hier ist der Workflow, mit dem ich angefangen habe

clone remote repository
create my_new_feature branch on remote repository
git checkout -b --track my_new_feature origin/my_new_feature
..work, commit, push to origin/my_new_feature
git merge master (to get some changes that my partner added)
..work, commit, push to origin/my_new_feature
git merge master
..finish my_new_feature, push to origin/my_new_feature
git checkout master
git merge my_new_feature
delete remote branch
delete local branch

Es gibt zwei wesentliche Unterschiede (denke ich): Ich benutze Merge immer statt Rebasing, und ich schiebe meinen Feature-Zweig (und meinen Feature-Zweig Commits) auf das Remote-Repository.

Meine Argumentation für den Remote-Zweig ist, dass ich möchte, dass meine Arbeit gesichert wird, während ich arbeite. Unser Repository wird automatisch gesichert und kann wiederhergestellt werden, wenn etwas schief geht. Mein Laptop ist nicht oder nicht so gründlich. Deshalb hasse ich Code auf meinem Laptop, der nicht woanders gespiegelt wird.

Meine Schlussfolgerung für die Zusammenführung anstelle von Rebase ist, dass Merge Standard zu sein scheint und Rebase ein fortgeschrittenes Feature zu sein scheint. Mein Bauchgefühl ist, dass das, was ich versuche, kein fortgeschrittenes Setup ist, daher sollte Rebase unnötig sein. Ich habe sogar das neue Pragmatische Programmierbuch über Git gelesen, und sie decken Merge ausgiebig ab und erwähnen kaum Rebase.

Wie auch immer, ich habe meinen Workflow in einem neuen Zweig verfolgt, und als ich versuchte, ihn wieder mit dem Master zu verbinden, ging alles in die Hölle. Es gab Tonnen von Konflikten mit Dingen, die eigentlich keine Rolle spielen sollten. Die Konflikte ergaben für mich keinen Sinn. Ich brauchte einen Tag, um alles zu sortieren, und gipfelte schließlich in einem erzwungenen Push zum Remote-Master, da mein lokaler Master alle Konflikte gelöst hatte, aber der Remote war immer noch nicht glücklich.

Was ist der "richtige" Workflow für so etwas? Git soll Verzweigen und Verschmelzen superleicht machen, und ich sehe es einfach nicht.

Update 2011-04-15

Dies scheint eine sehr beliebte Frage zu sein, also dachte ich, ich würde mit meiner zweijährigen Erfahrung seit meiner ersten Anfrage fortfahren.

Es stellt sich heraus, dass der ursprüngliche Workflow zumindest in unserem Fall korrekt ist. Mit anderen Worten, das ist was wir tun und es funktioniert:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge my_new_feature

In der Tat ist unser Workflow etwas anders, als wir es normalerweise tun Squash verschmilzt anstelle von rohen Zusammenführungen. (Hinweis: Dies ist umstritten, siehe unten.) Dadurch können wir unseren gesamten Feature-Zweig in einen einzigen Commit auf Master umwandeln. Dann löschen wir unseren Feature-Zweig. Dies ermöglicht es uns, unsere Commits auf Master logisch zu strukturieren, auch wenn sie in unseren Filialen etwas unordentlich sind. Also, das ist was wir machen:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git checkout master
git merge --squash my_new_feature
git commit -m "added my_new_feature"
git branch -D my_new_feature

Squash Merge Kontroverse - Wie mehrere Kommentatoren darauf hingewiesen haben, wird der Squash-Merge den gesamten Verlauf deines Feature-Zweigs wegwerfen. Wie der Name schon sagt, reduziert es alle Commits in einen einzigen. Bei kleinen Features ist dies sinnvoll, da es sich in einem einzigen Paket zusammenfasst. Für größere Features ist es wahrscheinlich keine gute Idee, besonders wenn Ihre individuellen Commits bereits atomar sind. Es kommt wirklich auf persönliche Vorlieben an.

Github und Bitbucket (andere?) Pull Requests - Falls Sie sich fragen, wie merge / rebase sich auf Pull Requests bezieht, empfehle ich Ihnen, alle oben genannten Schritte zu befolgen, bis Sie bereit sind, zum Master zurückzukehren. Anstatt manuell mit git zu verschmelzen, akzeptieren Sie einfach den PR. Konkret funktioniert es so:

clone the remote repository
git checkout -b my_new_feature
..work and commit some stuff
git rebase master
..work and commit some stuff
git rebase master
..finish the feature, commit
git rebase master
git push # May need to force push
...submit PR, wait for a review, make any changes requested for the PR
git rebase master
git push # Will probably need to force push (-f), due to previous rebases from master
...accept the PR, most likely also deleting the feature branch in the process
git checkout master
git branch -d my_new_feature
git remote prune origin

Ich habe Git geliebt und möchte nie wieder zum SVN gehen. Wenn Sie Probleme haben, bleiben Sie einfach dabei und schließlich werden Sie das Licht am Ende des Tunnels sehen.


895
2018-01-19 15:16


Ursprung


Antworten:


"Konflikte" bedeuten "parallele Entwicklungen gleichen Inhalts". Wenn es also während einer Zusammenführung "alles zur Hölle" geht, bedeutet das, dass Sie massive Entwicklungen auf dem gleichen Satz von Dateien haben.

Der Grund, warum eine Rebase dann besser ist als eine Zusammenführung ist, dass:

  • Sie schreiben Ihren lokalen Commit-Verlauf mit dem des Masters um (und wenden Sie Ihre Arbeit erneut an, um einen Konflikt zu lösen)
  • Die endgültige Zusammenführung wird sicherlich eine "schnelle Weiterleitung" sein, da sie die gesamte Commit-Historie des Masters hat und nur Ihre Änderungen erneut angewendet werden müssen.

Ich bestätige, dass der richtige Workflow in diesem Fall (Entwicklungen auf gemeinsamen Dateien) ist Rebase zuerst, dann zusammenführen.

Dies bedeutet jedoch, dass, wenn Sie Ihren lokalen Zweig (aus Gründen der Sicherung) drücken, dieser Zweig nicht von irgendjemand anderen gezogen (oder zumindest verwendet) werden sollte (da der Commit-Verlauf durch die nachfolgende Rebase neu geschrieben wird).


Zu diesem Thema (Rebase, dann Workflow zusammenführen), Barraponto Erwähnt in den Kommentaren zwei interessante Beiträge, beide aus randyfay.com:

Mit dieser Technik geht Ihre Arbeit immer an die Spitze der öffentlichen Verwaltung wie ein Patch, der aktuell ist HEAD.

(Eine ähnliche Technik existiert für Basar)


342
2018-01-19 15:32



TL; DR

Ein git-rebase-Workflow schützt Sie nicht vor Personen, die bei der Konfliktlösung schlecht sind, oder Personen, die an einen SVN-Workflow gewöhnt sind, wie in Git-Katastrophen vermeiden: Eine gorische Geschichte. Es macht die Konfliktlösung nur mühsam für sie und macht es schwieriger, sich von einer schlechten Konfliktlösung zu erholen. Verwenden Sie stattdessen diff3, damit es nicht so schwierig ist.


Der Rebase-Workflow ist nicht besser für die Konfliktlösung!

Ich bin sehr pro-Rebase für die Reinigung der Geschichte. Wie auch immer, wenn Ich habe je einen Konflikt gemacht, ich bringe sofort die Rebase ab und mache stattdessen eine Zusammenführung!Es bringt mich wirklich um, dass Leute einen Rebase-Workflow als eine bessere Alternative zu einem Merge-Workflow zur Konfliktlösung empfehlen (worum genau diese Frage ging).

Wenn es während eines Merge "alles zur Hölle" geht, wird es während einer Rebase "alles zur Hölle" und möglicherweise viel mehr Hölle auch gehen! Hier ist der Grund:

Grund # 1: Lösen Sie Konflikte einmal statt einmal für jeden Commit

Wenn Sie ein Rebase statt einer Zusammenführung durchführen, müssen Sie die Konfliktlösung so oft durchführen, wie Sie für denselben Konflikt eine Rebase durchführen.

Echtes Szenario

Ich verzweige mich vom Meister, um eine komplizierte Methode in einer Verzweigung umzubauen. Meine Refactoring-Arbeit umfasst insgesamt 15 Commits, während ich daran arbeite, sie zu überarbeiten und Code-Reviews zu erhalten. Ein Teil meines Refactorings beinhaltet das Reparieren der gemischten Registerkarten und Leerzeichen, die zuvor im Master vorhanden waren. Dies ist notwendig, aber leider wird es im Konflikt mit jeder Änderung stehen, die nach dieser Methode im Master vorgenommen wird. Sicher genug, während ich an dieser Methode arbeite, macht jemand eine einfache, legitime Änderung an derselben Methode im Hauptzweig, die mit meinen Änderungen zusammengeführt werden soll.

Wenn es Zeit ist, meinen Zweig wieder mit dem Master zusammenzuführen, habe ich zwei Möglichkeiten:

Git zusammenführen:  Ich bekomme einen Konflikt. Ich sehe die Veränderung, die sie gemacht haben, um sie zu beherrschen und sie mit (dem Endprodukt) meiner Branche zu verbinden. Erledigt.

Git-Rebase:  Ich bekomme einen Konflikt mit meinem zuerst verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem zweite verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem dritte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem vierte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem fünfte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem sechste verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem siebte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem achte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem neunte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem Zehntel verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem elfte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem Zwölftel verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem dreizehnte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem vierzehnte verpflichten. Ich löse den Konflikt und setze die Rebase fort. Ich bekomme einen Konflikt mit meinem fünfzehnten verpflichten. Ich löse den Konflikt und setze die Rebase fort.

Sie müssen mich verarschen, wenn Dies ist dein bevorzugter Workflow. Alles was es braucht, ist ein Whitespace-Fix, der mit einer Änderung im Master konfligiert, und jedes Commit wird konfligieren und muss gelöst werden. Und das ist ein einfach Szenario mit nur einem Leerzeichenkonflikt. Gott bewahre, dass du einen echten Konflikt hast, der große Codeänderungen über Dateien hinweg beinhaltet und lösen musst Das mehrmals.

Mit all der zusätzlichen Konfliktlösung, die Sie tun müssen, erhöht es nur die Möglichkeit, dass Sie werden einen Fehler machen. Aber Fehler sind gut in Git, da Sie rückgängig machen können, oder? Außer natürlich ...

Grund # 2: Mit Rebase gibt es keine Rückgängig machen!

Ich denke, wir können uns alle einig sein, dass die Konfliktlösung schwierig sein kann und dass einige Menschen sehr schlecht darin sind. Es kann sehr anfällig für Fehler sein, weshalb es so toll ist, dass es Git leicht macht, es rückgängig zu machen!

Wenn Sie zusammenführen Eine Verzweigung, git erstellt ein Merge-Commit, das verworfen oder geändert werden kann, wenn die Konfliktlösung schlecht abläuft. Auch wenn Sie die fehlerhafte Zusammenführung bereits in den öffentlichen / autoritativen Repo übertragen haben, können Sie verwenden git revertum die durch die Zusammenführung eingeführten Änderungen rückgängig zu machen und die Zusammenführung in einem neuen Zusammenführungs-Commit korrekt wiederherzustellen.

Wenn du umbugst ein Zweig, in dem wahrscheinlichen Fall, dass die Konfliktlösung falsch gemacht wird, bist du geschraubt. Jedes Commit enthält nun die fehlerhafte Zusammenführung und Sie können nicht einfach die Rebase * wiederherstellen. Im besten Fall müssen Sie zurückgehen und alle betroffenen Commits ändern. Kein Spaß.

Nach einer Rebase ist es unmöglich zu bestimmen, was ursprünglich Teil der Commits war und was als Ergebnis einer schlechten Konfliktlösung eingeführt wurde.

* Es kann möglich sein, eine Rebase rückgängig zu machen, wenn Sie die alten Refs aus den internen Logs von git herausholen können oder wenn Sie einen dritten Branch erstellen, der auf den letzten Commit vor dem Rebasieren zeigt.

Nimm die Konfliktlösung aus der Hand: benutze diff3

Nehmen Sie diesen Konflikt zum Beispiel:

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

Wenn man den Konflikt betrachtet, ist es unmöglich zu sagen, was jeder Zweig verändert hat oder was er beabsichtigt hat. Dies ist meiner Meinung nach der Hauptgrund, warum Konfliktlösung verwirrend und schwierig ist.

diff3 zur Rettung!

git config --global merge.conflictstyle diff3

Wenn Sie das diff3 verwenden, hat jeder neue Konflikt einen dritten Abschnitt, den gemeinsamen gemeinsamen Vorfahren.

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
||||||| merged common ancestor
EmailMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

Untersuche zuerst den verschmolzenen gemeinsamen Vorfahren. Dann vergleichen Sie jede Seite, um die Absicht jedes Zweiges zu bestimmen. Sie können sehen, dass HEAD EmailMessage in TextMessage geändert hat. Seine Absicht ist es, die Klasse, die für TextMessage verwendet wird, zu ändern und die gleichen Parameter zu übergeben. Sie können auch erkennen, dass die Absicht des Feature-Zweigs darin besteht, anstelle der Option "include_timestamp" false anstelle von true zu übergeben. Um diese Änderungen zusammenzuführen, kombinieren Sie die Absicht beider:

TextMessage.send(:include_timestamp => false)

Im Algemeinen:

  1. Vergleichen Sie den gemeinsamen Vorfahren mit jedem Zweig und bestimmen Sie, welcher Zweig die einfachste Änderung hat
  2. Wenden Sie diese einfache Änderung auf die Codeversion des anderen Zweigs an, sodass sie sowohl die einfachere als auch die komplexere Änderung enthält
  3. Entfernen Sie alle Abschnitte mit anderem Konfliktcode als den, in den Sie die Änderungen gerade zusammengeführt haben

Alternativ: Beheben Sie, indem Sie die Änderungen des Zweigs manuell anwenden

Schließlich sind einige Konflikte sogar mit diff3 schrecklich zu verstehen. Dies geschieht insbesondere dann, wenn diff gemeinsame Zeilen findet, die nicht semantisch üblich sind (z. B. haben beide Zweige zufällig eine Leerzeile an derselben Stelle!). Zum Beispiel ändert ein Zweig die Einrückung des Körpers einer Klasse oder ordnet ähnliche Methoden neu an. In diesen Fällen kann eine bessere Lösungsstrategie darin bestehen, die Änderung von beiden Seiten der Zusammenführung zu untersuchen und das Diff manuell auf die andere Datei anzuwenden.

Schauen wir uns an, wie wir einen Konflikt in einem Szenario lösen könnten, in dem eine Zusammenführung stattfindet origin/feature1 woher lib/message.rb Konflikte.

  1. Entscheiden Sie, ob unsere aktuell ausgecheckte Filiale (HEAD, oder --ours) oder der Zweig, den wir zusammenführen (origin/feature1, oder --theirs) ist eine einfachere Änderung anzuwenden. Diff mit Tripelpunkt verwenden (git diff a...b) zeigt die Änderungen an, die passiert sind b seit seiner letzten Abweichung von aoder, mit anderen Worten, vergleiche den gemeinsamen Vorfahren von a und b mit b.

    git diff HEAD...origin/feature1 -- lib/message.rb # show the change in feature1
    git diff origin/feature1...HEAD -- lib/message.rb # show the change in our branch
    
  2. Überprüfen Sie die kompliziertere Version der Datei. Dadurch werden alle Konfliktmarker entfernt und die ausgewählte Seite verwendet.

    git checkout --ours -- lib/message.rb   # if our branch's change is more complicated
    git checkout --theirs -- lib/message.rb # if origin/feature1's change is more complicated
    
  3. Wenn die komplizierte Änderung ausgecheckt ist, ziehen Sie das Diff der einfacheren Änderung hoch (siehe Schritt 1). Wenden Sie jede Änderung von diesem Unterschied auf die widersprüchliche Datei an.


358
2018-06-27 04:25



In meinem Workflow rebase ich so viel wie möglich (und ich versuche, es oft zu tun. Nicht zulassen, dass sich die Diskrepanzen drastisch anhäufen, reduziert die Menge und die Schwere von Kollisionen zwischen Zweigen).

Aber auch in einem weitgehend auf Rebases basierenden Workflow gibt es einen Platz für Zusammenführungen.

Denken Sie daran, dass die Zusammenführung tatsächlich einen Knoten mit zwei Eltern erstellt. Betrachten wir nun die folgende Situation: Ich habe zwei unabhängige Feature-Branches A und B und möchte nun Sachen auf Feature-Zweig C entwickeln, die sowohl von A als auch von B abhängen, während A und B überprüft werden.

Was ich dann mache, ist folgendes:

  1. Erstellen Sie (und checken Sie) Zweig C auf A.
  2. Füge es mit B zusammen

Jetzt enthält Zweig C Änderungen von A und B, und ich kann mich weiter darauf entwickeln. Wenn ich eine Änderung an A mache, rekonstruiere ich den Graphen von Zweigen folgendermaßen:

  1. Erstellen Sie Zweig T auf der neuen Spitze von A
  2. füge T mit B zusammen
  3. rebase C auf T
  4. Zweig löschen T

Auf diese Weise kann ich zwar beliebige Graphiken von Zweigen pflegen, aber etwas komplexeres als die oben beschriebene Situation ist bereits zu komplex, da es kein automatisches Werkzeug gibt, um das Umbasieren durchzuführen, wenn sich das Elternteil ändert.


29
2018-05-12 20:54



Verwenden Sie nicht git push Herkunft - Spiegel unter fast jeder Umgebung.

Es fragt nicht, ob Sie sicher sind, dass Sie dies tun möchten, und Sie sollten besser sicher sein, da es alle Ihre Remote-Zweigstellen löscht, die sich nicht in Ihrer lokalen Box befinden.

http://twitter.com/dysinger/status/1273652486


20
2018-04-10 01:06



Ich habe eine Frage nach dem Lesen Ihrer Erklärung: Könnte es sein, dass Sie nie ein

git checkout master
git pull origin
git checkout my_new_feature

Bevor Sie den 'git rebase / merge master' in Ihrem Feature-Zweig ausführen?

weil Ihre Master-Zweig wird nicht automatisch vom Repository Ihres Freundes aktualisiert. Du musst das mit dem tun git pull origin. I.e. vielleicht würden Sie immer von einem sich nie ändernden lokalen Meisterzweig ablehnen? Und dann komm Push-Zeit, du schiebst ein Repository ein, das (lokale) Commits hat, die du nie gesehen hast und somit scheitert der Push.


13
2018-05-25 20:52



In Ihrer Situation denke ich, dass Ihr Partner richtig ist. Was ist schön an Rebasing ist, dass für den Außenseiter Ihre Änderungen aussehen wie sie alle in einer sauberen Reihenfolge ganz von selbst passiert sind. Das heisst

  • Ihre Änderungen sind sehr einfach zu überprüfen
  • Sie können weiterhin nette, kleine Commits machen und dennoch können Sie Sets dieser Commits auf einmal veröffentlichen (indem Sie zum Master werden)
  • Wenn Sie sich den öffentlichen Master-Zweig ansehen, sehen Sie verschiedene Commits für verschiedene Features von verschiedenen Entwicklern, aber sie werden nicht alle miteinander vermischt

Sie können weiterhin Ihren privaten Entwicklungszweig zum Zwecke der Datensicherung in das Remote-Repository verschieben, aber andere sollten dies nicht als "öffentliche" Zweigstelle behandeln, da Sie eine Neuausrichtung durchführen. BTW, ein einfacher Befehl dafür ist git push --mirror origin .

Der Artikel Packsoftware mit Git macht einen ziemlich guten Job und erklärt die Kompromisse zwischen Fusion und Rebasing. Es ist ein etwas anderer Kontext, aber die Prinzipien sind die gleichen - es kommt im Grunde darauf an, ob Ihre Niederlassungen öffentlich oder privat sind und wie Sie planen, sie in die Hauptlinie zu integrieren.


12
2018-01-19 16:15



Wie auch immer, ich habe meinen Workflow in einem neuen Zweig verfolgt, und als ich versuchte, ihn wieder mit dem Master zu verbinden, ging alles in die Hölle. Es gab Tonnen von Konflikten mit Dingen, die eigentlich keine Rolle spielen sollten. Die Konflikte ergaben für mich keinen Sinn. Ich brauchte einen Tag, um alles zu sortieren, und gipfelte schließlich in einem erzwungenen Push zum Remote-Master, da mein lokaler Master alle Konflikte gelöst hatte, aber der Remote war immer noch nicht glücklich.

Weder in Ihrem Partner noch in Ihren vorgeschlagenen Arbeitsabläufen sollten Sie auf Konflikte stoßen, die keinen Sinn ergeben. Selbst wenn Sie dies getan hätten, wenn Sie den vorgeschlagenen Arbeitsabläufen folgen, sollte nach der Auflösung kein "erzwungenes" Drücken erforderlich sein. Es deutet darauf hin, dass Sie den Zweig, zu dem Sie gedrängt haben, nicht zusammengeführt haben, aber einen Zweig schieben mussten, der kein Abkömmling der entfernten Spitze war.

Ich denke, du musst genau hinsehen, was passiert ist. Könnte jemand (absichtlich oder nicht) den Remote-Master-Zweig zwischen Ihrer Erstellung des lokalen Zweigs und dem Punkt, an dem Sie ihn wieder in den lokalen Zweig einfügen wollten, zurückgespult haben?

Im Vergleich zu vielen anderen Versionskontrollsystemen habe ich festgestellt, dass die Verwendung von Git weniger mit dem Kampf gegen das Tool zu tun hat und es Ihnen ermöglicht, an den Problemen zu arbeiten, die für Ihre Quelldatenströme grundlegend sind. Git führt keine Magie aus, daher verursachen widersprüchliche Änderungen Konflikte, aber es sollte es einfacher machen, das Schreib-Ding zu machen, indem es die Commit-Abstammung verfolgt.


11
2018-01-19 19:30



Nach dem, was ich beobachtet habe, tendiert git merge dazu, die Zweige auch nach dem Zusammenführen getrennt zu halten, während rebase dann merge es zu einem einzigen Zweig verbindet. Letzteres ist viel sauberer, während es im ersteren einfacher wäre, herauszufinden, welche Commits zu welchem ​​Zweig gehören, selbst nach dem Zusammenführen.


6
2017-08-25 05:40



"Selbst wenn Sie ein einzelner Entwickler mit nur wenigen Zweigen sind, lohnt es sich, sich die Gewohnheit zu Nutze, Rebase zu verwenden und richtig zusammenzuführen. Das grundlegende Arbeitsmuster sieht folgendermaßen aus:

  • Erstellen Sie einen neuen Zweig B aus dem vorhandenen Zweig A

  • Hinzufügen / Übernehmen von Änderungen in Zweig B

  • Aktualisierungen von Zweigstelle A aktualisieren

  • Änderungen von Zweig B auf Zweig A zusammenführen

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/


6
2018-03-22 16:16



Mit Git gibt es keinen "richtigen" Workflow. Benutze, was auch immer dein Boot schwimmt. Wenn Sie jedoch beim Zusammenführen von Filialen ständig Konflikte bekommen, sollten Sie Ihre Bemühungen besser mit Ihren Kollegen koordinieren. Klingt so, als ob ihr beide die gleichen Dateien bearbeitet. Achten Sie auch auf Whitespace- und Subversion-Schlüsselwörter (d. H. "$ Id $" und andere).


2
2018-01-19 15:25