First, you'll have to decide what you want to do with your project:
* [Option 1: Start a new project on your own](/installation/from-source#option-1-installation-for-new-projects)
* [Option 2: Contribute back patches to SilverStripe](/installation/from-source#option-2-installation-for-contributions)
These options aren't very clear cut, you can mix-and-match approaches to suit your needs
(e.g. core modules are downloaded as files, but your own modules are still managed through `svn:externals`).
### Requirements ###
* A **git client** to check out the core repositories, see ["Getting started with Git and Github"](http://help.github.com/).
* A **webserver+database environment** to run SilverStripe (see [server requirements](/misc/server-requirements)).
* The **php commandline utility** (to run scripts in the `tools/` folder)
* (optional) **Piston** ([website](http://piston.rubyforge.org)): A thirdparty tool to manage files from an external repository. It is our recommended way to start your own project, and still provide an easy way to update from our repository. You will need Ruby and the ["Rubygems"](http://rubygems.org/) package manager to install it: `gem install piston`
Note for Windows users: The installation process assumes a Linux/Unix/OSX system.
Most commands are the same for Windows, but you will have to use the `*.bat` scripts instead for anything in the `tools/` folder
(e.g. `tools/new-project.bat` instead of `tools/new-project`).
<divclass="warning"markdown="1">
Scripts in the `tools/` folder are still under development and might change over time.
</div>
## Option 1: Installation for new projects ##
Your own projects are typically hosted in a version control system of your choice,
with SilverStripe files copied or linked into that repository. We assume you already
have an empty repository set up, either in git or subversion.
If you don't use version control, we recommend that you stick to the official [silverstripe.org/download](http://silverstripe.org/download) instead.
### Step 1: Getting the installer
* Create a new project repository in your own version control (we assume the working copy folder is called `my-silverstripe-project/`)
* Download and extract silverstripe-installer [master](https://github.com/silverstripe/silverstripe-installer/zipball/master)
or the [latest release](https://github.com/silverstripe/silverstripe-installer/zipball/2.4).
Now you can learn how to [update your fork](http://help.github.com/forking/) from the `upstream` repository. You should do this regularly, at least before submitting any pull requests.
Please read ["Module installation"](/topics/modules) to find out how to install additional modules like `blog` or `forum`.
### Step 3: Committing the modules ###
You don't need to commit the module code into the repository, as our project is only for local development.
Changes within the module code are committed back directly to their own repository, not into the `installer` project. To the `installer` project, these modules are unversioned files (although you can explicitly add them to `.gitignore` as well).
By default, the "master" is checked out, which contains the latest code.
You can optionally select a ["release branch"](https://github.com/silverstripe/silverstripe-installer/branches) to work on. Any work happens on a local branch, that you have to create first:
You can't switch branches if your working copy has local changes (typically in `mysite/_config.php`).
Either revert these changes before switching, or temporarily store them with `git stash`.
Once you switch back you can retrieve these changes via `git stash pop` (see further [instructions on `git stash`](http://progit.org/book/ch6-3.html)).
### Step 5: Running the web-based installer ###
You can now run through the web-based installer for your operating system of choice ([instructions](/installation)).
## Updating from source ##
The `tools/` scripts provide an easy start, but don't allow you to add, remove or update modules.
Please read the following instruction on how to udpate modules and the installer depending
on your setup.
### Updating the installer ###
If you've done a straight `git clone` as described above, the update process is very simple:
cd my-silverstripe-project/
git pull origin
If you have copied the installer files into a new project, we recommend to repeat the copying process manually.
### Updating modules via git ###
In case you chose the "Installation for contributions" option, all modules in your project
will be standard git repositories, and you can update them as usual.
cd my-silverstripe-project/sapphire
git pull
### Updating modules via piston or download ###
For the "Installation for a new project" option, modules like `sapphire` or `cms`
are added as plain files without a direct link to their originating repository.
If these plain files are managed by piston, the update process is simple:
cd my-silverstripe-project
piston update sapphire
# Use "svn" instead of "git" for subversion repositories
See [piston.rubyforge.org](http://piston.rubyforge.org/import.html).
## Frequently Asked Questions ##
* **I'm not a big fan of git, can I use Subversion for my own projects?**: Of course, you can manage your own project files any way you want.
To get SilverStripe modules from version control, you will have to use git to check out the code, and then add it to your own version control.
* **Can I use svn:externals?**: If your project is hosted on subversion, you can add your own svn:externals as usual.
To include most SilverStripe modules and themes from github, you have two options: Copying the files directly into your
own version control, or use ["piston"](http://piston.rubyforge.org) to manage this for you.
* **Some modules I use are still in subversion, can I mix and match with git?**: Yes, through ["piston"](http://piston.rubyforge.org).
* **I've cloned a module repository and now I want to make changes to it (that shouldn't go into the main version)**:
You can either run `piston import` and then apply your changes to the imported source, or edit your "git remote" for those modules.
* **Why don't you use git submodules or subtree merging instead of piston?**: In our experience, [Git submodules](http://progit.org/book/ch6-6.html) only work well if used in a readonly way, not for committing to the submodule repository.