A lot dirty work will happen in the private repos while the public ones will probably only includes the key changes when it’s ready.

Here is a simple trick to setup a private git repo for private development while keep a public repo for releases.

Workflow

Initial Setup

Create two repos for public and private. Then we will mostly work on the private repos and you probably don’t even need to checkout the public repo.

# 1. Add your public repository as a remote
git remote add public https://github.com/yourname/public-repo.git

# 2. Create a disconnected 'public' branch
git checkout --orphan public

# 3. Clear the staging area and working directory to start fresh
git rm -rf .

# 4. Create an empty initial commit to start the history
git commit --allow-empty -m "Initial Public Release"

# 5. Push to the public remote
# (Note: Use --force if the public repo already has a README or other files)
git push -u public public:main

Releases

# 1. Switch to the public branch
git checkout public

# 2. Sync content from private main
#    (This makes your current folder look EXACTLY like 'main', handling all adds/deletes)
git read-tree -u --reset main

# 3. Commit the release
git commit -m "Release v1.0: Major update"

# 4. Push to the public repository
git push public public:main

# 5. Return to private work
git checkout main

Why bother?

Why not just copy paste and manage through the public repo?

• Zero Conflicts: You will never encounter a merge conflict. The git read-tree command effectively says, “I don’t care how we got here; just make the public files look exactly like the private files.”
• Clean History: Your public repository will show a professional, linear history (v1.0 -> v1.1 -> v2.0) while your private repository retains every detailed “WIP” commit.
• Total Privacy: Because the branches are orphans (unrelated), there is no link connecting your detailed private commits to the public repository.