in hibernate project, we do the following to accept a PR: 1. check out a local branch from the original PR creator's branch 2. rebase it to the master (or whatever the target branch is) 3. push master
of course, there will be some conflicts if the creator's branch can't be fast forwarded personally, I'd resolve the conflicts if it is not too complicated, but usually, I'd say it is the creator's job to make sure the PR can be fast forward. and this process surely is more complicated than click the "merge" button, but, you will get a liner history, I'd say it is much more important for an open source project. IIRC, there is a git config to only allow fast forward merge. and keep the PR small would resolve most of conflicts, or easier. here is an example of hibernate validator project commit history the "incrementing brower versioning" PR and my 'Miscellaneous" PR (see attach) both can be rebased w/o any conflicts I think On Tue, Apr 22, 2014 at 12:28 AM, Todd Nine <[email protected]> wrote: > Hey Strong, > What would your proposed flow be for rebasing before PR? I agree it's > much cleaner from a commit history standpoint. For me, I've never > successfully managed to rebase anything without receiving merge errors for > every commit replay. When you have a large feature branch that's touched a > lot of code, manually merging each commit during the rebase is really > painful. We've been using merge because from a developer perspective it > "just works". If you have a strategy that has worked well for you in the > past, I'm all for giving it a try. > > Thoughts? > Todd > > > On Mon, Apr 21, 2014 at 9:14 AM, Strong Liu <[email protected]> wrote: > > > Hi guys, > > > > as $subject, rebase would give us a much much cleaner view to see what’s > > happening :D > > > > it is really hard to trace the commit history, for example > > > > WDYT? > > >
