Logo von Developer

Suche
preisvergleich_weiss

Recherche in 2.273.563 Produkten

Andreas Krüger 117

Arbeiten mit einem temporären Kollaborations-Repository

Im normalen Entwickleralltag nutzt man die Standardmöglichkeiten von Git. Aber gelegentlich können selten genutzte Fähigkeiten das Leben angenehmer machen – wenn man sie denn kennt.

Wenn man ein temporäres Repository erst einmal hat, können die beiden beteiligten Personen bequem damit arbeiten.

B möchte zum Beispiel in einem Feature-Branch arbeiten:

git fetch
git checkout -b b_contrib origin/master

A kann neues Material aus dem offiziellen Repository jederzeit zur Verfügung stellen:

git fetch origin
git push collab origin/master:master

B nimmt das Material entgegen, wie bei Feature-Branches üblich:

git fetch origin
git rebase origin/master

B kann Material zur Verfügung stellen:

git push origin -u b_contrib

und A schaut es sich an:

git fetch collab
git checkout -b b_contrib collab/b_contrib

(Alternativ richtet sich A dafür einen eigenen Worktree ein.)

Soll das Material im offiziellen Repository als Feature-Branch auftauchen, kann A es dort zugänglich machen:

git push origin collab/b_contrib:b_contrib

Ross und beide Reiter nennen

Bei der vorgestellten Arbeitsweise bleiben die Commits von B erhalten. Sie finden sich später komplett mit Checkin-Kommentar, Zeitstempel und Autorenangabe "B" im offiziellen Repo. Dass sie durch Vermittlung von A dort gelandet sind, geht aus dem Repository-Inhalt nicht mehr hervor.

Das kann im Einzelfall erwünscht oder unerwünscht sein. Möglicherweise möchte man die Mitwirkung von A langfristig nachvollziehen können. Dafür bietet sich eine andere selten genutzte Vielfalt an, die Git bietet.

Jedes Versionsmanagementsystem kann selbstverständlich für jede Änderung die Frage beantworten: "Wer war das?" Git bietet dazu noch Mehrwert: Für jeden Commit werden nicht nur ein, sondern zwei Verantwortliche ins Repository eingetragen. Als "Author" wird in der Git-Terminologie die Person bezeichnet, die die Änderung inhaltlich entwickelte, als "Committer", wer sie ins Repository eintrug. Die beiden sind häufig identisch, müssen es aber nicht sein.

Zwei Verantwortliche in jedem Commit (Abb. 4)
Zwei Verantwortliche in jedem Commit (Abb. 4)

Einen neuen Commit kennzeichnet die eintragende Person als den inhaltlichen Beitrag von zum
Beispiel "A. U. Thor", mit einem Befehl wie

git commit --author='A U Thor <a.u.thor@example.org>' 

Die entstehenden kompletten Angaben kann man sich mit git log anschauen, für den letzten Commit zum Beispiel mit

git log --pretty=fuller HEAD^..HEAD

Ein beispielhafter Output sieht wie folgt aus:

commit 84601e93dff652b0c8c2cbc1ec9e476366b06888 (HEAD -> git-vielfalt-artikel)
Author: A U Thor <a.u.thor@example.org>
AuthorDate: Mon Mar 4 14:23:18 2019 +0100
Commit: Andreas Krüger <andreas.krueger@innoq.com>
CommitDate: Mon Mar 4 14:23:18 2019 +0100

Sample commit with different author.

Es ist auch möglich, sich nachträglich als Committer einzutragen. Dazu erstellt derjenige einfach eine passende Kopie des Materials. In der oben beschriebenen Situation könnte A dazu folgende Befehle ausführen:

git checkout b_contrib
git rebase --no-ff origin/master

117 Kommentare

Themen: