I plan a complete rewrite of my project, using another framework etc. It would be nice to keep the old code including history for reference. What is the best way to do this, in order to avoid risk, confusion and surprises?

My idea is to create a new branch, replace there everything and get a basic "new" version running there, tag the last "old" master, and then merge the branch to the master. Does this sound reasonable?

  • 18
    This question appears to be about Git, not Github.
    – user253751
    Feb 27, 2016 at 22:56
  • If you don't plan on editing old code, just want it to easily take a look at you can use a tag. But tags are supposed to be immutable (but you can always delete, re-add).
    – Travis
    Feb 28, 2016 at 15:09
  • 2
    Create a new repository.
    – CodeGnome
    Mar 2, 2016 at 5:19

4 Answers 4


I vote for keeping everything in a single repository.

I would:

  1. Create a new branch to point to your old code
  2. Delete all the code and commit on master
  3. Start your rewrite on master.

This is how:

# checkout the master branch
git checkout master

# create a new branch so you can find the old code easily
git branch oldStuff-KeepingForReference

# push the branch to github
git push origin oldStuff-KeepingForReference

# You currently have the master branch checked out
# so now cd to the project root and start your rewrite: 
cd <your project root>
rm -rf *

# Create a commit of the delete
git add --all *
git commit -m "Fresh start"

# Start your rewrite
echo "Some changes" > file.txt
git add file.txt
git commit -m "This is the first commit of the rewrite"

Aside: You could also make a tag of the old legacy code, if you know you will never want to add any commits to it.

When you should create a new repository instead of doing this:

  • When your current repo is prohibitively large and cloning the repo is slow. You may want to consider using a new repo.

Unless there's a pressing reason to merge the rewrite and historical branches, I'd keep them separate. Create a new branch to keep the old code, do your rewrite in master, and keep them separated that way. That way you can always work with the old framework/implementation if the situation changes.


That's what orphaned branches are for.

git branch -m master new_branch       #rename the branch
git push origin new_branch:new_branch #push the old code
git push origin :master               #delete the origin/master branch containing the old code
git checkout --orphan master          #create a new orphane branch - master. The first commit made on this new branch will have no parents and it will be the root of a new history totally disconnected from all the other branches and commits.

echo foo > file.txt
git add file.txt
git commit -m 'init commit'
git push origin master

You might need to temporarily set the default branch to new_branch in Github since it displays master by default.


You could create a new branch in the current project, but it may be better to mark the repository as private then create a new one for your new code, that way you still have the old repository but there's no bloat from the obsolete work.

I suggest you take this approach instead of trying to later merge the branch back to master not only because you'll still have that bloat from the obsolete code, but also because there may be several frustrating merge conflicts by the time you're ready to do the pull. In order to avoid that it would be best to start off with a clear branch rather than merging two completely different ones together.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.