Git HowTo: Unterschied zwischen den Versionen
Jochen (Diskussion | Beiträge) (Die Seite wurde neu angelegt: = Git Snippets = Hier entsteht eine Sammlung von git-Befehlen. Für Platzhalter in den Befehlen verwende ich hier "Anführungszeichen". Da diese Sammlung ...) |
(→Herunterladen der aktuellen Version in einen neuen Ordner: MeinOrdner) |
||
Zeile 9: | Zeile 9: | ||
== Herunterladen der aktuellen Version in einen neuen Ordner: MeinOrdner == | == Herunterladen der aktuellen Version in einen neuen Ordner: MeinOrdner == | ||
− | git clone git:// | + | git clone git://github.com/ethersex/ethersex.git "MeinOrdner" |
== Aktualisierung der Heruntergeladen Dateien == | == Aktualisierung der Heruntergeladen Dateien == |
Version vom 8. August 2009, 10:41 Uhr
Inhaltsverzeichnis
- 1 Git Snippets
- 1.1 Herunterladen der aktuellen Version in einen neuen Ordner: MeinOrdner
- 1.2 Aktualisierung der Heruntergeladen Dateien
- 1.3 'Status' der lokalen Dateien
- 1.4 'Log' ansehen
- 1.5 Änderungen an Heruntergeladenen Dateien 'committen'
- 1.6 Eigene Dateien 'adden'
- 1.7 Eigene Dateien 'commiten'
- 1.8 Änderungen an den Dateien als Textdatei exportieren
- 1.9 'Commits' ändern
- 1.10 Git mit dem 'server' syncronisieren
- 2 Git Beispiel
Git Snippets
Hier entsteht eine Sammlung von git-Befehlen.
Für Platzhalter in den Befehlen verwende ich hier "Anführungszeichen".
Da diese Sammlung in dieser Reihenfolge dazu führt, einen 'patch' zu extrahieren, kommen doppelte Einträge vor.
Herunterladen der aktuellen Version in einen neuen Ordner: MeinOrdner
git clone git://github.com/ethersex/ethersex.git "MeinOrdner"
Aktualisierung der Heruntergeladen Dateien
git pull origin
'Status' der lokalen Dateien
git status
'Log' ansehen
git log
Änderungen an Heruntergeladenen Dateien 'committen'
git commit "Herruntergeladenen Dateien"
Eigene Dateien 'adden'
git add "Eigene Dateien"
Eigene Dateien 'commiten'
git commit "Eigene Dateien"
Änderungen an den Dateien als Textdatei exportieren
git format-patch "commit id von vor der Eigenen Änderungen"
oder
git format-patch -1
'Commits' ändern
git rebase -i <COMMIT-ID-EINS-VORHER>
oder den letzten 'commit' mit
commit --amend
Git mit dem 'server' syncronisieren
git fetch git rebase origin master
Git Beispiel
Hier hat mir stesie das mal erklaert...
so, jetzt habe ich eine version des rf12_powerswitch fertig; habe ein paar aenderungen an vorhandenen dateien gemacht und ein paar neue dateien angelegt... wie mach ich das denn jetzt am schlauesten mit git? habs in ein frisch gepulltes verzeichniss eingebaut! erst ma ein git-add, oder lieber erst die aenderungen der vorhandenen dateien als patch extrahieren? > wenn die dateien nur mit dem powerswitch zu tun haben, dann alles in eines > sind fehler in rfm12 berichtigt, dann separat > neue funktionen in rfm12 imho auch separat > anders ausgedrueckt, wenn in zukunft jemand powerswitch los haben will und dann die aenderungen in der rfm12.c z.b. auch nicht mehr braucht, dann in eines > solltest halt immer vom gedanken eines versionskontrollsystems ausgehen, und der ist ja, dass man die entwicklung nachvollziehen bzw. zuruecknehmen koennen soll ne nix repariert oder in rfm12 hinzugefuegt, lediglich die defines fuer rfm12_prologue und epilouge in die rfm12.h verschoben > das wuerd ich separat comitten ok, also erstma git-comit rfm12/rfm12.* ? > jo git-commit rfm12/rfm12.* Created commit f26e3e9: moved rfm12_prologue and epilogue to rfm12.h 2 files changed, 8 insertions(+), 7 deletions(-) sieht gut aus, oder? > schon ok, jetzt den patch extrahieren? git-?? > patch extrahieren, was hast du vor? > committe doch erstmal noch den rest ah, wenn man das so seperat committet, reicht ein patch per mail? > etz committe erstmal und die commits bleiben so erhlaten... > dann machen wir weiter > genau > der exportiert dann pro committ eine .patch datei > also etz mit commit add die neuen adden > dann git commit ok, dann jetzt die aenderungen an den anderen vorhandenen dateien, oder erst adden? > und du willst dich ein bisl an den anderen commit messages orientieren, d.h. den subsystem-namen voran stellen, also z.b. ein "rfm12: moved rfm12_prolgue and rfm12_epilogue functions to rfm12.h" > wobei's in dem fall sogar noch relativ offensichtlich ist habe /rfm12/rf12_powerswtich.c/h und in ecmd/ noch was > im zweifel in git status gucken ;) > naja, dann git add rfm12/rf12_powerswitch.[ch] ah, da ist auch noch die config.in; habe ich in anlogie zu usb-config.in bennant: rf12-powerswitch-confi.in > das kannste imho auch in die existierende rfm12/config.in packen > git format-patch id... > und statt `id' die commit id ab dem du exportieren willst > siehe `git log' > also im stile git format-patch 4afce1e9178397db61f962a874c984df2ddfbb65.. > das schreibt dann n *.patch dateien ins aktuelle verzeichnis jo, nach dem adden, muss ich die dateien auch noch commiten? > ja > weil, git commit bla.c > ist nur eine abkuerzung fuer > git add bla.c > git commit > funktioniert aber nur mit bereits im repository existierenden dateien oki, dann sowas wie rf12_powerswitch: initial commit fuers adden und ausfuehrlicher beim commiten? > beim add fragt er doch keine nachricht ab > die fraegt er nur beim commit > und da halt sowas in dem stile, also irgendwie rf12_powerswitch: initial commit. RET RET rf12_powerswitch is a new application, that allows to ... und wenn ich dann alles geadded und committet habe kann ich mit git-diff gucken, ob ich alles drin habe? > nein > git diff zeigt dir NUR aenderungen an Dateien, die bereits im repository lagen > wenn du irgendwo neu eine datei hinzugefuegt hast, zeigt er das nicht an > du willst wirklich(--foorce) git status verwenden > und du kannst in .git/info/exclude dateien eintragen, die er dir gar nicht erst anzeigen soll > also in die .git/info/exclude halt sowas eintragen: > *.[oda] > *~ > .config > .config.old > .subdirs > ecmd_parser/ecmd_defs.c > pinning.c > config.mk > autoconf.h ah cool so jetzt kopiere ich mir erst einmal unsere unterhlatung, um es dann in nen wiki artikel einzubauen...
... nachdem die dateien per mail versand sind und ins git repository eingepflegt...
mh, mache mir wohl am besten einen branch dafuer, oder? damit ich auch mit euch syncron beleiben kann;-) > branch? > mach doch etz einfach ein > git fetch > git rebase origin master > ok > das sollte dann feststellen, dass deine aenderungen jetzt upstream integriert wurden > und das entsprechend nicht einspielen
Neue Branch für Änderungen die man gemacht hat erstellen (bevor man commited)
zuerst NICHT COMMITTEN
- Neue Branch erstellen git branch wip-ecmd-callback
- Zur Branch wechseln git checkout wip-ecmd-callback
- Jetzt seine commits druchführen git commit -a
- und so zum Server übertragen git push origin wip-ecmd-callback
wenn man fertig ist wirds so zu master übertragen
- git checkout master
- git merge wip-ecmd-callback
Links zu git
- http://excess.org/article/2008/07/ogre-git-tutorial/ - Vortrag ueber git mit vielen Tips
- http://git.or.cz/course/svn.html - Git How To für SVN-User