git clone https://github.com/hjdivad/ember-m3.git
cd ember-m3
yarn install
yarn run test
(Runsember try:each
to test your addon against multiple Ember versions)ember test
ember test --server
ember build
- Performance impact of changes is monitored by the perf-testing CI job, which uses the dummy performance testing app at
./m3-perf-testing-app
. The perf scenarios tested are described in the README. We keep the performance app dependencies up to date manually.
For more information on using ember-cli, visit https://ember-cli.com/.
Visit https://github.com/hjdivad/ember-m3 and click the "Fork" button. Use your favorite git client to clone your fork of the repository, or just head straight to the command line:
# Clone your fork to your local machine
git clone https://github.com/USERNAME/ember-m3.git
While this isn't an absolutely necessary step, if you plan on doing anything more than just a tiny quick fix, you'll want to make sure you keep your fork up to date by tracking the original "upstream" repository. To do this, you'll need to add a remote:
# Add 'upstream' repository to list of remotes
git remote add upstream https://github.com/hjdivad/ember-m3.git
# Verify the new remote named 'upstream'
git remote -v
Whenever you want to update your fork with the latest upstream changes, you'll need to first fetch the upstream repository's branches and latest commits to bring them into your repository:
# Fetch from upstream remote
git fetch upstream
# View all branches, including those from upstream
git branch -va
Now, checkout your own master branch and merge the upstream repository's master branch:
# Checkout your master branch and merge upstream
git checkout master
git merge upstream/master
If there are no unique commits on the local master branch, git will simply perform a fast-forward. However, if you have been making changes on master (it is recommended to make all changes on a bug/feature branch), you may have to deal with conflicts. When doing so, be careful to respect the changes made upstream.
Now, your local master branch is up-to-date with everything modified upstream.
Whenever you begin work on a new feature or bugfix, it's important that you create a new branch. Not only is it proper git workflow, but it also keeps your changes organized and separated from the master branch so that you can easily submit and manage multiple pull requests for every task you complete.
To create a new branch and start working on it:
# Checkout the master branch - you want your new branch to come from master
git checkout master
# Create a new branch named newfeature (give your branch its own simple informative name)
git branch newfeature
# Switch to your new branch
git checkout newfeature
Now, go to town hacking away and making whatever changes you want to.
If any commits have been made to the upstream master branch, you should rebase your development branch so that merging it will be a simple fast-forward that won't require any conflict resolution work.
# Fetch upstream master and merge with your repo's master branch
git fetch upstream
git checkout master
git merge upstream/master
# If there were any new commits, rebase your development branch
git checkout newfeature
git rebase master
It may be desirable to squash some of your smaller commits down into a small number of larger more cohesive commits. You can do this with an interactive rebase:
# Rebase all commits on your development branch
git checkout
git rebase -i master
This will open up a text editor where you can specify which commits to squash.
Once you've committed and pushed all of your changes to GitHub, go to the page for your fork on GitHub, select your development branch, and click the pull request button. If you need to make any adjustments to your pull request, just push the updates to GitHub. Your pull request will automatically track the changes on your development branch and update.
Sources