Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
developer:github [2015/01/21 10:38] hofer [Alternative zu merge commit: git rebase] |
developer:github [2019/08/13 13:48] |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== GitHub ====== | ||
- | ===== Wichtige Commands ===== | ||
- | |||
- | <code> | ||
- | svn checkout: git clone linkZuRepo | ||
- | svn commit: git commit (-a) | ||
- | svn up: git pull (zuerst alles commiten!) | ||
- | svn switch: git checkout (-b) nameDesBranches | ||
- | svn status: git status (-s) | ||
- | svn info: git show | ||
- | </code> | ||
- | |||
- | ===== Aller Anfang ===== | ||
- | |||
- | Damit man nicht immer user/pass eingeben muss, kann man [[https://help.github.com/articles/generating-ssh-keys/|bei github einen public key eintragen]] und [[https://help.github.com/articles/about-two-factor-authentication/|2 factor auth zu aktivieren]] schadet auch nicht :-) | ||
- | |||
- | Damit commits als github User aufscheinen muss man die Mailadresse ([[https://help.github.com/articles/adding-an-email-address-to-your-github-account/|die auch github wissen muss]]) so lokal konfigurieren: <code>git config --global user.email "XYZ@technikum-wien.at"</code> | ||
- | |||
- | ===== git commit (-a) ===== | ||
- | |||
- | Um etwas zu commiten muss es zum "git index" geaddet werden (''git add''). Diese Dateien in der aktuellen Version sind dann im index ("staged for commit"). Ändert man noch etwas bei einer dieser Dateien muss man sie **nochmal** adden. | ||
- | |||
- | ''git commit'' commited alle Änderungen die im index ("staged") sind. | ||
- | |||
- | ''-a'' erspart das adden. Es staged und commited alle Dateien die schon mal im repository vorhanden waren. | ||
- | |||
- | ===== git pull ===== | ||
- | |||
- | Holt sich die Änderungen (''git fetch'') von den remotes (github) und merged (''git merge'') es ins lokale repository in den aktuellen branch. D.h. wenn es Änderungen gibt, ist ''git pull'' auch automatisch gleich ein commit. | ||
- | |||
- | Damit man mit den lokalen Änderungen nicht durcheinander, kommt sollte vorher alles lokale **commited** werden. | ||
- | |||
- | ===== Alternative zu merge commit: git rebase ===== | ||
- | |||
- | [[http://matthew-brett.github.io/pydagogue/rebase_without_tears.html|Rebase without tears]] | ||
- | |||
- | Hintergrund: Man arbeitet lokal an einem Fix/Feature, hat bereits eine history (ein paar commits) und benötigt jetzt eine Änderung die irgendjemand gepusht hat. rebasing erzeugt eine sauberere history als ständige merge commits. | ||
- | |||
- | Hab es gerade so ausprobiert und geschafft \o/: | ||
- | |||
- | Wechsel auf den Branch. Hol die letzten Änderungen von github vom Branch "master" und rebase deine Änderungen darauf. | ||
- | |||
- | <code> | ||
- | # Zuerst master updaten | ||
- | git checkout master | ||
- | git pull | ||
- | |||
- | # Jetzt den branch rebasen | ||
- | git checkout mein-feature-branch | ||
- | git rebase master | ||
- | </code> | ||
- | |||
- | Merge (Fast Forward) die Änderungen vom Branch. Push. | ||
- | |||
- | <code> | ||
- | git checkout master | ||
- | git merge mein-feature-branch | ||
- | git push | ||
- | </code> | ||
- | |||
- | In diesem Fall wird die gesamte history (alle commits) vom branch in den master mitgenommen. Wenn das nicht gewollt ist, kann man dem merge-Befehl noch den Parameter ''--squash'' mitgeben. Muss dann aber noch extra commiten. Git befüllt in diesem Fall die commit message bereits mit allen möglichen Infos. | ||
- | |||
- | <code> | ||
- | git checkout master | ||
- | git merge --squash mein-feature-branch | ||
- | git commit -a | ||
- | git push | ||
- | </code> | ||
- | ===== git checkout (-b) nameDesBranches ===== | ||
- | |||
- | ''git checkout nameDesBranches'' wechselt auf einen bestehenden branch mit Namen "nameDesBranches". | ||
- | |||
- | Wenn man einen neuen branch anfangen will kann man ihn mit ''-b'' erstellen und direkt hin switchen. | ||
- | |||
- | ===== git status (-s) ===== | ||
- | |||
- | Ist sehr detailliert. ''-s'' kürzt es ab. | ||
- | |||
- | ===== git tag -a nameDesTags ===== | ||
- | |||
- | Markiert eine bestimmte Version/Revision. Hilfreich zB wenn man festhalten will welche Version aktuell auf Produktion ist. Ermöglicht dann auch einen einfachen Rollback bei Fehlern zu vorigen Versionen. | ||
- | ===== Andere interessante Befehle ===== | ||
- | |||
- | <code>git reset: zB git reset HEAD index.php | ||
- | git mv config.server1.php config.server2.php | ||
- | git rm index.php</code> | ||
- | |||
- | |||
- | ===== Workflow ===== | ||
- | |||
- | Um in einem Projekt zu arbeiten ist der normale Workflow: klonen, branch erstellen (passiert nur lokal), developen/commiten bis es passt, in den master mergen, master pushen | ||
- | |||
- | Die Grafiken in der [[http://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging|git doku]] sagen mehr als 1000 Worte. Und [[https://guides.github.com/introduction/flow/index.html|der Guide]] schaut auch übersichtlich aus. |