DEV Community

Discussion on: There Is No "Right" Way: Git Rebase vs Merge

Collapse
 
dovidweisz profile image
dovidweisz

The app I'm working on has rebasing ENFORCED!

This is achieved by blocking pushes on a subtask branch if it is behind it's feature branch. (Development is done on subbranches, testing is done on feature branches, and code review happens in the PR between the two.) Git remote actually responds with the exact commands you need to run in order to get up to speed.

This works pretty well because everyone does it, and our history is just so pretty 🙄.

My biggest beef with this is that it messes with my code review process: The way I work is I review all the code, and if I find issues I comment on them, and decline the PR. The developer then makes the necessary changes, pushes new commits and reopens the PR. At this point I don't want to review all the code. I want to review the new commits only. But since it was rebased, it's hard to find the new changes (and don't get me started on squashed commits).

The integrity of the hashes are also important in this case. It prevents people from perhaps using shortcuts that would of otherwise not been approved in the standard process.

Another issue is that when conflicts are resolved by a different developer, the commit still has the original developers name on it, Which just confuses them.

So as long as no one else involved in a branch, rebase and squash away (YOLO), but please don't enforce it.