| > As soon as someone added changes to their pull request – either by rebasing in the new changes or making it as a new commit – you lost track of the comments in the code and viewing what had actually changed since the last update became really hard (almost impossible if the new push was rebased with the new changes). We use github at work with a feature branch workflow (as opposed to gitflow). We've adopted a system where pull request comments are addressed through the use of "fixup" commits. For example, when a pull request is submitted for a feature branch that contains 3 commits, and a comment is made regarding part of the change, the person who submitted the PR will add a commit that addresses the comment with a commit title of: >> fixup! Title of the commit to update >> >> An explanation of what this commit does and why >> ... This, incidently, is exactly what git commit --fixup <commit_ref> does. Then the person responds to the comment saying that it was addressed in <commit_sha1>. As a reviewer, it makes it easy to see that my comment has been addressed and exactly what change was made to address it (by clicking on the link that github autogenerates from the sha1 in the comment). Once the review process is complete, the person will run git fetch origin and then git rebase -i --autosquash --keep-empty origin/master to actually reduce the set of commits down to the original clean set of commits. They then run a git diff <original branch head sha1>.. to verify that there are no differences and then they merge the PR using the merge button in the web interface. This way, you end up merging a clean set of commits for each PR, and it's still relatively easy to keep track of comments and incremental code changes addressing those comments during the PR. In fact, multiple developers can collaborate using the same branch by pushing up "fixup!" commits. Though they need to make sure that they fetch/merge or pull before they push to avoid unwanted merge commits within the branch. |