3 ms·
Adding to GitHub Pull Requests, I recommend opening them early. This allows reviews to happen early and often, instead of reviewing one giant chunk of changes a
by reledi 12y ago
Adding to GitHub Pull Requests, I recommend opening them early. This allows reviews to happen early and often, instead of reviewing one giant chunk of changes at the end which may get rejected because it has too many problems.
Plan out the tasks in your PR to communicate what still needs to be done -- I like to use GitHub Flavored Markdown task lists.
Here's a fish script I use when creating a new branch. It opens a PR before I even write a single line of code.
# Usage: git-new-branch 120-fix-foo-issue
function git-new-branch --description 'Creates a new branch and opens a Pull Request for it'
git checkout -b $argv[1]
git commit --allow-empty -m 'Empty commit to open PR'
git push origin HEAD
git pull-request # Opens your default text editor for PR title. Uses hub.
end
- smathieu 12y agoAnother good thing about this is that if you have CI setup to work with Github, you can also run all of your test suite quickly and asynchronously for each commit.
- j_s 12y agoYou can also convert issues (which often are created before writing code, as the reason for the changes) to pull requests: http://stackoverflow.com/questions/4528869/how-do-you-attach-a-new-pull-request-to-an-existing-issue-on-github http://stackoverflow.com/questions/4528869/how-do-you-attach...
- reledi 12y agoI think having an issue attached to your PR is much better than converting your issue to a PR. Here's a good discussion about why it's been deprecated: https://github.com/github/hub/commit/4f70dd126f46dec14fc341c97c18efae417743c7 https://github.com/github/hub/commit/4f70dd126f46dec14fc341c...