git-svn workflow - feature-branches und merge

Ich bin mit git-svn mit dem folgenden workflow jetzt

git clone <SVN TRUNK URL> #done once

anschließend wenn ich auf ein feature

git branch featureZ
git checkout featureZ
#make edits for featureZ
git commit

git checkout master
git svn rebase # fetch changes from server

git checkout featureZ #go back to branch
#git merge master 
git rebase master #get the changes from SVN->master onto the branch now. Optional if I want the branch to be current. (EDITED: Got from the answer given below)

#make edits for featureZ
git commit #featureZ completed

git checkout master
git merge featureZ #getting featureZ onto master. Prepare to send to SVN

git svn dcommit #push featureZ back to SVN

Nun einige Punkte beachten, wenn ich ein git merge feature auf master, alle die einzelnen commits in featureZ Zweig bekommt zusammengeführt als eine, die in Ordnung ist mit mir.

Die commit-Nachricht ersetzt wird als "verbunden" mit featureZ". Das kann behoben werden mit fmt-merge-msg.

Nun meine Frage ist
Gibt es etwas, das schief gehen kann mit diesem workflow oder muss gesorgt werden. Ich lese in git-svn-Handbuch, dass die merge-sollte nicht getan werden, wenn die Arbeit mit git-svn. Ist das, was ich Tue in meinem workflow ist das, was Sie sich beziehen? wenn ja, welche Art von problem verursacht es? Eine Sache, die ich nicht wollen, etwas zu tun, das verwirrt mit der SVN-Magistrale.

  • btw, können Sie git checkout -b statt git branch ..;git checkout. Auch ist Es üblich mit co alias für checkout Befehl.
InformationsquelleAutor Pradeep | 2009-07-15
  1. 26

    SVN nicht in den Griff, nicht-lineare Geschichte (es hat einfach keine notation von ihm). Also, was Sie tun möchten, ist ein Stellungswechsel statt einer Zusammenführen, wie es bewahrt lineare Geschichte mit SVN (dies ist erkennbar in der git-svn Mann Seite hier.

    Aufwendige, lineare Geschichten sind trivial. Sie gehen in einer geraden Linie (A nach B zu C zu D). In der Erwägung, dass nicht-lineare Geschichte kann von A zu B zu C, B zu D, dann C + D-E--in anderen Worten, Sie sprießen aus in den Zweigen).

    Rebasierung wird Ihnen eine lineare Geschichte. Denken Sie daran, dass rebases getan werden sollte, von Ihrem eigenen lokalen Niederlassungen. Für Instanzen, wenn du 2 branches: master und experimentell. Sie würde Kasse experimentelle und tun "git rebase master" - vorzugsweise mit der -i-flag. Tut es die andere Weise herum kann in der Folge zu unerwünschten Nebenwirkungen.

    Ist es dann checkout master und merge die änderungen aus dem experimentellen Zweig. Ihre Geschichte sollte weiterhin linear.

    • könnten Sie erklären, was ist nicht-lineare Geschichte? Eine andere Sache ist, ich will nicht(care), die SVN muss wissen, dass ich hatte, lokalen Zweige, die ich zusammengeführt. wo schlagen Sie vor, Stellungswechsel getan werden muss, um in meinem workflow? git rebase featureZ?
    • Ich erläuterte meine Antwort. Hoffe, es hilft. 🙂
    • Danke für die Erklärung. Ich Verstand, was nicht-lineare Geschichte ist, obwohl ich erstellen nur lineare Verläufe, so weit(neu verzweigen sich). So, jetzt vorbereitet werden, um für nicht-lineare Geschichten ich begann mit git rebase master aus dem feature-branch zu ziehen, die änderungen vom master auf den feature-branch. Dies funktioniert sehr gut. Es zog die änderungen vom master auf meinen Zweig und wiedergegeben mein begeht oben drauf. Also die einzige änderung ist die Verwendung von "git rebase master" anstelle von "git merge master" - Zweig aus. Die letzten "git merge featureZ" aus dem master-branch ist ok dann?
    • Ja, das ist im Grunde es. So wiederhaben wieder, die Sie wollen zu tun "git rebase master" anstelle von "git merge master" aus dem featureZ Zweig und dann "git merge featureZ' aus dem master-branch. Natürlich denken Sie daran, um zu überprüfen, Ihre Geschichte mit 'git log --graph --dekorieren --abbrev-commit', gitk oder gitview um sicherzustellen, dass Sie erreicht die Ergebnisse, die Sie wollten.
    • Dank Rashid. Verstanden den Gebrauch des rebase-Befehl in diesem workflow. Ich bin in der Lage zu Folgen rebase manuell nun, da Sie sich auf diese. (Hinweis: ich habe nur getestet, mit einem linearen Verlauf in featureZ Branche aber laut Handbuch Stellungswechsel kann die Transplantation nicht-lineare Geschichten als gut)
    InformationsquelleAutor Fake Code Monkey Rashid
  2. 4

    Sollten Sie auf diesen merge-option:

    git checkout master
