Question

I’m no git expert by any means, so I want to make sure the following flow is good:

1. Find a repo I want to contribute to. (original repo)
2. Fork the original repo on github. (my fork)
3. Clone my fork to my machine, outside of any project I’m working on. (isolated clone)
4. Include my fork as a submodule of a project I want to use it in. (submodule clone)
5. Create a feature branch on the isolated clone, and add some stuff.
6. Create another feature branch and other unrelated stuff.
7. Add the original repo as a remote to my isolated clone.
8. Rebase to the original repo.
9. Push and pull the two feature branches into my isolated clone‘s master.
10. Pull from the submodule clone that is in my project.
11. Submit pull requests to the original repo from each feature branch in the isolated clone.
12. Pull requests get accepted.
13. Rebase my fork‘s master branch to reflect the new master with my changes.

Any mistakes in there?

And then with that, what should I do with my feature branches on my local machine? Rebase them to my local master perhaps? Delete them (is that bad?)?

If they don’t accept my requests, I’d still like to merge them into my local master. Will that screw anything up?

I’m trying to figure out the flow that allows me to submit feature-based requests, but also use my changes in my project regardless of their acceptance, and my local copy straight after they’ve accepted / rejected them.

Lots to read, but thanks for any help!

Edit: Found this, related article a day after. Doesn’t answer to the complexity of my question, but still useful: http://codeigniter.com/news/contribution_guide#When:13:36:15Z

Answer 1

The submodule part complicates things a bit, but otherwise:

• 9: pull? you would push your two feature branche to your fork (the “isolated clone”), not pull them. That will save those commits on your remote repo.
  And actually, for a pull request, you should push one branch with all the commits you want to propose. See next point.
• 11: submit pull request: the idea behind a pull request is to propose fast-forward merges for the original project to include.
  So while you need to rebase the commits you want to include in your pull request on top of the branch (for instance master) that the original repo will have to update with your commits. For that, it is recommended to:
  • first pull from the original repo (to make sure master is up-to-date),
  • rebase your feature branches on top of master (again master is an example here) as one new branch (and test if your two new features initially developed in their own branch works together)
  • push that new branch to your fork
  • propose the commits of that new branch as pull request for master

As commented by koffie, a rebase is possible if you are the only one working on that feature branch (and a push --force is then possible).

If you want to contribute back to a project, you shouldn’t modify directly the history of commit of the branch you will contribute to: if you want to make a pull request to master of an original repo, you shouldn’t push anything to the master of your fork (except commits coming from a pull from the original repo)
You should always work in a dedicated branch.