bin gerade am ausprobieren von GIT. Ich habe ein Repository gecloned,
eine Änderung gemacht, die Datei mit add in die Stage übertragen und
dann einen commit gemacht. Die Anzeige ist jetzt:
>git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
>
Wie kann ich hier eine patch Datei erzeugen ? Git diff erzeugt keine
Ausgabe. Hätte ich das früher tun sollen ?
Git ist eigentlich recht logisch strukturiert, aber es ist halt einiges
an Umgewöhnung wenn man von einem anderen System kommt.
Wenn es schon mehrere Commits sind kannst du auch "git diff $COMMITID$"
wobei $COMMITID$ die ID des letzten Commits vor deinen Änderungen ist
machen.
Idealerweise würdest du aber immer einen neuen Branch anlegen und kannst
dann einfach "git diff master" machen um alle Änderungen in Bezug auf
den master Branch anzuzeigen.
Sven B. schrieb:> git format-patch HEAD^..HEAD
Danke, die erste richtige antwort.
Oder auch git format-patch HEAD~
(HEAD ist dabei der aktuellste lokale commit und ~ gibt an, diesen
commit in format-patch inkludieren
Hermann K. schrieb:> Idealerweise würdest du aber immer einen neuen Branch anlegen und kannst> dann einfach "git diff master" machen um alle Änderungen in Bezug auf> den master Branch anzuzeigen.
Diese Denkweise ist etwas arg von github geprägt.
Das ist nicht notwendig und hängt sehr stark von deinem use-case ab.
Möchtest du einen github Pull-Request machen, dann muss man das so
machen (mit ein paar Ausnahmen). Möchte man den patch an irgendeine
Mailing-Liste schicken damit das aufgenommen wird, ist das nicht
notwendig. Kommt halt ganz stark darauf an, was man genau machen will.
super schrieb:> Möchte man den patch an irgendeine> Mailing-Liste schicken damit das aufgenommen wird, ist das nicht> notwendig.
Es ist aber dennoch praktisch wenn sich deren master mittlerweile
weiterbewegt hat. So kann man vorher noch seinen eigenen Branch wieder
auf den aktuellen master rebasen oder den Master in seinen Branch
reinmergen (denn man selbst kann seine eigenen Konflikte einfacher lösen
als andere) und DANN erst den Patch erzeugen.
Wenn man alle denkbaren Zustände von sich und die von anderen immer
sicher und wohlbehalten in separate Branches eingetütet hat so daß
nichts verrutschen kann lebt und merged es sich viel entspannter.
Branches kosten nichts und machen das Leben einfacher, also warum darauf
verzichten?
Rolf M. schrieb:> Ginge nicht auch einfach ein git diff origin/master?
Ja, das ginge natürlich auch. Hab den Teil mit dem geclonten Repository
überlesen.
>Möchtest du einen github Pull-Request machen ...
Ja, soweit bin ich zwischenzeitlich wobei das wohl als Nebenwirkung mit
sich bringt, daß ich mit der hübschen patch Datei gar nix anfangen kann
weil das auf Github dann sowieso automatisch geht.
Also, ich habe einen Fork auf den eigenen Usernamen in Github angelegt
und diesen zur Durchführung der Änderungen auf die lokale Platte
gecloned. Diese möchte ich am Master Branch machen denn an älteren
weitergepflegten Versionen macht das keinen Sinn. Ich bin mir jetzt
nicht sicher, warum ich auf dem eigenen Fork zur Änderung einen neuen
Branch aufmachen soll. Vereinfacht das dem Projekteigentümer beim
späteren Pull Request den Merge wenn jemand Anderes gleichzeitig
ebenfalls etwas ändern will ?
Janvi schrieb:> warum ich auf dem eigenen Fork zur Änderung einen neuen> Branch aufmachen soll
Nicht unbedingt. Aber wenn die anderen zwischenzeitlich auf deren master
branch weiter arbeiten kannst Du Deinen master bei Dir ebenfalls
problemlos nachziehen ohne deine eigenen Änderungen im Weg stehen zu
haben.
Aber das ist eigentlich reine Geschmackssache und eine Frage dessen wie
Du das organisieren willst, ob Du zum Beispiel an mehreren verschiedenen
Änderungen arbeitest die Du unabhängig voneinander Pull-Requesten willst
oder ob es nur diese eine einmalige Sache ist, ebensogut kannst Du auch
Deinen Fork bereits als separaten Branch betrachten und damit genausogut
einen Pull-Request machen.
Wenn Du etwas länger mit git arbeitest wird das bald alles leichter von
der Hand gehen und das Jonglieren mit mehreren Branches so natürlich und
unkompliziert erscheinen wie mal eben einen neuen Ordner anlegen um mal
kurz was zwischenzuparken und nach ner halben Stunde wieder zu löschen.
Janvi schrieb:> Ich bin mir jetzt nicht sicher, warum ich auf dem eigenen Fork zur> Änderung einen neuen Branch aufmachen soll.
Auf GitHub werden bei einem pull request neue Kommits und sonstige
Änderungen im Branch, der gemerged werden soll, automatisch in den pull
request übernommen, solange der pull request noch offen ist. Das kann
unpraktisch werden, wenn man den master branch genommen hat.
Wie kann ich denn einen älteren Branch auf Github ansprechen ?
Mit dem Pulldown switch auf der Webseite wird die URL umgeschaltet,
aber
git clone https://github.com/user/projekt/tree/branch
meldet fatal: not found
während der master genommen wird wenn man tree/branch abschneidet.
Wenn ich das korrekt verstanden habe, sind alle branch in einem einzigen
Repository enthalten, aber git branch meldet nur
* master
Das ist bisschen verwirrend aber was du tust ist Unsinn.
Die branches mit dem remotes/-Präfix sind nicht auf deinem Rechner, die
sind nur auf den Remotes. Was du eigentlich willst, ist einen lokalen
Branch anlegen, der den entsprechenden remote-Branch trackt.
Das geht z.B. für remotes/origin/5.0 normalerweise mit
git branch 5.0
git remote --set-upstream-to remotes/origin/5.0
aber da das so umständlich ist, tut
git checkout 5.0
dasselbe, wenn der lokale Branch "5.0" nicht existiert.
Habe jetzt mit checkout 5.1 auf dem lokalen rep gearbeitet
und es funktioniert soweit alles.
Danach add. auf die Stage und commit, dann push und es kommt der Browser
und will die Zugangsdaten zu github wissen. Das Ergebniss sollte jetzt
auf meinem Branch sichbar sein was es aber nicht ist.
Wie funkioniert das jetzt noch bis zu einem Pull request damit es ins
eigentliche Projekt einfliesst ? Im github http werden upload und pull
request angeboten. Sollte ich diese nur für das geänderte File benutzen
?
