Split git repo in a squashed public and initial private

I want to open-source a project on Github.
There is quite a lot of commits (more than 2k) that I would squash into one "Initial commit" in order to start with a clean codebase and hide some historical stuff.

The question is, is it possible to:

• keep a private repo (on which there will be some secret keys, travis conf, ...) with all initial commits
• have a clean public codebase (all commits squashed into one)
• and work on the public repo and "merge" when needed on the private without any kind of conflicts ?

Thanks.

Solution 1:

You can do this very efficiently in your current repo:

Starting from:

# ...---o---H    HEAD, master

do

git cat-file -p master \
| sed '1,/^$/d' \
| git commit-tree HEAD^{tree} \
| xargs git branch public

to get

# ...---o---H    HEAD, master
#
#           H'   public  <-- H's exact content and commit message, no history

Then,

git merge -s ours public

# ...---o---H---I    HEAD, master   <-- gives later merges an accurate base
#              /
#           H''   public

git remote add public -t public its://u/r/l   # <-- '-t public` sets default push
git push public

and you're done.

(edit: added -t public safety play so you have to do something explicit to push non-public history)

Solution 2:

have a clean public codebase (all commits squashed into one)

Simply remove the current .git, git init, add everything and commit: 1 commit "squashing" everything else.

keep a private repo

Yes, you even have hosting services like Bitbucket providing with free private repos.

and work on the public repo and "merge" when needed on the private without any kind of conflicts

If you don't have any concurrent modifications, and merge should be either trivial or a fast-forward one.
It would be done in a local clone of the private repo, which will then be pushed to its private hosting server.

Solution 3:

I would recommend creating a new public git repo and copying all the relevant files into that new project (we'll call it "PUBLIC" for now). Do your initial commit to PUBLIC. This provides your starting point with no history for your public repo.

Once you have that, in the future, all your commits you want to be public should be committed to PUBLIC.

Your existing private repo can now set up a new remote that pulls from PUBLIC. Any changes you want to make that should end up in the public repo should be committed to PUBLIC and then merged into your private repo.