I <3 git flow
git habe ich ja vor einiger Zeit als Versionskontrolle für meine Webdesign-Projekte gewählt. Und jetzt hat der asaaki mich auf git flow gebracht. git flow ist ein branching model, eine Methodik für git, die in meinen Augen eine sehr sinnvolle Abbildung von Software-Produktionsprozessen auf git darstellt. Es gibt das auch als Extension für git, die automatisch entsprechende Vorlagen anlegt. Ich habe angefangen, das mit einem krachneuen Projektchen zu benutzen. Mal sehen, ob das für mich total überkandidelt ist oder ob es auch für meine kleinen Projekte Sinn hat.
Für mich hat sich die git-flow-Praxis bewährt. Bei Open-Source-Projekten verschandle ich so nicht aus Versehen den master-Branch, der ja für die stabilen Versionen zur Verfügung stehen soll(te).
Ich finde, es macht genau dann Sinn, wenn man merkt, dass das eigene Projekt tatsächlich auch von anderen benutzt wird. Ab da übernimmt man ja auch eine gewisse Verantwortung gegenüber seinen Nutzern, und dann sollte man halt aufpassen, was man so ins Repo committet (schönes Denglish).
Natürlich kann man auch während der Entwicklung eh immer in temporären Arbeitsbranches werkeln, aber irgendwie hat sich dann diese develop-/master-Geschichte doch zu sehr bei vielen etabliert (auch ohne git-flow). Und damit ich auch auf mögliche Teamarbeiten in git-Repos vorbereitet bin, gewöhne ich mir diese Extratrennung einfach an (der develop-Branch ist dann sozusagen die gemeinsame Müllhalde der Entwicklung).
Außerdem: git-flow ist auch ein tolles Tool, um eine handvoll weniger Befehle einzutippen und manuelles Mergen fällt damit gerade im Single-User-Modus nahezu flach (so lange man nicht zig separate Branches am Laufen hat, die man ja auch noch immer aktualisieren muss, bla bla, das führt dann hier zu tief rein).
Mir ist grad aufgefallen, dass ich mal für meinen häufigen Prozess „git add .; git commit -m MESSAGE; git push“ auch mal n Miniscript tippen muss. :o)