What is a good development strategy for working on a fork of discourse privately on Github

(Chris Barry) #1

This is more of a Git/Github question, but I thought I would ask it here in case any one is wondering the same thing.

I want to work on a fork of discourse privately for a while, before my idea is ready for making public. (An attempt to formalise debate online for making governmental decisions)

Github says I have to duplicate the repository, as you can’t make a public fork private.

In terms of me working on this duplicate, but pulling in changes from the core repo, how do I keep my fork/duplicate up to date? Is there a difference between the fork and the duplicate apart from the connection of the fork itself?

And does this break any licence issues?

(Sophie Alpert) #2

You won’t lose anything by not making your repo an actual fork of the original one. In git, you can still do something like

git remote add upstream git@github.com:discourse/discourse.git

and then

git pull upstream

to merge in the latest changes, etc.

IANAL but I believe the GPL’s only says that you need to include the source if you distribute the software to other people (so you couldn’t, for example, sell a binary version of your fork without providing the source as well). As long as you’re just running the forum on your own server, there shouldn’t be any issues.

(Lee Dohm) #3

The way I keep my forks up-to-date is by creating a second remote named official like so:

git remote add official https://github.com/discourse/discourse

From there, you can update your own copy by performing these commands:

git pull official master
git push

If there are changes that need to be merged, then you will have to do that between the pull and the push.

(Jason) #4

If you’re just going to be working on it by yourself you could always just fork into a public repository then just not push your commits back to GitHub until you want to make it public.

But there’s probably not a reason to fork instead of duplicate that I’m aware of unless you’re planning to be submit pull requests later. So long as you make the changes public before releasing your software there shouldn’t be any GPL violations.

(Ted Lilley) #5

As others have said, making a fork then working on your copy locally without pushing to github will keep your work private.

Alternatively, you can make your clone of the discourse repository into a private one on github thusly:

  • Create a private repo on github (let’s call it discourse)
  • git clone git://github.com/discourse/discourse
  • cd discourse
  • git remote rename origin upstream
  • git remote add origin git@github.com:you/discourse
  • git push -u origin master

This will tie your local repo to the private one for your default push/pull actions. You can still pull from the official discourse repo as “upstream” as others have mentioned.

The last thing to remember is to always do your development work in a branch (I use “develop” as a branchname). When you’re ready to push, checkout master and merge your work, then switch back. This way you never accidentally push work-in-progress, since the develop branch doesn’t exist on the remote repo. A secondary benefit of this model is that it makes pull requests to the upstream repo easier as well, should you ever want to submit one.

Switching between development and master example:

  • git checkout -b develop
  • work, work, work
  • git add .
  • git commit -m "Some work"
  • git checkout master
  • git merge develop
  • git push
  • git checkout develop
  • work, work, work