Oh I've got a very clear answer when to use rebase: n-e-v-e-r. The process is obscure and the tooling is bad, even in modern IDEs such as IntelliJ it's not clear what is going on during a rebase. Just don't do it, the downsides by far outweigh the advantages. A force push is rarely a good idea. My team uses gitflow almost exclusively and we're quite happy with it, aside from the occasional "shouldn't we use rebase" discussion.
I’d like to disagree. While it requires some caution, pull —rebase / regular rebase of live branches / interactive rebase before merge / merge —no-ff workflow leads to a much cleaner history and makes reorganization/disaster recovery much easier, at least to my taste.
If rebase implies force push on shared branches and if you rely on automagic GUI trickery in your team, then you probably need training and discipline more that a simpler workflow.
Sure, why not having a civilized conversation by starting off with implying that the other guy has no idea what they are talking about and "need training". Way to go.
I've heard the arguments - all of them, plenty of times, over and over again. I am fully aware of the advantages. And I still think that it's a bad idea. You may call it a "clean history" - I say this is not how it happened. The result of a rebase is an arbitrarily twisted and warped version of the actual project history. If the sole reason for a rebase is a straight line in gitk, then count me out. Sticking to gitflow with merge commits gives you a history that actually deserves the name because it is based on facts. It is a perfectly fine workflow, even juniors get it quickly. I see no reason to add more complexity to that. And rebase is not without caveats.
Sorry if my tone was condescendent, I was just feeling that if your initial harsh rejection of rebase was because it was synonymous of force pushes and lack of proper GUI, it was pretty misguided.
If we start talking about the real stuff, then I’m not a gitk follower either. And I merge on trunks (no-ff), but after a rebase. Actually after regular rebases of living branches between their emergence and their merge. No rebase of shared branches (clone then rebase if the base is too old after a proper synchronization point), no push force either, publication of a private branch after rebase and before merge —no-ff to have the commits details on hand. Gitflow is ok to me, just feature/private branches handling feels better with rebases than with merges at least to me.
Sorry again if you took it personally, but you started 😝 by attacking cruelly my lovely rebase.
The main goal of rebase is to prepare a branch before submitting pull request (or equivalent), in the "blessed repository" workflow. It helps maintainer to have up-to-date changes, and less conflicts.
While at it, you can cleanup all the "fixup" commits with git rebase --interactive.
Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
Is the "blessed repository" or integrator workflow similar to a forking workflow? I was trying to research the difference but they sound similar to me.
Former Java engineer turned Ruby engineer who is trying to understand Ruby and Rails, MacOS and a lot of other things. Worked at Flywheel, FNBO, ACI Worldwide.
Oh I've got a very clear answer when to use rebase: n-e-v-e-r. The process is obscure and the tooling is bad, even in modern IDEs such as IntelliJ it's not clear what is going on during a rebase. Just don't do it, the downsides by far outweigh the advantages. A force push is rarely a good idea. My team uses gitflow almost exclusively and we're quite happy with it, aside from the occasional "shouldn't we use rebase" discussion.
I’d like to disagree. While it requires some caution, pull —rebase / regular rebase of live branches / interactive rebase before merge / merge —no-ff workflow leads to a much cleaner history and makes reorganization/disaster recovery much easier, at least to my taste.
If rebase implies force push on shared branches and if you rely on automagic GUI trickery in your team, then you probably need training and discipline more that a simpler workflow.
Sure, why not having a civilized conversation by starting off with implying that the other guy has no idea what they are talking about and "need training". Way to go.
I've heard the arguments - all of them, plenty of times, over and over again. I am fully aware of the advantages. And I still think that it's a bad idea. You may call it a "clean history" - I say this is not how it happened. The result of a rebase is an arbitrarily twisted and warped version of the actual project history. If the sole reason for a rebase is a straight line in gitk, then count me out. Sticking to gitflow with merge commits gives you a history that actually deserves the name because it is based on facts. It is a perfectly fine workflow, even juniors get it quickly. I see no reason to add more complexity to that. And rebase is not without caveats.
Sorry if my tone was condescendent, I was just feeling that if your initial harsh rejection of rebase was because it was synonymous of force pushes and lack of proper GUI, it was pretty misguided.
If we start talking about the real stuff, then I’m not a gitk follower either. And I merge on trunks (no-ff), but after a rebase. Actually after regular rebases of living branches between their emergence and their merge. No rebase of shared branches (clone then rebase if the base is too old after a proper synchronization point), no push force either, publication of a private branch after rebase and before merge —no-ff to have the commits details on hand. Gitflow is ok to me, just feature/private branches handling feels better with rebases than with merges at least to me.
Sorry again if you took it personally, but you started 😝 by attacking cruelly my lovely rebase.
The main goal of rebase is to prepare a branch before submitting pull request (or equivalent), in the "blessed repository" workflow. It helps maintainer to have up-to-date changes, and less conflicts.
While at it, you can cleanup all the "fixup" commits with
git rebase --interactive.Is the "blessed repository" or integrator workflow similar to a forking workflow? I was trying to research the difference but they sound similar to me.
I am talking here about workflow titled "Integration-Manager Workflow" in the "Pro Git" book, chapter 5.1: Distributed Workflows.
Got it, the infographics are quite helpful with reading through git workflows.