Sylius/Symfony基于Git的版本控制流程及相关配置咨询

Hey there! As someone new to Sylius and Symfony, it makes total sense to have these questions—version control and environment setup can feel tricky at first. Let's walk through each one clearly:

1. What's the proper version control workflow for Sylius/Symfony? #

For most Sylius projects, a Git-based workflow works best, and you can adapt either Git Flow or GitHub Flow depending on your team's needs. Here's a simplified, practical breakdown tailored to Sylius:

• Start with a clean base: If you're building a custom project, initialize a Git repo locally first (or fork the official Sylius repo if you're contributing to core).
• Feature branches for development: Always create a new branch for every feature or bug fix, e.g.:

  git checkout -b feature/add-product-review-system
  git checkout -b fix/checkout-tax-calculation
  

• Commit early and often: Write clear commit messages that explain what you changed, then push your branch to your remote repo.
• Pull Requests (PRs) for review: Open a PR to merge your feature branch into your main development branch (like develop for Git Flow, or main for GitHub Flow). Have your team review it before merging.
• Tag releases: When you're ready to deploy to UAT or production, tag your commit with a version number (e.g., git tag v2.1.0) and push the tag to remote. This makes it easy to roll back if needed.
• Don't forget dependencies: Always commit your composer.lock file—this ensures every environment uses the exact same version of dependencies, avoiding "it works on my machine" issues.

2. I have a UAT server set up with Sylius. Should I create a Git repo from UAT, then install Sylius locally and pull the code? #

Great question—you've got the right idea, but the order is a bit off. Here's the correct step-by-step:

1. Initialize Git on your UAT server first: SSH into your UAT server, navigate to the Sylius project root, and run:

   git init
   

2. Configure .gitignore: Make sure you have a proper .gitignore (use the one Sylius provides as a base) to exclude files that shouldn't be tracked (we'll cover this in the next question).
3. Commit and push UAT code to a remote repo: Add all necessary files, commit, and link to a remote repo (like GitHub or GitLab):

   git add .
   git commit -m "Initial commit: UAT Sylius setup"
   git remote add origin https://your-repo-url.git
   git push -u origin main
   

4. Clone the repo locally: On your local machine, clone the remote repo instead of installing Sylius from scratch:

   git clone https://your-repo-url.git
   

5. Set up local environment: Run composer install to pull in dependencies, copy .env to .env.local and update your local database credentials, then run migrations and asset builds:

   cp .env .env.local
   # Edit .env.local with your local DB details
   php bin/console doctrine:migrations:migrate
   php bin/console assets:install web
   yarn install && yarn build # If using Encore
   

6. Optional: Sync UAT data: If you need UAT's database data locally, create a dump from UAT and import it into your local database instead of running sylius:install (which sets up fresh demo data).

3. Sylius comes with a .gitignore file—what files should I actually track? Should I ignore the /web/ directory, or only commit /app/? #

Sylius's default .gitignore is pretty solid, but let's clarify the key do's and don'ts:

Files/Directories to Always Track: #

• /app/ (or /config/ for newer Symfony/Sylius versions): Contains your routing, configuration, templates, and custom settings—this is core to your project.
• /src/: Any custom entities, controllers, extensions, or plugins you've built for your Sylius store.
• /migrations/: Database migration files—these ensure all environments have the same database schema.
• composer.json & composer.lock: Defines your project dependencies; composer.lock locks dependency versions for consistency.
• symfony.lock: (Symfony 4+) Locks Symfony component versions, similar to composer.lock.
• /bin/: Symfony console scripts needed to run commands.
• Parts of /web/: Don't ignore the entire /web/ directory! Track entry files like app.php, app_dev.php, and robots.txt—but let .gitignore handle dynamic stuff like /web/bundles/, /web/media/, and /web/uploads/ (these are generated or user-uploaded, so they don't belong in version control).

Files/Directories to Ignore: #

• /var/: Cache, logs, and session files—these are generated locally and shouldn't be shared.
• /vendor/: Dependencies installed via Composer—never commit this; others can install them using composer install.
• .env.local: Local environment variables (database passwords, API keys)—this has sensitive info, so keep it local.
• /web/media/ & /web/uploads/: User-uploaded product images, files, etc.—store these in a cloud service instead of version control, and back them up separately.
• IDE files: .idea/, .vscode/, etc.—specific to your local setup.

内容的提问来源于stack exchange，提问作者Code