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 ?
ah, super - wär ich auch nie selbt draufgekommen. Es scheint in git mindestens soviel unendliche Tiefen wie in make zu geben.
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?
:
Bearbeitet durch User
Sven B. schrieb: > git format-patch HEAD^..HEAD Genau. Einspielen kann man einen (oder mehrere) so erzeugte Patches mit git am file.patch
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
C:\data\kcdev\kcd-i18n>git branch -a * master remotes/origin/4.0 remotes/origin/5.0 remotes/origin/5.1 remotes/origin/HEAD -> origin/master remotes/origin/master C:\data\kcdev\kcd-i18n>git branch remotes/origin/5.1 C:\data\kcdev\kcd-i18n>git branch * master remotes/origin/5.1 C:\data\kcdev\kcd-i18n>git checkout remotes/origin/5.1 warning: refname 'remotes/origin/5.1' is ambiguous. Switched to branch 'remotes/origin/5.1' C:\data\kcdev\kcd-i18n>git checkout 5.1 Switched to a new branch '5.1' Branch '5.1' set up to track remote branch '5.1' from 'origin'. C:\data\kcdev\kcd-i18n>git branch 5.1_bug463 C:\data\kcdv\kcd-i18n>git branch -a * 5.1 5.1_bug463 master remotes/origin/5.1 remotes/origin/4.0 remotes/origin/5.0 remotes/origin/5.1 remotes/origin/HEAD -> origin/master remotes/origin/master C:\data\kcdev\kcd-i18n>git checkout 5.1_bug463 Switched to branch '5.1_bug463' C:\data\kcdev\kcd-i18n>git branch -a 5.1 * 5.1_bug463 master remotes/origin/5.1 remotes/origin/4.0 remotes/origin/5.0 remotes/origin/5.1 remotes/origin/HEAD -> origin/master remotes/origin/master
:
Bearbeitet durch User
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 ?
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.