English ▾ Themen ▾ Neueste Version ▾ giteveryday zuletzt aktualisiert in 2.43.0

NAME

giteveryday - Ein nützlicher Mindestsatz an Befehlen für Everyday Git

SYNOPSIS

Everyday Git mit etwa 20 Befehlen

BESCHREIBUNG

Git-Benutzer können für die Zwecke der Beschreibung eines kleinen Satzes nützlicher Befehle für das tägliche Git hier grob in vier Kategorien eingeteilt werden.

Individueller Entwickler (Standalone)

Ein eigenständiger individueller Entwickler tauscht keine Patches mit anderen aus, arbeitet alleine in einem einzigen Repository und verwendet die folgenden Befehle.

Beispiele

Verwenden Sie ein Tarball als Startpunkt für ein neues Repository.
$ tar zxf frotz.tar.gz
$ cd frotz
$ git init
$ git add . (1)
$ git commit -m "import of frotz source tree."
$ git tag v2.43 (2)

  1. fügt alles unter dem aktuellen Verzeichnis hinzu.

  2. erstellt ein leichtgewichtigen, unkommentierten Tag.

Erstellen Sie einen Topic-Branch und entwickeln Sie.
$ git switch -c alsa-audio (1)
$ edit/compile/test
$ git restore curses/ux_audio_oss.c (2)
$ git add curses/ux_audio_alsa.c (3)
$ edit/compile/test
$ git diff HEAD (4)
$ git commit -a -s (5)
$ edit/compile/test
$ git diff HEAD^ (6)
$ git commit -a --amend (7)
$ git switch master (8)
$ git merge alsa-audio (9)
$ git log --since='3 days ago' (10)
$ git log v2.43.. curses/ (11)

  1. erstellt einen neuen Topic-Branch.

  2. macht Ihre fehlerhaften Änderungen in curses/ux_audio_oss.c rückgängig.

  3. Sie müssen Git mitteilen, wenn Sie eine neue Datei hinzugefügt haben; Entfernung und Änderung werden erfasst, wenn Sie später git commit -a ausführen.

  4. um zu sehen, welche Änderungen Sie committen.

  5. committet alles, was Sie getestet haben, mit Ihrer Unterschrift.

  6. schaut sich alle Ihre Änderungen an, einschließlich des vorherigen Commits.

  7. ändert den vorherigen Commit, fügt alle Ihre neuen Änderungen hinzu und verwendet Ihre ursprüngliche Nachricht.

  8. wechselt zum Master-Branch.

  9. führt einen Topic-Branch in Ihren Master-Branch zusammen.

  10. Überprüfen Sie Commit-Logs; andere Formen zur Begrenzung der Ausgabe können kombiniert werden und umfassen -10 (um bis zu 10 Commits anzuzeigen), --until=2005-12-10 usw.

  11. zeigt nur die Änderungen an, die das Verzeichnis curses/ seit dem Tag v2.43 betreffen.

Individueller Entwickler (Teilnehmer)

Ein Entwickler, der als Teilnehmer an einem Gruppenprojekt arbeitet, muss lernen, wie man mit anderen kommuniziert, und verwendet diese Befehle zusätzlich zu denjenigen, die ein eigenständiger Entwickler benötigt.

  • git-clone[1] vom Upstream, um Ihr lokales Repository zu initialisieren.

  • git-pull[1] und git-fetch[1] von "origin", um mit dem Upstream auf dem Laufenden zu bleiben.

  • git-push[1] zum gemeinsamen Repository, wenn Sie einen CVS-ähnlichen Workflow für gemeinsame Repositories anwenden.

  • git-format-patch[1] zur Vorbereitung von E-Mail-Einreichungen, wenn Sie den Workflow des öffentlichen Forums im Linux-Kernel-Stil anwenden.

  • git-send-email[1] zum Senden Ihrer E-Mail-Einreichungen ohne Beschädigung durch Ihren MUA.

  • git-request-pull[1] zum Erstellen einer Zusammenfassung von Änderungen, die Ihr Upstream abrufen kann.

Beispiele

Klonen Sie das Upstream und arbeiten Sie daran. Übertragen Sie Änderungen an das Upstream.
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git switch -c mine master (1)
$ edit/compile/test; git commit -a -s (2)
$ git format-patch master (3)
$ git send-email --to="person <email@example.com>" 00*.patch (4)
$ git switch master (5)
$ git pull (6)
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)
$ git reset --hard ORIG_HEAD (10)
$ git gc (11)

  1. checked einen neuen Branch mine von master aus.

  2. wiederholen Sie dies nach Bedarf.

  3. extrahieren Sie Patches aus Ihrem Branch, relativ zu master,

  4. und senden Sie sie per E-Mail.

  5. kehren Sie zu master zurück, bereit, um zu sehen, was es Neues gibt.

  6. git pull holt standardmäßig von origin und führt in den aktuellen Branch zusammen.

  7. Unmittelbar nach dem Pull die Änderungen anzeigen, die seit dem letzten Mal im Upstream vorgenommen wurden, nur in dem Bereich, der uns interessiert.

  8. Überprüfen Sie die Branch-Namen in einem externen Repository (falls nicht bekannt).

  9. holt von einem bestimmten Branch ALL aus einem bestimmten Repository und führt ihn zusammen.

  10. macht den Pull rückgängig.

  11. bereinigt nicht verwendete Objekte aus einem rückgängig gemachten Pull.

