github - If you git rebase and push, vs if you git pull, merge, and push, does it help the project maintainer the work of merging? -


it said if don't git rebase, project maintainer person may ask rebase changes (say, bugfix1122-branch) tip of master or development branch.

but save project maintainer's time merging it? thought either git pull, merge, , push, merge it, project maintainer doesn't have to. true? rebasing flatten history, flattening tree linear structure, git history more linear?

yes, rebasing branch onto master , merging master in before opening pull request have same effect, far helping project maintainer merge goes.

you right in saying rebasing done flatten history. however, there's special case in believe outperforms merge: when have conflicts. rebase force fix conflicts as commits applied, conflict resolution won't seen maintainer of project. merge, on other hand, force resolve conflicts all @ once, creating merge commit result, can make things harder understand maintainer.

that being said, becomes less of problem if github being used, allows maintainer review changes rather reviewing commits. personally, review commits, that's why prefer rebase. in end, comes down maintainer prefers, instructions in contributing.md file (if available) before opening pull request.


Comments

Popular posts from this blog

javascript - jQuery: Add class depending on URL in the best way -

caching - How to check if a url path exists in the service worker cache -

Redirect to a HTTPS version using .htaccess -