Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


Another 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.


You 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...


I 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/4f70dd126f46dec14fc341c...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: