7

I have solved an issue on an open project, on a dedictated fork I've made. After that, I've committed, pushed and merged (pull request) into the main master repo.

Now I wish to work on another issue.

What's the best way to do this? Should I use the same fork I worked on for previous issue(s)?

  • I don't know what best practices are, but it seems to me that the better option would be re-fork it, since other people might have made changes to the main master repo since you last forked it. That's just my opinion though. – Kyle Martin Feb 20 '17 at 17:35
11

Usually, for github, workflow is to have one fork (I even doubt you can fork the same repo more than once under the same account) but seperate branches per PR. Example:

  • create fork, clone locally
  • checkout a new, aptly named branch, say 'issuexxx-fix'
  • commit/push some work
  • create PR

When some time later you want to work on another issue you first get your fork up to date and repeat the above, in a different branch:

  • checkout master branch again
  • reset (or merge) master branch to upstream's latest commit
  • checkout a new, aptly named branch, e.g. issuexxx-fix
  • commit/push some work
  • create PR

And suppose you'd need more work on an issue you worked on before already, you'll normally want to rebase the original and new work on top of the latest upstream merges as that might reduce the amount of work the maintainer has to merge it (you fix possible conflicts instead of having them do it):

  • checkout the branch used
  • rebase on latest upstream commit
  • commit/push
  • existing PR gets updated automatically

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.