Checklist to prepare Git repo for public release

Eliminating unnecessary (particularly large) files and removing needless historical development details are two significant parts of preparing a Git repo for public release. The general public users, even if of a limited group don’t need enormous amounts of code development history, probably littered with large files. Here are several straightforward steps to prepare code for public Git release.

1. Create an empty Git repo

GitHub is an obvious first choice, as GitHub has by far the largest number of users and excellent integration with third party tools. Bitbucket and GitLab are two worthy alternatives.

Create an empty Git repo at the website, then clone the empty repo you created to your computer.

git clone https://github.com/username/myrepo

Copy the files you want into the myrepo directory–we’ll clean up extra files next

2. Remove unneeded files

These commands are executed in the new myrepo directory you cloned, NOT your old directory. These commands assume a Bash terminal in Linux, Mac, Cygwin or Windows Subsystem for Linux.

Find the biggest directories in myrepo directory:

du -h | sort -h

To inspect biggest files within ~/mydir:

ls -h mydir | sort -h

Find binary files (non-text, non-code) recursively:

find . -type f | perl -lne 'print if -B'

Find and eliminate .DS_Store files (from MacOS):

find . -name .DS_Store

and then add .DS_Store to .gitignore

Sometimes it’s handy to remove or list all files EXCEPT those matching a pattern (inverse globbing):

shopt -s extglob

ls !(*inverse_pattern*)

Keep unwanted files out of the Git repo in the future by adding filename, directory names, and globbing patterns to .gitignore

3. Share and collaborate

When you’re confident things are ready, do

git add .

git commit -am "initial public release"

git push

and your files are on the Web for all.

Users will use GitHub Issues and Pull Requests to request and suggest code changes.

Instead of adding Collaborators, start by having people who want to make changes Fork and then Pull Request.

4. Ensure quality

Continuous Integration is vital to maintaining and improving code quality. Ask a code guru you know to help you get started with Travis-CI.