Git HowTo

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

Jedoch ist das verwenden von github um einiges einfacher zu handeln, als Patches umherzusenden.

'Commits' ändern

    git rebase -i <COMMIT-ID-EINS-VORHER>

oder den letzten 'commit' mit

    git 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

1. Neue Branch erstellen git branch wip-ecmd-callback
2. Zur Branch wechseln git checkout wip-ecmd-callback
3. Jetzt seine commits druchführen git commit -a
4. und so zum Server übertragen git push origin wip-ecmd-callback

wenn man fertig ist wirds so zu master übertragen

1. git checkout master
2. 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