This post is a follow up to this one where we explore the .git directory.
The base of the rebase
This what you might have in mind when ...
For further actions, you may consider blocking this person and/or reporting abuse
I'm going to admit something: I've never rebased.
I've never seen a reason to.
My team commits early and often, and we push to GitHub constantly. This includes our feature branches. If someone was working on a feature over two days and didn't push at the end of each day, I'd be mad. Shit happens, laptops break, and code would go away. So push your branch to GitHub.
And since it is on a remote like GitHub, and the golden rule as you say is to never rebase a branch that someone else could have pulled down, then this is always the case.
So, we never rebase. We pull master. Create a new branch. Work on it. Push it to GH. When complete, make a PR. Merge into master. Deploy. Repeat.
The biggest reason to rebase is to keep your commit history clean. If you are working on a project with many active contributors, you'll almost certainly need to merge recent changes to master into your feature branch to prevent merge conflicts. This creates a merge commit which does nothing but gum up your commit history on master when you merge it.
feat: foo
fix: bar
merge branch master into branch feature
merge branch feature into branch master
it makes grokking your commit history much easier if you rebase PRs instead of merging since it gets rid of that extra commit and makes your commit history more declarative.
Except to do that my team has to break another rule -- don't rebase if you pushed your branch remotely because someone else could pick it up.
In fact, since making a PR requires having pushed to GitHub, shouldn't you never rebase if a PR is involved?
As long as all team members are aware ahead of time, I don't think it should be a problem, just make sure to pull in the remote before doing additional work (
git pull -ror similar). How often are multiple team members working on the same PR at the same time? If you ever find that's the case it signals to me that your PRs should be more focused.Rarely honestly.
Currently though the way we do things just doesn't bother me. I don't mind the extra commit of the merge and other than "slightly cleaner history", I don't see a benefit of rebase right now that would make us change.
Every time I read up on it, and I do occasionally to see if there are ways to improve our flow, after all the back and forth opinions on whether rebase is good or bad or neutral or helpful or destructive, I end up back at "Well, we're doing good now and I can't see a real good reason to do rebase yet".
Then I check again when inevitably another one of these articles comes up about it. I'm not vehemently opposed to it, I just don't get an overwhelming sense of it being "right" compared to what we do.
Totally fair. At the end of the day you should favor whatever works best for your team, and I 100% agree, if it's not broken, don't try to fix it.
I have also never used rebase. You are not alone!
Nice article. Rebase is actually part of my teams day-to-day. Yes, we force push after a rebase but the commit history is clean, especially if commits are squashed. You also don't see merge commits in the history which is nice. If everyone's on the same page it can work quite nicely combined with CI and slack bots. I'm probably the odd man out here though 😂
Ditto: we're a small team (3 devs, all in the same location) and often rebase if more than one of us has been working on the same code. With small commits it's easy to sort the occasional conflict, but you have to agree to this method as a team.