Skip to content

Instantly share code, notes, and snippets.

@yarcowang yarcowang/gist:4173695
Last active Oct 13, 2015

What would you like to do?
Common Project Initialize Procedure

Common Project Initialize Procedure

This common style is for me in developer eye. You could also follow it by yourself.

Name a project

The very beginning thing is you need to name a project. It is really very important when starting a project. No name, then no project.

  • name should be in english, and should less than 20 characters
  • do not use space, prefer -
  • try use lowercase for all projects
$ mkdir sample
$ cd sample

Version control and Branches

Version control is important for versioning sources, but not to abuse it.

  • choose git as version control system, no doubt
  • use github as remote server, no doubt
sample$ git init
  • create a file to introduce this project.
sample$ touch
sample$ git add
sample$ git commit -m 'add readme'
  • create gh-pages branch for github pages for future usage
sample$ git branch gh-pages


If a project can be divided into several parts, for example: restapi, webservice,ui etc. Then you'd better to store them into seperated directories and branches.

I sugguest the structure could be:

[master] -- master branch holding everything
 + rest-api/ -- it is a directory and also a branch
 + webservice/ -- same
 + rest-api/
 + webservice/

Certainly there could be non-branch directory or non-directory branch.

Extra file

  • if install procedure is complex, you'd better to create a
sample$ touch
  • if release notes become large, you'd better to create a
sample$ touch
  • you may also include license
sample$ touch LICENSE.txt
  • you may also include version file for some purpose
sample$ touch VERSION

Extra directory

  • you may also create a docs/ directory for storing docs. things like tut/ for tutorial, api for api, examples/ for example should always be stored in this directory
  • you may create a test/ directory to store tests
  • you may create a proj/ directory to store project related files for user requirements docs etc (internal using)

Extra personal prefers (following *nix style):

  • bin/ for binary file
  • lib/ for library file
  • src/ for c/c++ source code
  • var/ for runtime usage file
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.