Arbeiten mit Git

Dawosch

Neues Mitglied
Schönen guten Abend zusammen,
ich nutzte Git schon eine ganz Weile, doch immer nur sehr rudimentär und an vielen Stellen wahrscheinlich nicht wie man sollte.
Davon getrieben mein Vorgehen stets zu optimieren stellen sich mir viele Fragen, auf die ich gerne eure Meinung lesen würde.
  • Nutzt ihr Branches?
    • Wann entscheidet ihr einen weiteren Branch zu erstellen?
    • Löscht ihr den Branch nach einem Merge in den Master?
  • Löscht ihr eure Branches nach dem Merge in den Master?
  • Pusht ihr eure Committs direkt in den Master, oder nutzt ihr Pull Requests? (Interessant bezogen auf das Arbeiten in Teams, Open Source Projekte auf z.B. Github mal außen vor, da hier Pull Requests Standard sind)
  • Nutzt ihr lieber den Merge Befehl oder den Rebase Befehl?

Ich würde zum diesem Thema ganz gerne eine offene Diskussion eröffnen um eure Erfahrungen und evtl. "Best Practices" zu hören.
Ich denke, dass ich hierzu noch eine Menge lernen kann und freue mich auf eure Antworten.

Grüße
 

Lowl3v3l

Aktives Mitglied
devCommunity-Experte
Ich benutze eigentlich immer Vincent Driessen's Branching Model, und SemVer2.0.

Wer in Git keine Branches benutzt benutzt die Software klar falsch, da gibt es soweit ich weiß auch keine Debatte zu. Direkte Pushes auf Master sind ein Antipattern, da sind sich eigentlich auch alle einig, ausgenommen sind da nur Fälle wie Cherry-Picks oder Merges.
Rebasing sollte man i.A. auch nur mit besonders gutem Grund tun, da man von der History grundsätzlich die Finger lassen sollte, vor allem, wenn es mit Merges einen vollständig nicht-destruktiven Weg gibt das selbe zu erreichen, der insbesondere auch keinen Teil der Geschichte schreddert. Allein schon, dass es zu rebasing "golden Rules" gibt sollte eigentlich genug darüber aussagen, dass das eine schlechte Idee als default-Workflow ist.
Da nicht alle dazu fähig sind, sich an derart einfache Regeln zu halten, bin ich mittlerweile dazu übergegangen, die meisten der schlechteren Ideen direkt in allen Repos über die ich die Macht habe per git-hooks zu verbieten, insbesondere, aber nicht ausschließlich, sind das: direkte commits auf master oder develop, rebasing auf öffentlichen Branches, amend. Ich hab bestimmt noch welche vergessen, mittlerweile kopiere ich die hooks nur noch immer weiter, wenn mal ein neues Repo aufgemacht wird.

Mfg
 
Zuletzt bearbeitet:

LimDul79

Neues Mitglied
Schönen guten Abend zusammen,
ich nutzte Git schon eine ganz Weile, doch immer nur sehr rudimentär und an vielen Stellen wahrscheinlich nicht wie man sollte.
Davon getrieben mein Vorgehen stets zu optimieren stellen sich mir viele Fragen, auf die ich gerne eure Meinung lesen würde.
  • Nutzt ihr Branches?
    • Wann entscheidet ihr einen weiteren Branch zu erstellen?
    • Löscht ihr den Branch nach einem Merge in den Master?
Ja - ansonsten kann man sich GIT auch schenken.
Für jedes Feature / Ticket / Änderung gibt es einen Branch. Entweder mit der Ticket-Nummer oder einem sprechenden Namen für die Mini-Korrektur.

Nur privat, wenn ich eh der einzige bin, der drauf arbeitet schenke ich mir meist Branches.

  • Löscht ihr eure Branches nach dem Merge in den Master?
