Using Git to manage third party developers

Question

We're about to kick off a project in which we will customized a large opensource project. We will have to patch this existing project in a few different ways:

• theming: changing the look & feel, for which the changes will be mostly in one or a few new subdirectories in the existing project directory structure
• extensions: the existing project has a notion of extensions for which the code only touches one or a few new subdirectories in the project directory structure
• core changes: some small changes in the core of the existing project might be required (as few as possible)
• configuration changes: some changes to the existing file in the existing project might be required for example to register the new extension/themes

The existing project releases patches or new versions regularly, we would like to apply these patches and new versions (when it makes sense). We will use one or more 3rd parties to develop the theme and extensions.

I'm trying to figure out the best way to leverage Git to manage this project. We want the 3rd parties to release code on a regular basis (daily? weekly?) so we can monitor progress. Multiple 3rd parties might be developing code at the same time.

I have done a fair amount of research on Git but I'm not sure what the best approach is. I thought How to manage a Git "upstream" branch and related patches? was quite interesting and was wondering how to adapt this for our project.

Something like this?

• 'upstream' branch is existing project, new upstream patches applied to this branch
• one branch per theme or extension

Is the Git way to ask the 3rd parties to work off a clone of the main Git repository and to regularly create a pull request which I apply to the appropriate branch of the main repository?

Answer 1

Yeah. This is basically the 'forking' method of git workflow. You have a main repository which is read-only to all but a few chosen candidates. Anyone who wants to contribute forks it and commits code to their own fork. When they want to submit the code to main repo, they send a pull request which contains a list of their commits.

People with write access to main repo can then merge those pull requests which in layman's terms, downloads the commits from fork to the main repo.

A contributor will generally refer to main repo as upstream and their own fork as origin. But these are just the remote names which can be anything else too.

Check out the following article for a better explanation https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow