Nehmen wir an, man benutzt Git im Team. Obwohl man immer auf seinem eigenen Repository arbeitet muss man irgendwann wieder mit den anderen Teammitgliedern synchronisieren. Bei Git arbeitet man dabei besonders mit dem Konzept von Branches.
Die Hauptbranch in Git ist per Naming Convention der "master". Auch wenn ich nur an einem kleinen Feature arbeite lege ich mir sofort eine Branch an, die den Stand vom Master hat mit
Auf dieser Branch arbeite ich weiter, mache Änderungen, commite sie oder lege sie ab. Statt Änderungen komplett zu verwerfen lege ich sie lieber ab, was man mit Git Stash machen kann. Wer weiß, vielleicht möchte ich sie ja doch später wieder hohlen.
Sollte das Feature nicht ganz so klein sein, muss man sich Gedanken machen, wie man die Branch auf dem Stand des Masters hält. Andere Team-Members pushen dort vielleicht Änderungen. Arbeite ich alleine an meiner Branch gibt es das tolle Feature "Rebase" bei Git. Ziel ist am Ende der Entwicklung mein Feature in den Master zu mergen und zwar möglichst so, dass es bei Problemen leicht ausgebaut werden kann. Dafür ist es schön wenn bei Git log nicht jeder einzelne Commit den ich lokal gemacht habe auftaucht, sondern vielleicht einer: myNewFeature Featurenummer xyz oder so etwas. Rebase verändert die History und lässt mich Commits genau dort einfügen wo ich sie haben will. Ein regelmäßiges Rebase verhindert das Auflösen von Konflikten an Ende der Entwicklung. Um ein Rebase zu machen wechsle ich ich erstmal wieder auf den Master
Die Hauptbranch in Git ist per Naming Convention der "master". Auch wenn ich nur an einem kleinen Feature arbeite lege ich mir sofort eine Branch an, die den Stand vom Master hat mit
git checkout -b myFeatureBranch
Auf dieser Branch arbeite ich weiter, mache Änderungen, commite sie oder lege sie ab. Statt Änderungen komplett zu verwerfen lege ich sie lieber ab, was man mit Git Stash machen kann. Wer weiß, vielleicht möchte ich sie ja doch später wieder hohlen.
git stashlegt die aktuellen Änderungen im Stash ab und setzt den Arbeitsstand zurück auf den letzten Commit. Stash ist mächtig, man kann den gesamten Stash durchsuchen und die verworfenen Stände zurückhohlen. Meist brauche ich aber nur
git stash popwelches die letzte Änderung vom Stash holt. Ansonsten mache ich Commits mit meinen Änderungen.
Sollte das Feature nicht ganz so klein sein, muss man sich Gedanken machen, wie man die Branch auf dem Stand des Masters hält. Andere Team-Members pushen dort vielleicht Änderungen. Arbeite ich alleine an meiner Branch gibt es das tolle Feature "Rebase" bei Git. Ziel ist am Ende der Entwicklung mein Feature in den Master zu mergen und zwar möglichst so, dass es bei Problemen leicht ausgebaut werden kann. Dafür ist es schön wenn bei Git log nicht jeder einzelne Commit den ich lokal gemacht habe auftaucht, sondern vielleicht einer: myNewFeature Featurenummer xyz oder so etwas. Rebase verändert die History und lässt mich Commits genau dort einfügen wo ich sie haben will. Ein regelmäßiges Rebase verhindert das Auflösen von Konflikten an Ende der Entwicklung. Um ein Rebase zu machen wechsle ich ich erstmal wieder auf den Master
git checkout masterund hohle mir die neuesten Änderungen
git pullNun ist der Master lokal auf dem neuesten Stand und ich kann wieder zur Branch wechseln mit
git checkout myNewFeatureHier rufe ich nun
git rebase masterauf. Gibt es keine Konflikte habe ich damit erfolgreich ein Rebase ausgeführt. Was man bei Konflikten tun kann beschreibe ich in einem anderen Blog Post ;-)
