Skip to content

How the MooTools Dev Team Contributes

Jump to bottom
Thomas Aylott edited this page Jun 21, 2011 · 1 revision

First, and most important. Never force a push! git push -f
This will screw up the history of everyone following the project or forking.

Originally, development was handled on Subversion. Back then everyone would just commit their changes directly to the trunk.

  • Keep your master branch identical to the official fork’s master branch.
  • Make a personal branch for every new feature

Setup and Basics
—

  1. Create your own fork of MooTools Core
  2. Make changes locally, committing changes as you go.
  3. Push your changes to your fork
  4. Once your bug fix or feature or whatever is complete
    Create a new Tag and push it to your personal fork
  5. Always create specs for any new features or bug fixes

Working on Multiple Things at Once
—
Sometimes you can’t complete a single feature/bug/whatever in a single commit.
Sometimes you have to fix some other minor bug while you have unstable changes from some other part of the code.
The trick is to use a branch for each feature or any other set of multiple related commits.

Get into the habit of making a new local branch anytime you want to start working on anything.

Be sure to push all your branches to your personal fork on Github so that you can work on multiple computers and keep everything in sync.

Making your changes “Official”
—
The official branch of MooTools core must always be kept as stable as possible. So we want to avoid pushing any unfinished features or untested bug fixes into it.

Once you have a new feature that has been approved by the project lead…

  1. Pull changes from official/master
    • Your master branch should now be identical to the official/master branch
  2. Merge your new feature into your local master from its branch
  3. Make a new tag
  4. Push your new tag to your personal fork on Github
  5. Push your new tag to the official fork OR

    Send a pull request

TODO: Add git code snippets for everything or link to the git docs

How to Verify a Patch
--

Workflow for Merging in peoples changes from their Git fork
--

Note: Replace kassens with the name of whatever user you’re tracking.

Setup a fork as a git remote:
github track kassens if you have the github gem installed.
OR
git remote add kassens git://github.com/kassens/mootools-core.git

Grab all the history of your remote repo and create special local tracking branches
git fetch kassens

See a detailed log of the changes in their history that aren’t already in your history
git log -p master..kassens/master

Merge all their changes into your branch
git merge kassens/master

Merge in only a single change from their history
git cherry-pick b856f889069cf3f40222672472dd940ac2a5c4d3 replace with the actual code for the commit you want.

Push changes to your fork
git push origin master

Push changes to the mootools/mootools-core fork
git remote add stage gitgit.luolix.top:mootools/mootools-core.git@
You have to have been given commit access to this fork already.
git push stage master
NOTE: Never use the -f option when pushing to the main fork. This will goof up everyone else.

Branches
—

The master branch is for all stable version bug fixes. EG: if 1.2.1 is the latest stable release, then master contains all the stuff that should be going into 1.2.2 or 1.2.3.

All new major versions are developed in their own branch until they are released as stable. EG: if 1.2.3 is the latest stable release, then all development on 1.3 should happen in a 1.3 branch.

Clone this wiki locally