| Zeile 19: | Zeile 19: | ||
=== Archiv herunterladen (clone) === | === Archiv herunterladen (clone) === | ||
| − | Um mit der Entwicklung zu beginnen, muss man zunächst natürlich seine eigene Kopie des Repositorys haben. Diese bekommt man mit dem <tt>clone</tt>-Befehl. Der Befehl ist das git-Äquivalent zum Subversion-Befehl <tt>checkout</tt>. | + | Um mit der Entwicklung zu beginnen, muss man zunächst natürlich seine eigene Kopie des Repositorys haben. Diese bekommt man mit dem <tt>clone</tt>-Befehl. Der Befehl ist das git-Äquivalent zum Subversion-Befehl <tt>checkout</tt>. (Achtung: Dieser Befehl existiert zwar auch in git, hat aber eine andere Aufgabe) |
Da die gesamte Versionsgeschichte des Projektes heruntergeladen wird, kann dieser Befehl je nach Verbindungsgeschwindigkeit sehr lange dauern. | Da die gesamte Versionsgeschichte des Projektes heruntergeladen wird, kann dieser Befehl je nach Verbindungsgeschwindigkeit sehr lange dauern. | ||
| Zeile 29: | Zeile 29: | ||
=== Archiv aktualisieren (pull) === | === Archiv aktualisieren (pull) === | ||
| − | Der Befehl <tt>pull</tt> berechnet die Änderungen zwischen dem eigenen Archiv und dem Remote-Archiv und fordert die Änderungen vom Server an. <tt>pull</tt> bezieht die Änderungen standardmäßig von dem origin-Archiv, das ist normalerweise das Archiv von dem ursprünglich geclonet wurde. | + | Der Befehl <tt>pull</tt> berechnet die Änderungen zwischen dem eigenen Archiv und dem Remote-Archiv und fordert die Änderungen vom Server an. <tt>pull</tt> bezieht die Änderungen standardmäßig von dem origin-Archiv, das ist normalerweise das Archiv von dem ursprünglich geclonet wurde. Unter Subversion funktioniert der <tt>update</tt>-Befehl ähnlich. |
Wenn eigene commits vorliegen, die nicht auf dem Server ist (wie es bei git eigentlich typisch ist), dann kann <tt>pull</tt> angewiesen werden, versuchen, die Änderungen in den eigenen Tree zu übernehmen, sodass nachher sowohl die lokalen, als auch die remote-commits vorliegen. Dies geht mit dem <tt>--rebase</tt>-Parameter. | Wenn eigene commits vorliegen, die nicht auf dem Server ist (wie es bei git eigentlich typisch ist), dann kann <tt>pull</tt> angewiesen werden, versuchen, die Änderungen in den eigenen Tree zu übernehmen, sodass nachher sowohl die lokalen, als auch die remote-commits vorliegen. Dies geht mit dem <tt>--rebase</tt>-Parameter. | ||
| Zeile 46: | Zeile 46: | ||
Sobald man alle Dateien hinzugefügt hat, ruft man <tt>git commit</tt> auf. Es öffnet sich ein Editor, in dem man die commit-Nachricht eingibt. Man kann jedoch auch mit dem Parameter <tt>-m</tt> direkt eine Nachricht angeben. | Sobald man alle Dateien hinzugefügt hat, ruft man <tt>git commit</tt> auf. Es öffnet sich ein Editor, in dem man die commit-Nachricht eingibt. Man kann jedoch auch mit dem Parameter <tt>-m</tt> direkt eine Nachricht angeben. | ||
| + | |||
| + | Im Gegensatz zu den gleichbenannten Subversion-Befehlen laufen beide Befehle bei git nur lokal ab. | ||
Beispiel: | Beispiel: | ||
| Zeile 62: | Zeile 64: | ||
Zum erfolgreichen push muss der tree jedoch ein wenig mit dem auf dem Hauptserver abgestimmt sein. Vorher ist also ein <tt>git pull --rebase</tt> zu empfehlen, um Konflikte zu vermeiden. | Zum erfolgreichen push muss der tree jedoch ein wenig mit dem auf dem Hauptserver abgestimmt sein. Vorher ist also ein <tt>git pull --rebase</tt> zu empfehlen, um Konflikte zu vermeiden. | ||
| + | |||
| + | Da bei Subversion alle Commits direkt auf den Server kommen, gibt es hier keinen vergleichbaren Befehl. Der SVN-Befehl <tt>commit</tt> vereint sozusagen die Funktionalität von Gits <tt>commit</tt> und <tt>push</tt> | ||
Beispiel: | Beispiel: | ||
| Zeile 71: | Zeile 75: | ||
git push | git push | ||
</pre> | </pre> | ||
| + | |||
| + | === Ausblick === | ||
| + | Oben werden nur sehr grundlegende Befehle genannt, die nur ein sehr begrenztes Arbeiten ermöglichen. Hier werden auch solche genannt, die oben aus Platzgründen nicht erwähnt werden, aber trotzdem sehr wichtig sind. Dieser Absatz soll ein Anreiz sein, die Befehle in der Git-Dokumentation oder mit Hilfe von <tt>man</tt> nachzuschlagen. Bei <tt>man</tt> findet man diese Befehle unter dem Namen <tt>git-<BEFEHL></tt>. | ||
| + | |||
| + | Um erstmal ein eigenes Archiv anzulegen, sollte man den Befehl <tt>init</tt> kennen. Außerdem wird man sicherlich oft die Git-Befehle <tt>diff</tt>, <tt>log</tt> und <tt>status</tt> brauchen. Um Fehler in der History zu korrigieren muss man sicher auch einmal die Befehle <tt>reset</tt> oder <tt>revert</tt> anwenden. | ||
| + | |||
| + | Sehr wichtig sind die Branching-Mechanismen. Mit den oben genannten Befehlen wäre es nur möglich auf einem Branch zu arbeiten. Davon ist grundsätzlich abzuraten; viele Projekte verbieten sogar das Arbeiten im Hauptzweig (''master''). Wichtige Branching-Befehle sind <tt>branch</tt>, <tt>merge</tt>, <tt>rebase</tt> und <tt>checkout</tt>. | ||
| + | |||
| + | Äußerst wichtig für das Aktualisieren des Trees während der täglichen Arbeit ist <tt>stash</tt>, das es ermöglicht, die Änderungen an seiner Arbeitskopie zwischenzuspeichern und einen saubere Arbeitskopie zum <tt>pull</tt>en zu bekommen. | ||
| + | |||
| + | Aber auch die bereits oben erklärten Befehle sollte man in der Dokumentation nachschauen, da alle noch interessante Parameter haben, die sicherlich zur Anwendung kommen. | ||
== Vergleich zu Subversion == | == Vergleich zu Subversion == | ||