Ich bin mir nicht sicher, ob du mit einem Softlink nicht dieselben oder noch schlimmere Probleme provozierst. Davon ab brauchst du "nur" dafür sorgen, dass ihr in beiden Kopien des Repos unterschiedliche Branches ausgecheckt habt und schon kannst du nach Herzenslust pushen. Denk aber daran, dass es dann komplexer werden könnte, was den Austausch zwischen den Branches angeht.
Grundsätzlich ist es nicht wild, ein Bare-Repo anzulegen. Ich habe hier mal die ersten Schritte durchgekaspert. ☺
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54 | $ git init --bare primary
Leeres Git-Repository in /.../primary/ initialisiert
$ git clone primary/ autor
Klone nach 'autor' ...
warning: Sie scheinen ein leeres Repository geklont zu haben.
Fertig.
$ git clone primary editor
Klone nach 'editor' ...
warning: Sie scheinen ein leeres Repository geklont zu haben.
Fertig.
$ cd autor/
$ git checkout -b master
Zu neuem Branch 'master' gewechselt
$ git commit --allow-empty --message "Initial commit"
[master (Root-Commit) bf520ee] Initial commit
$ git push
Objekte aufzählen: 2, Fertig.
Zähle Objekte: 100% (2/2), Fertig.
Schreibe Objekte: 100% (2/2), 173 Bytes | 173.00 KiB/s, Fertig.
Gesamt 2 (Delta 0), Wiederverwendet 0 (Delta 0)
To /.../primary/
* [new branch] master -> master
$ echo "Halol Welt!" > s1
$ git add s1
$ git commit -a --message "Erste Seite fertig"
[master 52c2db6] Erste Seite fertig
1 file changed, 1 insertion(+)
create mode 100644 s1
$ git push
Objekte aufzählen: 4, Fertig.
Zähle Objekte: 100% (4/4), Fertig.
Schreibe Objekte: 100% (3/3), 263 Bytes | 263.00 KiB/s, Fertig.
Gesamt 3 (Delta 0), Wiederverwendet 0 (Delta 0)
To /.../primary/
bf520ee..52c2db6 master -> master
$ cd ..
$ git clone primary/ editor
Klone nach 'editor' ...
Fertig.
$ cd editor/
$ git log --pretty=oneline
52c2db6d237ae24e6eef8278d707efd48ed6a19b (HEAD -> master, origin/master, origin/HEAD) Erste Seite fertig
bf520eebc12c70cf1d35fcba858fd742f675bde3 Initial commit
$ echo "Hallo Welt!" > s1
$ git commit -a --message "Korrektur S1"
[master 5d065bb] Korrektur S1
1 file changed, 1 insertion(+), 1 deletion(-)
$ git push
Objekte aufzählen: 5, Fertig.
Zähle Objekte: 100% (5/5), Fertig.
Schreibe Objekte: 100% (3/3), 258 Bytes | 258.00 KiB/s, Fertig.
Gesamt 3 (Delta 0), Wiederverwendet 0 (Delta 0)
To /.../
52c2db6..5d065bb master -> master
|
Ihr könntet euch jetzt gegenseitig mit git pull und git push zuwerfen, bis der erste Merge Conflict auftritt oder der Arzt kommt.
Mir liegt der Vorschlag auf der Zunge, mit unterschiedlichen Branches zu arbeiten, um die Arbeitsbereiche besser abzugrenzen. Grob umrissen könnte es so aussehen, dass du immer in einem "Kreativ"-Branch neue Inhalte schreibst und diese dann zu gegebener Zeit in den "Korrektur"-Branch überführst (mit git merge). Diese ganzen Änderungen werden dann mit push in das Primär-Repo übertragen, um sie für deinen Korrektor bereitzustellen.
Dein Korrektor macht dann von Zeit zu Zeit ein git pull, passt auf, welche Dateien sich im Vergleich zum letzten Mal geändert haben (z.B. mit git diff --name-only HEAD~1
) und legt mit Korrigieren los. Ist er fertig, kann er die Änderungen mit git commit -a
sichern und mittels push wieder ins zentrale Repo schieben.
Ergänzend/Alternativ dazu könntest du git gui, gitk (kommen beide mit git, zumindest unter macOS) oder z.B tig verwenden, um das Terminal etwas zu umgehen. Gerade git gui und ggf. noch ein grafisches Mergetool sollten sehr helfen, wenn das Terminal so gar nicht die richtige Option zu sein scheint. 😉
So, das sollte erstmal ausreichen, wobei mir das seltsam unzusammenhängend erscheint, was ich da geschrieben habe. 😕