Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Rebasing a long-lived branch sounds like a bad idea. As long as you don't have hotfixes on master you can fast-forward. When FFs are not possible I'd probably settle on merges.
-
Where is the feature branch getting from originally? Usually as a rule of thumb I merge each branch to where it came from.
-
CptFox16165yI guess you could simply use what you described for master, but on staging, and then fast-forward master to staging whenever the conditions for that are met.
-
I'm still a bit unsure of rebasing but I was doing some reading up on Git the other day and there was one bit of advice that stuck with me. Rebasing is fine for your own branches, but stick to good ol' merge for shared branches (like master, develop, staging etc.) where multiple people have work merged in to the same branch.
But that's just me. 💁♀️ -
bnjns865yI think reading depends how your team works together. I really like rebasing because it keeps your history nice and clean (not littered with loads of horrible merge commits) but the caveat is that you need to be careful if multiple people are working on it. As a general rule of thumb, I'll only rebase as the final step before merging to minimise any confusion.
I don't like squashing though - you end up losing the entire history of that feature.
As for branching, everything comes from and goes into master, and we can then control which environment that goes to. Not seen this way of doing it before, but it's actually quite nice.
Related Rants
How to use git rebase when working with master and staging branch?
It might be a stupid question, but I really like the idea of creating a feature branch, work on it, if there are multiple commits squash them, rebase in top of master and then create a pull request from that branch to master.
It keeps the gut log pretty clean.
However, how would you do this, when not only working with a master branch but a staging/testing too?
Would you just rebase onto staging, merge to staging and when everything is fine, rebase onto master and merge again? Is there a netter way?
question
git
rebase
sqash