The standard procedure in this case is to fix those issues with commit , and when all is done and ready to be merged you'll do a git squash - http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
You do don't need to do a PR within your own branches, you can just rebase or merge as needed. PRs are meant to be sent across forks. -- Itamar Syn-Hershko http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member On Thu, Jan 22, 2015 at 1:53 AM, Guido Tagliavini Ponce < [email protected]> wrote: > Hi devs, > > This mail is not about lucenenet specifically but about a problem I'm > having with Git. I have already forked lucenenet's master branch, and > worked on my own branch. Over the development process, some changes I made > where reviewed by Itamar, and some of those where regarded as NOCOMMITs. > Now, I want to do a PR from my branch to the master (Apache's one), but > only with the "good" changes. Using cherry-pick seems promising, but I have > a problem with that: Some commits include "good" and "bad" changes, so I > cannot completely discard those. To solve this I could do another commit, > changing the "bad" part, and include both commits in the pull request. > Anyway, I don't know if this is the standard procedure to solve this kind > of issues. Could someone tell me what is the best or standard way to do it? > > A final question about PRing: Do I have to pull request from my branch to > my own master, and then from the latter to Apache's master? Or should I do > it directly from my branch to Apache's master? > > Best regards, > > Guido >
