Skip to content

Instantly share code, notes, and snippets.

@yarcowang
Last active October 13, 2015 09:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yarcowang/4173695 to your computer and use it in GitHub Desktop.
Save yarcowang/4173695 to your computer and use it in GitHub Desktop.
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 EADME.md file to introduce this project.
sample$ touch README.md
sample$ git add README.md
sample$ git commit -m 'add readme'
  • create gh-pages branch for github pages for future usage
sample$ git branch gh-pages

Branches

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]
 + rest-api/
[webservice]
 + 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 INSTALL.md
sample$ touch INSTALL.md
  • if release notes become large, you'd better to create a RELEASE.md
sample$ touch RELEASE.md
  • 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