I have a Mandelbrot Set explorer project that I have hosted on GitHub. I used it to learn how to generate the Mandelbrot set, and to get more experience with using the Java ExecutorService. It works great, but I've just been tacking on new pieces as I go along, and it's becoming a mess. It's already broken twice after I made small changes to a small part of the code.

I decided that a complete rewrite is necessary, but obviously I want to keep the old messy, but working code. I've thought of 2 basic ways of going about this:

  • Start an entirely new project. I'd like to avoid doing this as the goal of the code is the same, and really, the end results should be the same. They're conceptually the same project.

  • Branch the old code off into a "messy-working" branch, start a new branch for the new attempt, then rebase into the new code.

I imagine the branching idea would work, but I don't have a ton of experience with Git.

Are there any pitfalls to creating a new branch of code that shares very little (if anything) with other branches? If this isn't a good idea, is there a better way of going about it?


If you are starting from scratch, it makes sense to start a new project. "I'd like to avoid doing this as the goal of the code is the same, and really, the end results should be the same" : Version control tools are not about the output of a program, but about the code. For example many Linux tools mimic exactly the behavior of closed-source Unix tools, and they don't share code.

In the other hand, version control systems and appropriate unit tests help you refactor the old, messy code into a new, clean code. Writing tests (which the old, messy code pass) and making sure that the refactored code passes them too, is like a safety net. If you decide to make this, then branching is a good option. The fact that the old code "works" great, makes tests written for it, a very good tool for validating the new, cleaner version.


The second option is technically the most correct. In conversion projects, I typically have 2 copies of the repository. The first copy is my current working code, and I keep it for reference. The second copy is the new effort... even if it is a blank slate.

Hopefully, you'll find that with a little restructuring, you'll be able to keep a lot of the logic you already wrote.

This is the approach when converting working projects from one version of a framework to a newer, but incompatible version that has bug fixes. Unfortunately, sometimes the changes are so extensive that sections of my code need a massive rewrite (I'm looking at you AspNet Core and Identity framework). Sometimes the changes are very minimal.

To do the work, you need to create the branch. You can do that from GitHub or BitBucket, or you can do it from the command line:

git branch --set-upstream-to=origin new-mandelbrot

The above creates a new branch and keeps the remote connection so that changes on your local branch can be pushed when you are ready (--set_upstream-to=origin). The branch name is the last part of the command line (new-mandelbrot).

Once that's done, git will have already switched you to the new branch. You can delete files, etc. You might want to keep your .gitignore and Readme.md files, but deleting everything and commiting that change effectively restarts the clock.

As long as you don't make any changes to the working code, you can do a pull request and merge the new project back into the master branch and it will cleanly replace everything.

  • I'm not sure I want to refactor it though. It contains so much bulk from being a side project for awhile, I'd be spending a lot of time just figuring out "where to cut". I think starting from scratch would be the cleanest option. I've realized that simple Mandelbrot explorers really aren't that hard to make, and was planning on just having that project for the next couple of days. It would take longer to convert it than it would to just start over. With that in mind, is this still the better option? Jul 6 '17 at 17:37
  • You can still clean everything out and start over. I find having the original in a separate branch for reference is useful more often than not. You may not use the code directly, but all those lessons learned about how to deal with creaky parts of the APIs you are using are still there waiting for you to cherry pick from them. Jul 6 '17 at 17:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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