In ein anderes Repository pushen.
satellite$ git clone mothership:frotz frotz (1)
satellite$ cd frotz
satellite$ git config --get-regexp '^(remote|branch)\.' (2)
remote.origin.url mothership:frotz
remote.origin.fetch refs/heads/*:refs/remotes/origin/*
branch.master.remote origin
branch.master.merge refs/heads/master
satellite$ git config remote.origin.push \
	   +refs/heads/*:refs/remotes/satellite/* (3)
satellite$ edit/compile/test/commit
satellite$ git push origin (4)

mothership$ cd frotz
mothership$ git switch master
mothership$ git merge satellite/master (5)

  1. Die Mutterschiff-Maschine hat ein Frotz-Repository unter Ihrem Home-Verzeichnis; klonen Sie es, um ein Repository auf der Satellitenmaschine zu starten.

  2. clone setzt diese Konfigurationsvariablen standardmäßig. Es arrangiert git pull so, dass die Branches der Mutterschiff-Maschine abgerufen und in lokalen Remote-Tracking-Branches remotes/origin/* gespeichert werden.

  3. arrangiert git push so, dass alle lokalen Branches in ihren entsprechenden Branch der Mutterschiff-Maschine gepusht werden.

  4. push sichert all unsere Arbeit auf den Remote-Tracking-Branches remotes/satellite/* auf der Mutterschiff-Maschine. Sie könnten dies als Backup-Methode verwenden. Ebenso können Sie so tun, als ob die Mutterschiff-Maschine von Ihnen "geholt" hätte (nützlich, wenn der Zugriff einseitig ist).

  5. Auf der Mutterschiff-Maschine die auf der Satellitenmaschine geleistete Arbeit in den Master-Branch integrieren.

Branch von einem bestimmten Tag abzweigen.
$ git switch -c private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git cherry-pick v2.6.14..private2.6.14 (2)

  1. Erstellt einen privaten Branch, der auf einem gut bekannten (aber etwas veralteten) Tag basiert.

  2. Portiert alle Änderungen im Branch private2.6.14 in den Branch master ohne ein formelles "Merging". Oder Langform
    git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

Ein alternativer Einreichungsmechanismus für Teilnehmer ist die Verwendung von git request-pull oder Pull-Request-Mechanismen (z. B. wie auf GitHub (www.github.com) verwendet, um Ihr Upstream über Ihren Beitrag zu informieren.

Integrator

Eine ziemlich zentrale Person, die als Integrator in einem Gruppenprojekt fungiert, empfängt von anderen gemachte Änderungen, überprüft und integriert sie und veröffentlicht das Ergebnis für andere zur Nutzung. Sie verwendet diese Befehle zusätzlich zu denen, die Teilnehmer benötigen.

Dieser Abschnitt kann auch von denen verwendet werden, die auf git request-pull oder Pull-Requests auf GitHub (www.github.com) reagieren, um die Arbeit anderer in ihre Historie zu integrieren. Ein untergeordneter Leutnant für ein Repository agiert sowohl als Teilnehmer als auch als Integrator.

  • git-am[1] zum Anwenden von Patches, die per E-Mail von Ihren Mitwirkenden gesendet wurden.

  • git-pull[1] zum Zusammenführen von Ihren vertrauenswürdigen Leutnants.

  • git-format-patch[1] zur Vorbereitung und zum Senden von vorgeschlagenen Alternativen an Mitwirkende.

  • git-revert[1] zum Rückgängigmachen von fehlerhaften Commits.

  • git-push[1] zur Veröffentlichung der neuesten Änderungen.

Beispiele

Ein typischer Git-Tag eines Integrators.
$ git status (1)
$ git branch --no-merged master (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git switch -c topic/one master
$ git am -3 -i -s ./+to-apply (4)
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
$ git switch topic/one && git rebase master (6)
$ git switch -C seen next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git switch maint
$ git cherry-pick master~4 (9)
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)
$ git fetch ko && for branch in master maint next seen (11)
    do
	git show-branch ko/$branch $branch (12)
    done
$ git push --follow-tags ko (13)

  1. Sehen Sie, was Sie gerade tun, falls etwas.

  2. Sehen Sie, welche Branches noch nicht in master integriert wurden. Dasselbe gilt für alle anderen Integrations-Branches, z. B. maint, next und seen.

  3. E-Mails lesen, anwendbare speichern und andere speichern, die noch nicht ganz fertig sind (andere E-Mail-Reader sind verfügbar).

  4. wenden Sie sie interaktiv mit Ihren Unterschriften an.

  5. erstellen Sie Topic-Branches nach Bedarf und wenden Sie sie an, wiederum mit Unterschriften.

  6. rebasiert interne Topic-Branches, die noch nicht in den Master integriert oder als Teil eines stabilen Branches veröffentlicht wurden.

  7. Starten Sie seen jedes Mal neu vom nächsten.

  8. und bündelt Topic-Branches, die noch in Bearbeitung sind.

  9. Backportiert einen kritischen Fix.

  10. erstellt einen signierten Tag.

  11. Stellen Sie sicher, dass master nicht versehentlich über das bereits veröffentlichte hinaus zurückgespult wurde.

  12. In der Ausgabe von git show-branch sollte master alles haben, was ko/master hat, und next sollte alles haben, was ko/next hat, usw.

  13. Pusht die neuesten Änderungen, zusammen mit neuen Tags, die auf die gepushte Historie zeigen.

In diesem Beispiel verweist die Abkürzung ko auf das Repository des Git-Maintainers unter kernel.org und sieht wie folgt aus:

(in .git/config)
[remote "ko"]
	url = kernel.org:/pub/scm/git/git.git
	fetch = refs/heads/*:refs/remotes/ko/*
	push = refs/heads/master
	push = refs/heads/next
	push = +refs/heads/seen
	push = refs/heads/maint

Repository-Administration

Ein Repository-Administrator verwendet die folgenden Werkzeuge, um den Zugriff auf das Repository für Entwickler einzurichten und aufrechtzuerhalten.

  • git-daemon[1] zum Zulassen anonymer Downloads aus dem Repository.

  • git-shell[1] kann als *beschränkte Login-Shell* für Benutzer zentraler gemeinsamer Repositories verwendet werden.

  • git-http-backend[1] bietet eine serverseitige Implementierung von Git-über-HTTP ("Smart HTTP"), die sowohl Fetch- als auch Push-Dienste ermöglicht.

  • gitweb[1] bietet eine Web-Oberfläche für Git-Repositories, die mit dem Skript git-instaweb[1] eingerichtet werden kann.

update hook howto enthält ein gutes Beispiel für die Verwaltung eines zentralen gemeinsamen Repositorys.

Darüber hinaus gibt es eine Reihe weiterer weit verbreiteter Hosting-, Browser- und Review-Lösungen wie

  • gitolite, gerrit code review, cgit und andere.

Beispiele

Wir gehen davon aus, dass im Folgenden in /etc/services
$ grep 9418 /etc/services
git		9418/tcp		# Git Version Control System
Führen Sie git-daemon aus, um /pub/scm von inetd zu bedienen.
$ grep git /etc/inetd.conf
git	stream	tcp	nowait	nobody \
  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

Die tatsächliche Konfigurationszeile sollte auf einer Zeile stehen.

Führen Sie git-daemon aus, um /pub/scm von xinetd zu bedienen.
$ cat /etc/xinetd.d/git-daemon
# default: off
# description: The Git server offers access to Git repositories
service git
{
	disable = no
	type            = UNLISTED
	port            = 9418
	socket_type     = stream
	wait            = no
	user            = nobody
	server          = /usr/bin/git-daemon
	server_args     = --inetd --export-all --base-path=/pub/scm
	log_on_failure  += USERID
}

Überprüfen Sie Ihre xinetd(8) Dokumentation und Einrichtung, dies ist von einem Fedora-System. Andere können abweichen.

Geben Sie Entwicklern, die git-over-ssh verwenden, nur Push-/Pull-Zugriff.

z. B. diejenigen, die verwenden: $ git push/pull ssh://host.xz/pub/scm/project

$ grep git /etc/passwd (1)
alice:x:1000:1000::/home/alice:/usr/bin/git-shell
bob:x:1001:1001::/home/bob:/usr/bin/git-shell
cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
david:x:1003:1003::/home/david:/usr/bin/git-shell
$ grep git /etc/shells (2)
/usr/bin/git-shell

  1. Die Login-Shell ist auf /usr/bin/git-shell gesetzt, was nichts anderes als git push und git pull erlaubt. Die Benutzer benötigen SSH-Zugriff auf die Maschine.

  2. In vielen Distributionen muss /etc/shells auflisten, was als Login-Shell verwendet wird.

CVS-ähnliches gemeinsames Repository.
$ grep git /etc/group (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/devo.git
$ ls -l (2)
  lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
  -rw-rw-r--   1 david git    84 Dec  4 22:40 config
  -rw-rw-r--   1 david git    58 Dec  4 22:40 description
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
  -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
  drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
  drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
  drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
$ ls -l hooks/update (3)
  -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
$ cat info/allowed-users (4)
refs/heads/master	alice\|cindy
refs/heads/doc-update	bob
refs/tags/v[0-9]*	david

  1. Fügen Sie die Entwickler in dieselbe Git-Gruppe ein.

  2. und machen Sie das gemeinsame Repository für die Gruppe beschreibbar.

  3. Verwenden Sie das update-hook-Beispiel von Carl aus Documentation/howto/ für die Branch-Richtlinienkontrolle.

  4. alice und cindy können in master pushen, nur bob kann in doc-update pushen. david ist der Release-Manager und die einzige Person, die Version-Tags erstellen und pushen kann.

GIT

Teil der git[1] Suite