Git-Zusammenarbeit mit Merge und Rebase

Nexus

Hallo zusammen

In letzter Zeit arbeite ich an einem Projekt, wo wir häufig gleichzeitig Code bearbeiten. Da kommt es teilweise vor, dass wir in kurzen Intervallen (halbe Stunde) auf GitHub pushen und pullen, um jeweils auf dem Laufenden zu bleiben.

Normalerweise kommt es dabei jeweils zu einem Merge-Commit, was die History extrem unübersichtlich macht. Daher benutze ich üblicherweise git pull --rebase , um alles zu linearisieren. Das Problem hier ist, dass ein Rebase eine saubere Working Copy verlangt, d.h. ich muss jeweils git stash save , git pull --rebase , git stash pop nacheinander ausführen (zumindest falls die lokalen Änderungen noch nicht commit-bereit sind). Klar kann ich das in ein Bash-Skript auslagern, aber Rebase und Stash sind recht langsame Operationen, ausserdem muss ich in der Mitte des Skripts den Schlüssel eingeben.

Wie handhabt ihr so eine Situation? Oder ändert ihr nur über längere Zeit hinweg, sodass Merges die Übersichtlichkeit erhöhen?

Ich muss irgendwas übersehen, denn als ich mal versuchsweise die Anwendung GitHub for Windows ausprobiert habe, gab es nie Merge Commits, und die Synchronisierung war recht schnell.

nman

Keine Ahnung was GitHub für Windows macht, aber es ist generell gute Praxis, Feature-Branches zu erstellen.

Warum willst du denn zwischendurch so oft pullen, dass nichtmal dein working directory clean ist? Und welchen Schlüssel musst du zwischendurch eingeben?

nman

Statt "git stash" zu verwenden kannst du auch einfach gleich richtige Commits erstellen; wenn du davon sehr viele produzierst, kannst du die später ja immer noch per interaktivem Rebase zu einem einzelnen Commit zusammensquashen.

Nexus

Es handelt sich um ein kleineres Projekt, bei dem sich völlig unabhängige Feature-Branches kaum lohnen. Wir besprechen oft aktuelle Probleme, während wir Code schreiben, beheben sie, und passen gleich den Code an. So kombinieren wir oft gleich die neuesten Features. Ist also nicht der typische Git-Workflow

Ja, committen und interaktiv rebasen ginge auch, finde ich für eine einzelne Änderung allerdings mehr Aufwand als schnell stashen.

nman

Ich kann nur empfehlen, wirklich oft zu committen. Viele Commits sind gut, die helfen auch beim Debuggen, wenn du mal Kleinmist zerschießt. Und bevor du die dann alle hochpusht, kannst du ein git fetch && git rebase -i origin/master machen.

Ergo verstehe ich das Problem vmtl. einfach nicht so hunderprozentig.