-1

I have a project in Symfony2 which maintains several branches in Git: develop, testing and some other. The file composer.json is different on each branch so I need to run composer update all the time to update dependencies and/or delete old or new libraries which might cause unwanted behavior.

Right now I am learning and trying to write some tests using BDD: Behat + Mink and I don't want to have that changes on develop branch so I have created testing and made all those changes on that branch but as I said the main problem is to run composer update any time I switch branches.

Which is the right way to handle this? How would you do it? Any advice? I am getting crazy running the same command several times and then synchronizing my local code (Windows host) on PHPStorm against remote code (Linux server). Ideas?

ReynierPM
  • 17,594
  • 53
  • 193
  • 363

1 Answers1

1

A few different things come to mind. Some are more best practices, others may alleviate turnaround time, depending on how much effort you want to exert:

Basic:

  • On .lock down - Make sure each branch has a committed lock file. There's a reason its right in the Composer documentation. Too few projects seem to appreciate SemVer, and even those can let a breaking change sneak in from time to time.
  • Be Specific When running a composer update, make sure you're targeting the specific packages that differ between branches (ex: composer update doctrine/dbal).
    • Better yet, don't run update at all. This could be erroneously updating a package in a branch you hadn't intended to. Better to utilize composer install.
  • Why not both? - Might it also be worthwhile to just have a separate clone of your project dedicated to that branch? If you see yourself regularly working in both, spare the entire headache of toggling branches. After all, disk space is cheap.
    • Delete all branches from local except for the ones you're interested in. Setup Git Push/Pull to 'Simple' to avoid any accidental commits.

Moderate or Higher

  • Be lazy, go have some coffee - Consider a post-checkout hook. You can see here for an example. Enjoy the spare cycles to grab some coffee, map our your next test.
  • Roll Your Own - Install a local Satis instance. I've noticed a marked improvement in our project installs after our team added a local Satis instance w/ mirroring of our primary dependencies.
  • VM - Transition your project to use a VM. GUI-based tools such as PuPHPet or Phansible can ease you in to things. This won't solve your composer problem, but cutting down on the roundtrip with the remote for sync will likely be worth the time investment.
  • Config tweak - Change composer's vendor dir on a per-branch basis. See this previous answer for details.
    • Note: This has a high probability of adding some complications to your testing due to unexpected/branch-specific permissions errors, etc.
  • Platform.sh:
    1. Set up an account with Platform.sh
    2. ???
    3. Profit

Hopefully some combination of the above will help you find some improvements!

Community
  • 1
  • 1
ReservedDeveloper
  • 414
  • 3
  • 19