发布于 2015-08-27 16:49:14 | 150 次阅读 | 评论: 0 | 来源: 网络整理
小技巧
Though this entry is specifically about Git, the same generic principles will apply if you’re storing your project in Subversion.
Once you’ve read through 创建页面 and become familiar with using Symfony, you’ll no-doubt be ready to start your own project. In this cookbook article, you’ll learn the best way to start a new Symfony project that’s stored using the Git source control management system.
To get started, you’ll need to download Symfony and get things running. See the 安装和配置Symfony chapter for details.
Once your project is running, just follow these simple steps:
Initialize your Git repository:
$ git init
Add all of the initial files to Git:
$ git add .
小技巧
As you might have noticed, not all files that were downloaded by Composer in step 1,
have been staged for commit by Git. Certain files and folders, such as the project’s
dependencies (which are managed by Composer), parameters.yml
(which contains sensitive
information such as database credentials), log and cache files and dumped assets (which are
created automatically by your project), should not be committed in Git. To help you prevent
committing those files and folders by accident, the Standard Distribution comes with a
file called .gitignore
, which contains a list of files and folders that Git should
ignore.
小技巧
You may also want to create a .gitignore
file that can be used system-wide.
This allows you to exclude files/folders for all your projects that are created by
your IDE or operating system. For details, see GitHub .gitignore.
Create an initial commit with your started project:
$ git commit -m "Initial commit"
At this point, you have a fully-functional Symfony project that’s correctly committed to Git. You can immediately begin development, committing the new changes to your Git repository.
You can continue to follow along with the 创建页面 chapter to learn more about how to configure and develop inside your application.
小技巧
The Symfony Standard Edition comes with some example functionality. To remove the sample code, follow the instructions in the “如何删除AcmeDemoBundle” article.
composer.json
¶Every Symfony project uses a group of third-party “vendor” libraries. One
way or another the goal is to download these files into your vendor/
directory and, ideally, to give you some sane way to manage the exact version
you need for each.
By default, these libraries are downloaded by running a composer install
“downloader” binary. This composer
file is from a library called Composer
and you can read more about installing it in the Installation
chapter.
The composer
command reads from the composer.json
file at the root
of your project. This is an JSON-formatted file, which holds a list of each
of the external packages you need, the version to be downloaded and more.
composer
also reads from a composer.lock
file, which allows you to
pin each library to an exact version. In fact, if a composer.lock
file exists, the versions inside will override those in composer.json
.
To upgrade your libraries to new versions, run composer update
.
小技巧
If you want to add a new package to your application, run the composer
require
command:
$ composer require doctrine/doctrine-fixtures-bundle
To learn more about Composer, see GetComposer.org:
It’s important to realize that these vendor libraries are not actually part
of your repository. Instead, they’re simply un-tracked files that are downloaded
into the vendor/
. But since all the information needed to download these
files is saved in composer.json
and composer.lock
(which are stored
in the repository), any other developer can use the project, run composer install
,
and download the exact same set of vendor libraries. This means that you’re
controlling exactly what each vendor library looks like, without needing to
actually commit them to your repository.
So, whenever a developer uses your project, they should run the composer install
script to ensure that all of the needed vendor libraries are downloaded.
You now have a fully-functional Symfony project stored in Git. However, in most cases, you’ll also want to store your project on a remote server both for backup purposes, and so that other developers can collaborate on the project.
The easiest way to store your project on a remote server is via a web-based hosting service like GitHub or Bitbucket. Of course, there are more services out there, you can start your research with a comparison of hosting services.
Alternatively, you can store your Git repository on any server by creating a barebones repository and then pushing to it. One library that helps manage this is Gitolite.