Patch Datei mit GIT erzeugen

git show HEAD

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.

Ginge nicht auch einfach ein git diff origin/master?

git format-patch HEAD^..HEAD

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?

Sven B. schrieb:
> git format-patch HEAD^..HEAD

Genau. Einspielen kann man einen (oder mehrere) so erzeugte Patches mit

git am file.patch

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.

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.

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

J. V. schrieb:
> aber git branch meldet nur
>
> * master

Was sagt "git branch -a"?

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

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 
?