Meistens, da sie nicht mehr benötigt werden und sonst die Liste zu lang wird.

  • Pusht ihr eure Committs direkt in den Master, oder nutzt ihr Pull Requests? (Interessant bezogen auf das Arbeiten in Teams, Open Source Projekte auf z.B. Github mal außen vor, da hier Pull Requests Standard sind)
Außer privat, wenn ich eh der einzige bin, sind direkte pushes auf den master verboten (und auch technisch verboten). Immer Pull-Requests oder vergleichbares.

  • Nutzt ihr lieber den Merge Befehl oder den Rebase Befehl?
Kommt drauf an. Rebase mag ich mehr, der ist aber nix für Team-Arbeit. Wenn man gerrit nutzt, arbeitet man automatisch transparent mit Rebases. Ansonsten nutze ich rebase nur, wenn ich 100% weiß das ich alleine auf dem Feature-Branch bin.
 

dominik

Mitglied
Nutzt ihr Branches?
  • Wann entscheidet ihr einen weiteren Branch zu erstellen?
  • Löscht ihr den Branch nach einem Merge in den Master?

Ja, weil das neben lokalen Commits eines der Hauptargumente für Git ist. Ich erstelle für jedes Feature mindestens einen Branch. Sehr große Features wickle ich im Rahmen mehrerer Branches und entsprechender PRs ab, um langlebige Branches zu vermeiden - das sind nämlich Refactoring-Killer - und um ein schrittweises Code Review zu ermöglichen.

Bei Open-Source-Projekten lösche ich die Branches vom Remote erst nach einem neuen Release.

Pusht ihr eure Committs direkt in den Master, oder nutzt ihr Pull Requests?

Bei privaten Projekten pushe ich für triviale Anpassungen direkt auf den Master, bei öffentlichen Projekten natürlich nicht. Manchmal erstelle ich aber auch bei privaten Projekten einen PR, um bei größeren oder komplexen Änderungen eine einfache Übersicht zu erhalten, welche Stellen mit dem Merge geändert werden.

Nutzt ihr lieber den Merge Befehl oder den Rebase Befehl?

Rebasen finde ich schöner, aber in der Arbeit oder bei anderen größeren Teams traue ich mich nicht :)
 

JR Cologne

Administrator
Teammitglied
  • Nutzt ihr Branches?
    • Wann entscheidet ihr einen weiteren Branch zu erstellen?
    • Löscht ihr den Branch nach einem Merge in den Master?
Privat nutze ich, zumindest bei kleineren, schnellen Änderungen, teilweise keine Branches.
Bei Projekten, wo man der einzige Entwickler ist, kann man das richtige Branching also schon mal etwas schleifen lassen.
Ansonsten ist das aber natürlich absolute Pflicht. Für jedes Feature/Ticket wird entsprechend ein eigener Branch angelegt, wie oben schon von den anderen beschrieben.

Den Branch lösche ich eigentlich so gut wie immer nach einem Merge - im Idealfall geschieht das automatisch.
Das gilt für mich allein schon, weil es mehr Übersicht schafft und mit dem Merge eines Branches die dortige Entwicklung eigentlich abgeschlossen sein sollte.

Pusht ihr eure Committs direkt in den Master, oder nutzt ihr Pull Requests?
Wie gesagt: Bei privaten Projekten pushe ich auch schon mal direkt auf master.
Eigentlich bin ich aber auch immer mehr dazu übergegangen, Pull Requests zu nutzen und den direkten Push auf master zu verbieten.
Im Team ist das nochmal wichtiger, da auf master meist nur das landen sollte, was in irgendeiner Form durch eine andere Person abgenommen wurde und im Produktionssystem landen darf.

Nutzt ihr lieber den Merge Befehl oder den Rebase Befehl?
Rebase nutze ich eigentlich gar nicht. Meist ist es der klassische Merge-Commit oder alternativ ein Squash-Merge, wenn die Historie nicht mit Commits wie "wip" verunstaltet werden soll. :D
 
Oben Unten