Git: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
Jewox (Diskussion | Beiträge) K Konfiguration |
||
(5 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
Git ist ein Versionskontrollsystem. Es ist freie Software unter GPL und war ursprünglich für den Linux-Kernel entwickelt worden. Inzwischen werden viele weitere bekannte Projekte, wie GNOME, Qt und X.org mit Git verwaltet. | {{righttoc}}Git ist ein Versionskontrollsystem. Es ist freie Software unter der GPL und war ursprünglich für den Linux-Kernel entwickelt worden. Inzwischen werden viele weitere bekannte Projekte, wie GNOME, Qt und X.org mit Git verwaltet. Siehe {{wikipedia|Git}} | ||
Des Weiteren kann man natürlich nicht nur Software-Projekte, sondern auch Artikel, Lied-Texte etc. mit Git verwalten, sprich versionieren, da das System intern mit ''diff'' arbeitet. | |||
{{installation|repo=extra|paket=git}} | |||
== Konfiguration == | |||
Als erste Konfiguration legt man Benutzername und E-Mail fest. | |||
$ git config --global user.name "John Doe" | |||
$ git config --global user.email john.doe@example.com | |||
Mittels dem Befehl | |||
$ git config --global --edit | |||
kann man weitere Einstellungen vornehmen. Der Editor, welcher von Git aufgerufen wird, wird entsprechend der Variable export EDITOR= verwendet. Siehe auch {{ic|$ printenv}} | |||
Der Befehl | |||
$ git config --global --list | |||
zeigt alle Einstellungen an. Es handelt sich dabei um die Datei {{ic|.gitconfig}}. | |||
Es wird seitens Git nochmals unterschieden: --global für den Benutzer, --system für das System und --local für das Repository. | |||
Sinnvoll ist es, die Datei {{ic|.gitignore_global}} anzulegen. | |||
$ touch .gitignore_global | |||
Die Datei {{ic|.gitconfig}} ist in Abschnitte unterteilt. Folgender Eintrag wird hinzugefügt: | |||
[core] | |||
excludesfile = /home/user/.gitignore_global | |||
Die Dateien {{ic|.gitignore_global}} und {{ic|.gitignore}} (pro Repository) enthalten Dateien bzw. Dateiendungen, welche nicht in ein Repository z.B. auf öffentlichen Servern hochgeladen werden sollen. | |||
== Ein Projekt erstellen == | == Ein Projekt erstellen == | ||
Zeile 20: | Zeile 41: | ||
Zuerst erstellt man einen Projektordner. | Zuerst erstellt man einen Projektordner. | ||
$ mkdir example/ | |||
$ cd example/ | |||
Nun initialisiert man Git. | Nun initialisiert man Git. | ||
$ git init | |||
Jetzt erstellt man die Ausgangsdateien des Projekts, z.B. mit 'touch'. | Jetzt erstellt man die Ausgangsdateien des Projekts, z.B. mit 'touch'. | ||
$ touch example.c | |||
$ touch README | |||
$ touch .gitignore | |||
Zuletzt fügt man diese dem Git-Projekt hinzu und erstellt | Zuletzt fügt man diese dem Git-Projekt hinzu und erstellt den ersten Commit. | ||
$ git add example.c README .gitignore | |||
$ git commit -m 'initial commit' | |||
== Ein einfacher Workflow == | == Ein einfacher Workflow == | ||
Zuerst erstellt man einen neuen Branch. Dies ist ein | Zuerst erstellt man einen neuen Branch. Dies ist ein separater Zweig des Projekts, in dem man die Veränderungen, die getätigt werden, zuerst testen kann, bevor sie in den Hauptzweig (üblicherweise 'master') einfließen. | ||
$ git branch experimental | |||
$ git checkout experimental | |||
Nun tätigt man seine Veränderungen, testet sie, erstellt einen Commit und fügt, wenn alles ausgereift ist, die neuen Dateien 'master' hinzu. | Nun tätigt man seine Veränderungen, testet sie, erstellt einen Commit und fügt, wenn alles ausgereift ist, die neuen Dateien 'master' hinzu. | ||
$ vim example.c | |||
$ git add example.c | |||
$ git commit -m '...' | |||
$ git checkout master | |||
$ git merge experimental | |||
== Zusammenarbeit == | == Zusammenarbeit == | ||
Zeile 57: | Zeile 78: | ||
Es wird davon ausgegangen, dass Alice an 'example' bisher alleine arbeitete und Bob nun zum Projekt hinzustößt. Deshalb wird zuerst das Repository geklont. | Es wird davon ausgegangen, dass Alice an 'example' bisher alleine arbeitete und Bob nun zum Projekt hinzustößt. Deshalb wird zuerst das Repository geklont. | ||
$ git clone /home/alice/example example | |||
Hierdurch wird im aktuellen Ordner der Ordner 'example' erstellt und alle Dateien aus dem Quellordner hinzugefügt. | Hierdurch wird im aktuellen Ordner der Ordner 'example' erstellt und alle Dateien aus dem Quellordner hinzugefügt. Nachdem alle Änderungen durchgeführt wurden, holt Alice sich diese, überprüft, ob alles ihren Vorstellungen entspricht und wenn ja, fügt diese zu ihrer Kopie hinzu. | ||
Nachdem alle Änderungen durchgeführt wurden, holt Alice sich diese, überprüft, ob alles ihren Vorstellungen entspricht und wenn ja, fügt diese zu ihrer Kopie hinzu. | |||
$ git fetch /home/bob/example | |||
$ git log -p HEAD..FETCH_HEAD | |||
$ git merge HEAD..FETCH_HEAD | |||
Mit der Option 'pull' anstatt von 'fetch', würde 'fetch' und 'merge' in einem Schritt durchgeführt werden, dabei kann es jedoch zu Konflikten kommen, die zuerst beseitigt werden müssen! | |||
Des Weiteren ist es möglich 'Shorthands' zu erstellen, um sich lange Pfadnamen zu sparen. | Des Weiteren ist es möglich 'Shorthands' zu erstellen, um sich lange Pfadnamen zu sparen. | ||
$ git remote add bob /home/bob/example | |||
Nun kann man mit 'bob' alle vorherigen Operationen durchführen. | Nun kann man mit 'bob' alle vorherigen Operationen durchführen. | ||
$ git fetch bob | |||
$ git log -p master..bob/master | |||
$ git merge bob/master | |||
Zuletzt ist es möglich mittels 'push' seine Änderungen in ein anderes Repository einzupflegen, sofern man die Berechtigungen hat. | Zuletzt ist es möglich mittels 'push' seine Änderungen in ein anderes Repository einzupflegen, sofern man die Berechtigungen hat. | ||
$ git push bob master | |||
Hiermit würde man in die aktuelle Branch von Bob seine eigenen Änderungen im eigenen 'master'-Branch einfügen, also als ob Bob 'pull' ausführt. Auch hier muss man auf Konflikte achten. | Hiermit würde man in die aktuelle Branch von Bob seine eigenen Änderungen im eigenen 'master'-Branch einfügen, also als ob Bob 'pull' ausführt. Auch hier muss man auf Konflikte achten. | ||
== Weblinks == | == Weblinks == | ||
Zeile 94: | Zeile 111: | ||
* [http://stefanimhoff.de/notiz/einstieg-in-git-als-versionskontrollsystem/ http://stefanimhoff.de/notiz/einstieg-in-git-als-versionskontrollsystem/] {{sprache|de}} | * [http://stefanimhoff.de/notiz/einstieg-in-git-als-versionskontrollsystem/ http://stefanimhoff.de/notiz/einstieg-in-git-als-versionskontrollsystem/] {{sprache|de}} | ||
[[Kategorie:Versionsverwaltung]] | |||
[[en:Git]] | |||
[[Kategorie: | |||
[[ |
Aktuelle Version vom 5. Juni 2019, 19:05 Uhr
Git ist ein Versionskontrollsystem. Es ist freie Software unter der GPL und war ursprünglich für den Linux-Kernel entwickelt worden. Inzwischen werden viele weitere bekannte Projekte, wie GNOME, Qt und X.org mit Git verwaltet. Siehe Git
Des Weiteren kann man natürlich nicht nur Software-Projekte, sondern auch Artikel, Lied-Texte etc. mit Git verwalten, sprich versionieren, da das System intern mit diff arbeitet.
Installation
Das Programm ist als
git
in extra
verfügbar, und kann von dort
mittels Pacman
installiert werden.
Konfiguration
Als erste Konfiguration legt man Benutzername und E-Mail fest.
$ git config --global user.name "John Doe" $ git config --global user.email john.doe@example.com
Mittels dem Befehl
$ git config --global --edit
kann man weitere Einstellungen vornehmen. Der Editor, welcher von Git aufgerufen wird, wird entsprechend der Variable export EDITOR= verwendet. Siehe auch $ printenv
Der Befehl
$ git config --global --list
zeigt alle Einstellungen an. Es handelt sich dabei um die Datei .gitconfig
.
Es wird seitens Git nochmals unterschieden: --global für den Benutzer, --system für das System und --local für das Repository.
Sinnvoll ist es, die Datei .gitignore_global
anzulegen.
$ touch .gitignore_global
Die Datei .gitconfig
ist in Abschnitte unterteilt. Folgender Eintrag wird hinzugefügt:
[core] excludesfile = /home/user/.gitignore_global
Die Dateien .gitignore_global
und .gitignore
(pro Repository) enthalten Dateien bzw. Dateiendungen, welche nicht in ein Repository z.B. auf öffentlichen Servern hochgeladen werden sollen.
Ein Projekt erstellen
Zuerst erstellt man einen Projektordner.
$ mkdir example/ $ cd example/
Nun initialisiert man Git.
$ git init
Jetzt erstellt man die Ausgangsdateien des Projekts, z.B. mit 'touch'.
$ touch example.c $ touch README $ touch .gitignore
Zuletzt fügt man diese dem Git-Projekt hinzu und erstellt den ersten Commit.
$ git add example.c README .gitignore $ git commit -m 'initial commit'
Ein einfacher Workflow
Zuerst erstellt man einen neuen Branch. Dies ist ein separater Zweig des Projekts, in dem man die Veränderungen, die getätigt werden, zuerst testen kann, bevor sie in den Hauptzweig (üblicherweise 'master') einfließen.
$ git branch experimental $ git checkout experimental
Nun tätigt man seine Veränderungen, testet sie, erstellt einen Commit und fügt, wenn alles ausgereift ist, die neuen Dateien 'master' hinzu.
$ vim example.c $ git add example.c $ git commit -m '...' $ git checkout master $ git merge experimental
Zusammenarbeit
Es wird davon ausgegangen, dass Alice an 'example' bisher alleine arbeitete und Bob nun zum Projekt hinzustößt. Deshalb wird zuerst das Repository geklont.
$ git clone /home/alice/example example
Hierdurch wird im aktuellen Ordner der Ordner 'example' erstellt und alle Dateien aus dem Quellordner hinzugefügt. Nachdem alle Änderungen durchgeführt wurden, holt Alice sich diese, überprüft, ob alles ihren Vorstellungen entspricht und wenn ja, fügt diese zu ihrer Kopie hinzu.
$ git fetch /home/bob/example $ git log -p HEAD..FETCH_HEAD $ git merge HEAD..FETCH_HEAD
Mit der Option 'pull' anstatt von 'fetch', würde 'fetch' und 'merge' in einem Schritt durchgeführt werden, dabei kann es jedoch zu Konflikten kommen, die zuerst beseitigt werden müssen!
Des Weiteren ist es möglich 'Shorthands' zu erstellen, um sich lange Pfadnamen zu sparen.
$ git remote add bob /home/bob/example
Nun kann man mit 'bob' alle vorherigen Operationen durchführen.
$ git fetch bob $ git log -p master..bob/master $ git merge bob/master
Zuletzt ist es möglich mittels 'push' seine Änderungen in ein anderes Repository einzupflegen, sofern man die Berechtigungen hat.
$ git push bob master
Hiermit würde man in die aktuelle Branch von Bob seine eigenen Änderungen im eigenen 'master'-Branch einfügen, also als ob Bob 'pull' ausführt. Auch hier muss man auf Konflikte achten.