Marcus, tl;dr: I advise against rebasing published branches.
In my view, it is perfectly fine to leave your pull request alone if it still merges cleanly. Rebasing on every commit to master? That way madness lies. Rebasing any published branch, even one made for a pull request, is rewriting history, and will prevent anyone from pulling from your branch (which I often do when reviewing). Reviewers are quite capable of cherry-picking if required. Also, rebasing changes the branch so it no longer matches the comments in the pull request. Pull requests are associated with branches by name not by their commit id. On the other hand, there are some developers who rebase to keep their pull-request branches clean. While this does make their requests tidy, git does not require this practice. If I have made a terrible mess, I prefer to close a pull request and make a new branch and pull request, rather than rebase. This seems more transparent to me, and preserves the relevance of existing comments. Kind regards, Ben. On 26/08/15 22:14, Sen, Marcus A. wrote: > A related general question... When master goes ahead of the commit on which a > pull request I submitted was based, is it best practice for me to rebase the > pull request branch on top of the latest master and checking the build > whenever I notice commits to master? -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
