Meiner Erfahung nach ist es, wenn man mit mehreren zusammen an einem git-Repo arbeitet, schon fast unerlässlich, dass man nur auf einem lokalem feature-Branch, neben dem Branch, den man aus dem remote-Repository geholt hat - ich nenne den mal develop, arbeitet.
Man hat also folgende Branches:
lokal:
feature
develop -> remote/develop
remote:
develop
Der feature-Branch wird von dem develop-branch nach dem Clone abgezweigt. Man macht nur Änderungen auf dem feature-Branch und nie auf dem develop-Branch.
Am besten macht man einen Push, wenn man mit nach einer Änderung wieder einen lauffähigen Stand hat. Da sollte man sich auch vorher mit den Kollegen abstimmen, wer was macht. 😉
Wenn man den aktuellen Stand in den develop-Branch auf dem remote schieben will, macht man am besten folgendes:
In den develop-Branch wechseln
Pull
In den feature-Branch wechseln
Auf develop rebase (und mögliche Konflikte auflösen)
In den develop-Branch wechseln
feature in develop merge (sollte ja fast forward gehen)
Push
Man kann auch sich einen aktuellen Stand holen, auch wenn man noch nicht mit der Änderungen fertig ist:
Commit Änderung
In den develop-Branch wechseln
Pull
In den feature-Branch wechseln
Auf develop rebase (und mögliche Konflikte auflösen)
Man kann den Commit mit dem Zwischenstand dann immer noch mit commit --amend ändern.
PS: Am besten mehrere Commits zu einem Feature in einen Commit zusammenfassen, das erspart einem viel Arbeit beim Konflikte auflösen.