If you’re someone who regularly develops software, sites, or anything with any code, you’re going to start using source code control at some point.

And when a project ends, you’ve got options when it comes to maintaining the source code:

  • Perhaps you’ll hand the code over to the client, and you will retire it,
  • Or maybe you’ll continue to maintain it for the client as part of an ongoing relationship,
  • Or there’s a chance you’ll be done with the project but still want to hang on to the source code.

For me, I’m partial to the latter option primarily because I like to have an archive of the things I’ve worked on throughout my career (no matter how trivial they may be) and because I’m a bit of a packrat when it comes to things like this.

Because if a client ever comes back for future work on a project, then I want to be able to spin up a copy of the development environment so I can get back to work. This assumes that I have an archive of the source, though.

But this assumes I have a repository archive.

Create a Repository Archive

For those who are relatively new to source control, you may find this primer helpful. In short, source control software maintains a log of all of the work that you’ve done in some internal set of data so that you can track your changes, project history, and so on.

If you use Git and have your operating system set to display hidden files and folders or browsed a directory using a terminal or a command line, then you’ve likely seen the hidden git folder that resides in the root directory of your project.

Create a Repository Archive

For Git, this is where the software keeps all information about your project so that the source control system can track the project history. Other source control systems will do something similar.

When you export a project, you get a copy of the source code in the state that it’s in exactly when you export it except it does not include the directory and meta information about the history.

That is, it doesn’t include the git directory.

If you’re interested in, say, removing a project from GitHub or Bitbucket, but you still want to maintain the historical information of the project then I recommend creating a repository archive that includes the metadata and saving it.

This way, when it comes time to resume work on the project, you can unarchive the project and get back to work with the Git repository.

From the command line, navigate to the root of your project directory (for this example, assume that the project is called “acme”), and then issue the following command:

zip -r acme.zip acme/

Super simple, isn’t it? Technically, you could do this using a GUI in the file manager of your operating system, too. If you opt to use the command-line, zip has a lot of other options, too.

This will create a zip file in the root of the project. You can then take that file, save it wherever you archive your projects, and unarchive it whenever you’re ready to resume work on the project.


Join the conversation! 1 Comment

  1. Another option that I’ve been using is:

    git bundle create --all

    This creates a binary file that you can clone. The downside is that it won’t keep anything that wasn’t committed to the repo. If, like me, the bulk of uncommitted files in the repo directory is stuff like node_modules or composer vendor directory this works good. If you keep your source PSDs, then it’s not so hot.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.