re: Git Rebase and the golden rule explained VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 f...

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.

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.

code of conduct - report abuse