git merge --squash featureZ

    Wird es squash alle commits auf dem branch zu einem einzigen commit auf dem master-branch. Sie erhalten die Möglichkeit zum Bearbeiten der log-Meldung, die wird initialisiert mit einer Zusammenfassung, was gemacht wurde, auf dem ast.

    Es hat den Nachteil, dass die einzelnen commit auf dem feature-branch nicht erfasst werden. Darüber hinaus sollten Sie nur tun, dieses eine mal, und nicht mehr Arbeit auf die Branche, weil es nicht registriert ist, wie eine richtige Zusammenführen, und spätere Zusammenführung geben könnte zu unerwünschten Ergebnissen.

    • Kürbisse zerstören Zweig Geschichte und so kann ich nicht empfehlen. Wenn ich könnte, down-vote, ich würde (und werde ich).
    • Kürbisse würde Sinn machen, wenn ich nicht die möchten, dass der lokale Zweig der Geschichte erfasst werden. Ich könnte senden Sie eine einzige fat-commit von SVN auf die Hauptstrecke, die würden alle ausblenden, die Verzweigung, die ich getan hatte, wenn ich es will. gut, dass git nicht verhindern. Dank Ropez.
    • Ja, wohl hat es verwendet, aber ich glaube, dass die Geschichte zu kostbar sein. Die am weitesten, dann würde ich leicht umschreiben es mit die am wenigsten invasive Methode zur Verfügung und squash ist sehr invasiv. Es zerstört alle änderungen, die Sie vorgenommen haben, und die Reihenfolge, die Sie vorgenommen. Es blendet alle Fehler und silver linings, die halfen, Sie zu lösen. Es löscht die person und gibt Ihnen einen enorm unpersönlich Endergebnis (ie: das einzige Fett-commit). Aber das ist nur meine aktuelle Meinung ist, und du nicht mich. Also ich Stimme auf den Punkt, dass es gut ist, dass git ist flexibel. 🙂
    • Sizzler sagte, "all die einzelnen commits in featureZ Zweig bekommt zusammengeführt als eine, die ist in Ordnung mit mir". Quetschen verpflichtet ist vielleicht nicht eine intelligente Sache zu tun, im Allgemeinen, aber es ist eine option, die gemeint ist, für genau die oben beschriebene situation, wenn die einzelnen commits in den feature-branch ist nicht wichtig. Es ist sicherlich eine option, die relevant für diese Frage.
    • Bearbeiten, um eine Warnung enthalten, zu verlieren einzelnen commits
    • Als eine zusätzliche Anmerkung, die Sie eigentlich gar nicht "verlieren", die Geschichte - es gibt Sie noch in Ihrem git-repository. Wenn Sie brauchte, um zu teilen, die Geschichte, ich bin mir ziemlich sicher, dass Sie tun könnte, die git-svn-Zweig und wenden diese sich verpflichtet, die Niederlassung und dann verbindet es sich wieder mit git-svn

    InformationsquelleAutor Ropez
  3. 2

    Die Antwort, die wir von fake-code-monkey-rashid, der richtige ist. Dies ist weniger eine Antwort als vielmehr eine Vereinfachung.

    Können Sie svn rebase/dcommit aus beliebigen git-Zweig. Der einzige nutzen master haben würde, wenn Sie hatte andere lokalen änderungen, die Sie benötigt, um zu verschmelzen mit den änderungen aus featureZ.

    git branch featureZ
git checkout featureZ
#bunch of changes
git commit
git svn rebase
# solve any conflicts
git svn dcommit

    Wenn Sie möchten, um eine saubere master, dann können Sie entweder git svn rebase oder git merge featuresZ

    InformationsquelleAutor John K
  4. 0

    Anstelle von git-svn, können Sie SubGit. Es ist ein Serverseitiges tool, das automatisch synchronisiert Subversion-und Git-repositories.

    Können Sie alle Git-workflow und jedem Git-client zur Verfügung, es ist keine zusätzliche client-tools benötigt.

    Angesichts Szenario:

    git branch featureZ
git checkout featureZ
# make edits for featureZ
git commit
git checkout master

    Können Sie wie folgt Vorgehen:

    1. Push-Funktion Zweig vollständig.

      git merge featureZ
git push origin refs/heads/*

    2. Stellungswechsel ein Zweig auf der Oberseite des master/trunk.

      git rebase featureZ
git push

    3. Squash verpflichtet Zweiges.

      git merge --squash featureZ
git commit
git push

    Sobald Sie push verpasst, SubGit Haken übersetzen Sie Ihre änderungen in das Subversion-Revisionen.

    Einige weitere details:

    • SubGit ist in vieler Hinsicht besser als git-svn — besser merge-tracking-übersetzung, EOLs & mime-type, etc.
    • SubGit muss lokalen Zugriff auf Subversion-repository (es verwendet eine benutzerdefinierte Haken);
    • SubGit ist ein kommerzielles Produkt mit einigen Optionen ohne (open-source-und wissenschaftliche Projekte, kleine teams).
    InformationsquelleAutor vadishev
Schreibe einen Kommentar