Managing Multiple Apps from a Single Git Repo

Last Updated October 2014

Running multiple apps from a single repo can really come in handy, especially when using dev, QA, staging, production, etc. phases in your development workflow. It's really simple to do on Pagoda Box, requiring only a minor adjustment to your Git workflow. This doc walks managing multiple apps from a single Git repo. After reading it, you should be familiar with:

  • Managing Multiple apps from a single Git repo
  • Things to know when working this into your workflow

Things to Know

There are a few things to know when managing multiple apps from a single Git repo. They're pretty simple, but still important to understand.

Every App Has a Unique Clone URL

Every app has its own repo on Pagoda Box, each with a unique Git clone url. The clone url is necessary when adding Git remotes. Your app's Git clone url can be found under the "Admin" tab of your app dashboard.

Adding Git Remotes Terminal

  # Pattern
  $ git remote add [remote_name] [git_clone_url]
  # Example 1
  $ git remote add pagoda
  # Example 2
  $ git remote add staging

Each App Should Be Added as a Separate Git Remote

To push a single repo to multiple apps, each app must be added as a unique Git remote. Simply use the pattern explained above to add remotes to your local repo.

Only the Master Branch Will Deploy

When pushing to Pagoda Box, only the "master" branch will deploy. If you're working on a branch other than master, it's possible to push to the master branch of your remote repo with a simple addition to your git push command. The example below shows how to push your local "staging" branch to the remote "master" branch.

Pushing a Local Branch to the Remote Master Branch Terminal

  # Pattern
  $ git push [remote_name] [local_branch]:[remote_branch]
  # Example
  $ git push pagoda staging:master

Workflow for Staging & Production Apps

It's a common practice to have multiple test apps setup for different phases of the app development process (dev, staging, QA, production, etc.). This process becomes especially easy when combining the functionality of Git and Pagoda Box.

Each Development Phase Should Have Its Own App

To test changes in isolation in a live environment, we suggest creating applications for each phase of your development cycle. For example, a development app, a staging app, a production app, etc. Each will have their own unique remote repos and clone urls.

Use Git Branches to Isolate Development Phases

We recommend using Git branching to isolate changes made within each phase of the development process. This allows you to develop on a branch other than master. Then, when changes are tested and proven production-ready, they can be merged into master and pushed to your production app.

Workflow Example

Below is an example workflow for a development cycle. Assume two applications have already been created, each devoted to a specific phase of the dev cycle. The names of the apps are "staging-demo-app", and "prod-demo-app." "Feature x" is being developed, tested, then pushed into production.

Example Development Workflow Terminal

  #Add a remote for each app
  $ git remote add production
  $ git remote add staging
  #Master will be used as the production branch
  #Add a staging branch to the repo
  $ git branch staging
  #Checkout the staging branch
  $ git checkout staging
  #Make changes, add and commit them to the staging branch
  $ git add .
  $ git commit -m 'developing feature x'
  #Push and deploy the staging branch to the staging remote
  $ git push staging staging:master
  #Confirm changes are good
  #Switch to the master branch and merge in changes from staging
  $ git checkout master
  $ git merge staging
  #Push merged changes to the production remote
  $ git push production master

If you have any questions, suggestions, or corrections, let us know.