Git Workflow Question: Getting Ready for a Pull Request

[John R. Graham]

I think this is a fairly normal workflow. I've done the following:

1. Check out "master".
   
2. Create a feature branch. Call it "feature".
   
3. Work on the feature branch, committing early an often with various temporary changes, debug chatter, and generally being very verbose about my reasoning, false starts, and so forth.
   
4. If other work is being done on master (not by me), merge and rebase as appropriate to keep my feature branch reasonably up to date with master.

Now I'm ready to submit my feature to upstream, but all of this commit chatter is meaningless to anyone but me. I also want to preserve the debug code, that I won't be submitting upstream, for my own benefit for future development on the feature branch. So what I want to do is:

1. Create a "release-candidate" branch from the current HEAD of the "feature" branch.
   
2. Edit out all of the extraneous debug chatter in the code and commit the clean code on the new branch with appropriate explanatory comments.
   
3. Do something so that the "release-candidate" branch is attached to the HEAD of master so that only the commits I want to be part of the pull request are in that branch.

It's that last step that I don't know how to do. Some pointers would be appreciated.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[logrusx]

[pingtoo]

[logrusx]

[pingtoo]

[keekkenen]