Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Our code is on Github and we use Pull Requests to review the code. As a result of the review a commit might be reverted or changed. This might clutter the commit history. The rebase command is discouraged because the commits are already “publicly available”.
If you perform code reviews in a similar way: How do you deal with this? How do you keep your history clean?
Rebasing non-master (maint*, next) branches is ok even they are published.
Just use topic branches to publish new stuff to be reviewed. Then delete them in any case after they are merged into master or after the pull request has been declined.
See
man gitworkflows