How to Keep a Copy of Your CodeCrafters Project on GitHub (While Still Pushing to CodeCrafters)

You’re working through a CodeCrafters challenge, making real progress, and suddenly realize something frustrating: all your work lives in a private remote repository that CodeCrafters controls. You want your progress on GitHub for your portfolio, for backup, or just to share with colleagues. But CodeCrafters requires you to push to their remote to validate each stage.

This is a common problem with a straightforward solution. If you want to mirror your CodeCrafters repo to GitHub or push CodeCrafters progress to GitHub while maintaining validation, Git supports multiple remotes. You can configure your repository to push to both CodeCrafters and GitHub with a single command. This guide shows you exactly how to set that up, explains why CodeCrafters works this way, and covers the tradeoffs of making your learning projects public.

Why CodeCrafters Uses a Private Remote

CodeCrafters validates your progress by monitoring commits to their remote repository. When you push code, their system runs automated tests against your implementation. This approach ensures you’re actually building the project rather than copying solutions.

The architecture requires their remote as the source of truth. They track which stages you’ve completed, provide feedback on test failures, and unlock subsequent challenges based on your progress. This validation system depends on having control over the repository state.

You can’t simply change the remote to GitHub because CodeCrafters won’t see your pushes. The solution requires maintaining both remotes: CodeCrafters for validation and GitHub for visibility.

The Two-Remote Setup

Git allows any number of remotes per repository. By default, CodeCrafters projects have one remote named origin pointing to their servers. You’ll add a second remote named github (or any name you prefer) pointing to your GitHub repository.

First, create a new repository on GitHub. Don’t initialize it with a README or any files since your local repository already has content. Note the repository URL, which looks like [email protected]:yourusername/yourproject.git for SSH or https://github.com/yourusername/yourproject.git for HTTPS.

In your CodeCrafters project directory, check your current remotes:

git remote -v

You’ll see something like:

origin  https://git.codecrafters.io/your-project-id (fetch)
origin  https://git.codecrafters.io/your-project-id (push)

Add your GitHub repository as a second remote:

git remote add github [email protected]:yourusername/yourproject.git

Verify both remotes exist:

git remote -v

Now you should see:

github  [email protected]:yourusername/yourproject.git (fetch)
github  [email protected]:yourusername/yourproject.git (push)
origin  https://git.codecrafters.io/your-project-id (fetch)
origin  https://git.codecrafters.io/your-project-id (push)

Push your existing work to GitHub. Note that CodeCrafters projects often use master as the default branch rather than main. Check your current branch with git branch and use the appropriate name:

git push github master

Or if your repository uses main:

git push github main

Your CodeCrafters project now exists on GitHub with your full commit history.

Working with Two Remotes

After initial setup, your workflow requires pushing to both remotes. The key principle: always push to CodeCrafters first to ensure validation happens before you mirror to GitHub.

When you complete a stage and want CodeCrafters to validate it, push to origin (using your actual branch name, typically master):

git push origin master

When you want to update GitHub, push to the github remote:

git push github master

This manual process works but requires remembering to push twice. For most learning scenarios, pushing to CodeCrafters after each stage and to GitHub once per session suffices.

If you want GitHub updated continuously, you can push to both remotes with separate commands. This ensures CodeCrafters validation happens first:

git push origin master && git push github master

The second push only executes if the first succeeds, ensuring CodeCrafters validates your work before GitHub shows it. This push order matters because CodeCrafters needs to see valid stage completions.

Automating Dual Pushes

Git provides two mechanisms for pushing to multiple remotes simultaneously: push URLs and aliases. Each has different tradeoffs.

Push URLs: Automatic but One-Way

You can configure the origin remote to push to multiple URLs:

git remote set-url --add --push origin [email protected]:yourusername/yourproject.git
git remote set-url --add --push origin https://git.codecrafters.io/your-project-id

After this configuration, git push origin main pushes to both remotes. However, this approach has a significant limitation: if either push fails, Git doesn’t clearly indicate which one. You might think your code reached CodeCrafters when only GitHub received it, or vice versa.

Additionally, git pull still fetches only from the original origin URL. This asymmetry can cause confusion about repository state.

Git Aliases: Explicit and Clear

A shell alias or Git alias provides more control. Remember to use your actual branch name (typically master for CodeCrafters):

git config --global alias.pushall '!git push origin master && git push github master'

Now git pushall pushes to both remotes sequentially. If the CodeCrafters push fails, the GitHub push won’t execute. The output clearly shows results from each remote.

You can also create a shell alias in your .bashrc or .zshrc:

alias gitpushall='git push origin master && git push github master'

This approach keeps push operations explicit. You still use git push origin master when you only want CodeCrafters validation, and gitpushall when you want both. The CodeCrafters push always happens first, which is critical for proper validation.

Public vs Private: Choosing Repository Visibility

Making your CodeCrafters project public on GitHub has benefits and tradeoffs worth considering carefully.

Public repositories increase portfolio visibility. Potential employers or collaborators can see your work, your commit history, and your problem-solving approach. For junior developers building portfolios, this visibility matters.

However, public repositories make solutions easily discoverable. Future CodeCrafters users can find and copy your implementations, reducing the learning value for them. CodeCrafters doesn’t prohibit sharing solutions, but the platform’s value comes from struggling through problems independently.

A middle-ground approach: keep repositories private until you complete the entire challenge, then make them public. This gives you portfolio credit while reducing the chance current users stumble upon solutions before attempting problems themselves.

