DEV Community

Discussion on: Git Rebase and the golden rule explained

Collapse
 
thebouv profile image
Anthony Bouvier

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?

Thread Thread
 
superhawk610 profile image
Aaron Ross

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 -r or 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.

Thread Thread
 
thebouv profile image
Anthony Bouvier

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.

Thread Thread
 
superhawk610 profile image
Aaron Ross

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.