GIT usage for tracking a remote project, but keeping local changes private.

Question

At work we contribute to an open source project using git, as well as keep local proprietary changes (we also license it). And what I'd like to do is setup a bare repository that is a clone of the upstreams repo. Our developers would then clone from this and push back to it using more of a cvs/svn development model - if Joe is working on something in branch, then leaves, we'd just like Hank to take over by checking out the branch.

What I'm confused about is the best to way to track the remote repo. Should the master of our internal bare repo be the copy of the master from upstream? Or should we put it on another branch. Also, since our shared repo is bare, how do we go about pulling in the latest changes from upstream? If I'm correct, I'd add upstream as a remote to my personal checkout, pull it, then push it back to our shared repo?

If possible we'd like to limit the users that could pull in the upstream changes to the shared repo, but all developers should have free access to work on other branches in the shared repo.

Am I having svn influence me too much in how I'd like our git repo to work?

Thanks.

Answer 1

My advice is to use a CI server like git. Hudson for example has a plugin which allows to merge all branches, build and test it and push it to master when everything is green.

You can also run arbitrary commands, so you could have a dependent project which is triggered after a successful buid to push the external master to the internal repo on a branch.

You can then decide to manually merge this branch or have another hudson job merge it and push it to your internal master when green.

Answer 2

I suggest the following:

• UPSTREAM'S GIT (aka upstream) branches:
  • master
• COMPANY'S SHARED REPO (aka companygit) branches:
  • proprietary: the company's development branch
• LOCAL GIT REPO branches:
  • upstream_master: tracks upstream/master
  • proprietary: tracks companygit/proprietary

So a new worker would git clone companygit to his computer, then add upstream (git remote add) and pull _upstream_master_ branch from there. Locally he'd have _upstream_master_ branch which tracks upstream/master remote directly (companygit shouldn't really care, I believe), and proprietary branch, which follows the companygit's branch.

Once in a while, he could 'git pull upstream_master', checkout proprietary, and then 'git merge upstream_master' (pray for no conflicts :) ), to incorporate the new upstream commits, and then push to companygit.

In order to push your specific updates to upstream, I'd be using 'git cherry-pick' for each relevant commit.

Answer 3

Here's one solution: have a non-bare repository somewhere that has remotes to both your internal central repository, and the upstream master. You can then have a cron job that does 'git pull upstream master; git push internal master:upstream'. This will pull the upstream code, then update the 'upstream' branch on your internal server with the new code.

From there, everyone can just pull upstream, along with two other tags -- maybe 'published' and 'internal' or something? -- that represent the work you're doing internally, all from the central repo. If you make sure anything to be published ends up on the published branch, you can then push that up to github or something for the upstream folks to merge in if they want. Generally speaking, you will then have someone periodically merge the upstream into published and the published into internal so that upstream changes get propagated properly.