Another option: make repositories public but add a prominent README explaining that these are learning exercises and encouraging others to attempt challenges before viewing solutions. This social pressure reduces but doesn’t eliminate solution copying.

Private repositories protect solution integrity but require GitHub Pro for unlimited private repos (free for students and many developers). If portfolio visibility matters less than having backups, private repos work well.

When This Setup Makes Sense

This dual-remote approach solves specific problems. Understanding when it applies helps you decide if the setup complexity is worth it.

You should set this up if you want your CodeCrafters projects in your GitHub portfolio, need backups beyond CodeCrafters’ systems, want to share progress with mentors or study groups, or plan to continue developing projects beyond CodeCrafters’ scope.

You probably don’t need it if you’re focused only on learning without portfolio concerns, you’re comfortable with CodeCrafters as your only backup, or you plan to make projects public only after completion rather than during development.

The setup takes about five minutes initially. The ongoing cost is remembering to push to both remotes, which automation can mitigate. For developers building portfolios or working in study groups, this cost is negligible compared to the benefits.

Alternative Approaches

The dual-remote setup isn’t the only way to preserve CodeCrafters work on GitHub. Alternative approaches trade automation for simplicity or timing.

You can complete the entire CodeCrafters challenge first, then create a new GitHub repository and push everything at once. This avoids dual-remote management during development but provides no incremental backup. If CodeCrafters’ servers have issues or your local repository corrupts, you lose work.

You can periodically export your project as a ZIP and commit it to a separate GitHub repository. This approach keeps CodeCrafters and GitHub repositories completely separate but loses Git history. Your GitHub repository shows large commits rather than incremental progress.

You can use Git’s mirror feature to create a complete replica after finishing. This preserves history but delays GitHub visibility until project completion.

Each approach optimizes different priorities. Dual remotes optimize for continuous visibility and backup. Post-completion push optimizes for simplicity. Periodic exports optimize for complete separation. Choose based on what matters most for your situation.

Practical Considerations

A few practical details that come up when managing this setup in real development.

Branch names matter. CodeCrafters projects typically use master as the default branch, while many GitHub repositories now default to main. Check your current branch with git branch and ensure your push commands reference the correct branch name. You can set up branch tracking to avoid specifying the branch explicitly in every push command.

Authentication varies by remote. CodeCrafters typically uses HTTPS with token authentication. GitHub supports both HTTPS (with personal access tokens) and SSH (with SSH keys). You might need different authentication methods for different remotes. SSH keys generally provide smoother experiences for GitHub.

Large files or binary assets can cause problems. If your CodeCrafters project includes large build artifacts or data files, consider adding them to .gitignore before pushing to GitHub. CodeCrafters might need certain build outputs for validation, but GitHub doesn’t.

If you’re working across multiple machines, clone from CodeCrafters initially to maintain their remote setup, then add GitHub as a remote on each machine. Cloning from GitHub first requires manually adding CodeCrafters as origin, which inverts the default setup and can cause confusion.

When to Push to Which Remote

Different scenarios call for different push strategies. Understanding when to use each remote helps maintain clean workflows.

After completing a CodeCrafters stage, push to origin immediately. This triggers validation and unlocks the next challenge. You don’t need to push to GitHub yet.

At the end of a working session, push to both remotes. This ensures GitHub has your latest progress for backup and visibility purposes.

Before switching machines, push to GitHub. If you’re moving from a desktop to a laptop, GitHub serves as the sync point. Pull from GitHub on the new machine, work, then push to both remotes.

When adding significant commits worth showcasing, push to GitHub immediately. If you just implemented a particularly elegant solution or solved a complex problem, make it visible in your portfolio right away.

For quick fixes or experimental work you might revert, push only to CodeCrafters. Keep GitHub clean of experimental branches that don’t add portfolio value.

Handling Merge Conflicts

If you’re working on the same project from multiple machines or collaborating with others, merge conflicts can occur between remotes. The dual-remote setup increases this risk slightly.

Before starting work, pull from both remotes (using your actual branch name):

git pull origin master
git pull github master

If GitHub has commits that CodeCrafters doesn’t (perhaps from work on another machine), resolve any conflicts before pushing to CodeCrafters. CodeCrafters’ validation requires clean history.

If you accidentally create divergent histories where both remotes have different commits, you’ll need to reconcile them. Typically, treat CodeCrafters (origin) as the source of truth since it tracks your challenge progress. Fetch from origin, merge into your local branch, then force push to GitHub if necessary:

git fetch origin
git merge origin/master
git push github master --force

Force pushing to GitHub loses any GitHub-only commits, so be certain you want to discard them. A safer approach: create a backup branch on GitHub before force pushing.

Additional Remote Management Commands

A few Git commands help manage multiple remotes effectively when you need more control.

Remove a remote if you no longer need it:

git remote remove github

Rename a remote if the name doesn’t fit your workflow:

git remote rename github backup

Change a remote’s URL if you recreate the GitHub repository or switch authentication methods:

git remote set-url github [email protected]:yourusername/newproject.git

Show detailed information about a specific remote:

git remote show origin

This displays the remote’s URL, tracked branches, and push/pull configuration. Useful for debugging when pushes don’t behave as expected.

Prune stale remote-tracking branches after deleting branches on the remote:

git remote prune origin

Need help setting up Git workflows, CI/CD pipelines, or developer productivity infrastructure? At ZirconTech, we help teams build robust development environments that support learning, collaboration, and delivery. Whether you’re building internal developer platforms or optimizing existing workflows, we bring AWS-certified expertise to developer tooling challenges. Let’s discuss your infrastructure needs.