ist es in Ordnung, immer git pull –rebase master branch zu verwenden

Wir sind ein Team, das mit Git arbeitet, wir haben ein zentrales Repository (einzelner Ursprung), das wir verwenden push und pull from (und capistrano verwendet es, um den Branch-Master bereitzustellen)

Wir machen regelmäßig Commits und Deployments (10 bis 20 Deployments pro Tag), das heißt, wir haben viele Merge-Commits und git blame zum Albtraum werden

Ich habe das gelesen, um eine einfachere Geschichte zu haben, die wir verwenden können git pull --rebase um es zu umgehen. Ist es eine gute Idee, dies immer auf dem Master-Zweig zu tun?

Wenn ja, würde ich vorschlagen, es in der Konfiguration festzulegen mit:

git config branch.master.rebase true

Gibt es ein Problem damit?

Überhaupt kein Problem. Das wird sogar bevorzugt.

In 99 % der Fälle ist es besser, die Änderungen zu rebasen. Wenn nicht, kann der Entwickler die Rebase jederzeit abbrechen und seine Änderungen manuell zusammenführen.

Die Alternative (Merging on Pull) verursacht haufenweise kleine Side-Commits und Merges, die keinen Sinn ergeben.

Im Allgemeinen sehe ich nicht oft den Sinn, lokale Änderungen zusammenzuführen. Es impliziert, dass es etwas Besonderes an der genauen Revision gab, mit der der Entwickler begonnen hat, und irgendwie würde ein Rebasing auf eine andere Revision zu einem Informationsverlust führen (vielleicht „Ich habe damit vor Bobs Feature begonnen und ich möchte das mitteilen, falls dies nicht der Fall ist spiele gut mit Bob und ich werde beschuldigt” oder so…). Dies ist tatsächlich selten der Fall und eine saubere, geradlinige Commit-Historie ist viel einfacher zu verfolgen.

Pull-Rebase standardmäßig zu machen ist in Ordnung (nicht unbedingt eine “gute Idee”, auch nicht unbedingt eine “schlechte Idee”). Sie müssen nur bedenken, dass dies Ihre Arbeit tatsächlich rebasiert. Wenn Sie eine Reihe von Commits gemacht haben, die alle davon abhängen, was im Repo war Vor Bob hat es geändert¹kann Ihr Rebase (zusätzlich zu Bobs Änderungen) Sie dazu zwingen, all diese Commits zu korrigieren, obwohl es einfacher gewesen wäre, nur den endgültigen Merge-Commit zu korrigieren.

Ich mache das lieber manuell: run git fetchund dann git rebase oder git merge je nach Situation, die ich feststellen kann, sobald ich das Holen durchgeführt habe.

Es gibt einen Vorteil git pull --rebase (und/oder Einstellung branch.master.rebase true), da ein “Pull mit Rebase” besonders intelligent ist und einige Fälle handhaben kann, in denen die Fernbedienung auch Rebases durchgeführt hat.

¹“Bob” steht hier für jeden, der eine Änderung vorgenommen hat (und Sie geschlagen hat push Schritt), der dazu führt, dass Ihre eigenen Änderungen sozusagen “Verdauungsstörungen haben”.

Pull.rebase ist meiner Erfahrung nach immer in Ordnung. Wenn Sie keine Zusammenführungskonflikte haben möchten, können Sie in einem lokalen Zweig arbeiten, und wenn Sie mit dem neuesten Code arbeiten möchten, ziehen Sie es immer vor, alle nicht festgeschriebenen Änderungen zu haben, bevor Ihre aktuelle Arbeit gepusht wird.

Zusammenführung in einer Filiale als Folge git pull ist fast immer bedeutungslos, wenn Merge sinnvoll wäre, hätten Zweige anders sein sollen (und Merge explizit).

Siehe auch http://stevenharman.net/git-pull-with-automatic-rebase.