You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
train07 edited this page Feb 6, 2012
·
6 revisions
There are multiple different Git branches that you'll be working with. Here's a quick guide to managing them!
Stable
Stable should never be coded in, except for 1 case: hotfixes. When you have a bug that needs to be fixed quickly, it's faster to code directly in stable and deploy from there. Make sure that you never break stable - it's your only hope, young padawan.
Therefore, only the Git Admin is allowed to code within stable. (Fraser for now)
Whenever a code change is made in stable, it always needs to be merged down into master.
Tips: On stable,
git push origin stable
git checkout master
git merge stable
-- Sort through conflicts --
git commit -a (Use default message)
git push origin master
When you feel that code in master is ready to go live, do the following steps:
git checkout master (switch to master)
git pull origin master (get all updates)
-- DEPLOY FROM MASTER --
You don't want to pollute stable incase anything is broken. Watch the logs for a day or so. If everything looks good, select the commits you deployed live and merge them into stable. DON'T FORGET TO MERGE THESE COMMITS INTO STABLE!
Master
No one should ever code in Master - EVER.
Personal Branches
Everyone should code in personal branches to keep their changes separate. When a feature has been completed and thoroughly tested, they can submit a GitHub Pull Request to merge it into master.