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.
Setup and Basics
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…
TODO: Add git code snippets for everything or link to the git docs
Workflow for Merging in peoples changes from their Git fork
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.
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
git remote add stage gitgithub.com: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.
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
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