What is good Git workflow to contribute to a repo that works with pull requests? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

I have to contribute to an open source repo on GitHub.

I have done the following:

1. Forked the repo
2. Cloned the repo locally
3. Made changes

4. Tested the changes (and it's all good)

   • Now if I commit locally (in the same master branch), push it, make a pull request, and they take 3 weeks to review it, what should I do if I need to work on some other bug in the meantime?
   • How would it work if I created a separate branch for each bug, and committed changes only to the right branch for each bug? So then, I would create a branch, fix the bug, commit it, push, pull request and checkout to my master branch to work on other bugs simultaneously? Would my organization know which branch to look for when I make pull requests?

Please suggest a workflow for my situation.

Answer 1

Now if I commit locally (in the same master branch), push it, make a pull request, and they take 3 weeks to review it, what should I do if I need to work on some other bug in the meantime?

That's easy - every change you do in a forked repository should be ONLY in its own branch. You should NEVER commit to any branches that you inherit from forked repositories (otherwise it will be painful for you to maintain them - to refresh with the latest changes from the upstream repository).

How would it work if I created a separate branch for each bug, and committed changes only to the right branch for each bug? So then, I would create a branch, fix the bug, commit it, push, pull request and checkout to my master branch to work on other bugs simultaneously? Would my organization know which branch to look for when I make pull requests?

That's it. When you make a pull request you choose what changes/branches to put into request

Answer 2

You should branch and submit the pull request from the branch. Because the pull request identifies the commit you are requesting to pull (and implicitly and different ancestors), it will pull the correct branch.

Personally, I double branch - one that will be used for the pull request and one that I do the work in. I'll then develop using multiple commits (as needed), then merge it down into a single commit (or several, depending on reviewer needs) in the first branch. That way I can develop freely, but the actual pull request only has a minimal number of commits within it.