How to organize git workflow when I can't directly push to origin/master?

Question

I checked out a git project on which I want to work. I don't have push permissions so I will be submitting patches to the upstream maintainers. I want to create my own branch and collaborate with a few other people on that one branch. When the work is done I want to rebase my branch against the current head of the main project and send patch to upstream maintainers. The question is: how to organize collaboration between a group of people working on one branch?

Currently I use the following setup:

• I have my own git server on which I keep bare copy of the repo.
• I store my working branch on that server
• Other developers push their changes to that branch on the server and pull out changes made by others, so the server acts as a central repository for all people working on a branch
• Changes made to master are pulled from the upstream repo of the project.
• Master may be pushed to my server if needed

I thought this is a good setup but realized that everything will break if I ever decide to rebase my branch against the current master from the upstream. If I push rebased branch to my local server it will end up being a disaster for others, so obviously this is not a correct setup. I had discussion about this with my friend and he noted that the problem is caused by using my own local server as a central server for all developers, as if it was a subversion repository. So while I think we realized the source of our problem, we didn't come up with a correct way of organizing our git workflow. How this should be done?

Answer 1

Each of your co workers should create micro-branches [aka feature branches] (from your main branch; as should you) for each of their small iterations which they can push to your server at any time to allow them to be seen. As each micro-iteration is completed they (and you) would rebase that iteration on top of your main branch to see if it is still working and ready for integration with your main branch.

There is a race here to keep iterations short and small so that they 'just work' and are acceptable, and merged or fast forwarded into your main branch. In some cases the different iterations will interact and the appropriate developers can collaborate using the pushed/pulled micro branches to avoid in-fighting;-)

If there is a lot of cross running features in development then you can use a workflow ( git help workflows ) similar to that used by the Git maintainer, of Master <- Next <- pu (potential updates) <- contributor branches, with pu being rewound after every cycle with contributors pulling a fresh view of that re-wound branch to see how their changes fit into the larger whole.

---

Patch submission

Once you have a completed piece of work in your 'main' branch you should again fetch/pull the upstream master (and any release candidates they may have) and rebase your changes on top of them to truly be up to date.

Now you would prepare a patch series from your branch using git format-patch , most likely having prepared a cover letter to introduce the series. Then use git send-email to send them in. It is worth practising though by sending them to yourself, and looking up any instructions provided by the upstream project. For example Git's SubmittingPatches .