Mozillians Git-Fu
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Mozillians Git-Fu. | |
# Useful steps for moving around git branches and servers related to | |
# the Mozillians release process. Any dev should be able to do these | |
# in a pinch, there are no special privileges. | |
# Always assuming 'origin' refers to github.com/mozilla/mozillians.git | |
# Current branch is in () in my pseudo-prompt. | |
# HowTo: Cut a new 'next' branch. | |
# After tagging, we wipe out the current next branch and fork from | |
# the current master. Master never has to freeze, and next is stable | |
# for QA. | |
mozillians(master)$ git pull --rebase origin master | |
Already up to date. | |
mozillians(master)$ git branch -d next # If you have a local next branch, remove it. | |
mozillians(master)$ git checkout -b next # Create a new local next branch from master. | |
mozillians(next)$ git push -f origin next # Overwrite the current next on github. | |
# Tada! baconmatt should notify about the push and trigger the mozillians_next | |
# Jenkins build. Now all you need to do is file a bug to update -stage. | |
# HowTo: Tag a release. | |
# Once QA has signed off on -stage and all the bugs in a release, we can tag it | |
# in git for IT to deploy. After tagging, we can cut a new next branch, as above. | |
mozillians(master)$ git fetch origin | |
mozillians(master)$ git checkout origin/next # Optionally with -t. Your call. | |
mozillians((abcdefg1234))$ git tag YYYY-MM-DD # ISO dates FTW. | |
mozillians((YYYY-MM-DD))$ git push --tags origin | |
# Now IT has a tag ready to fetch and deploy! Yay! | |
# HowTo: Cherry-pick to next | |
# When QA is verifying a bug on -stage/next and finds an issue, or if | |
# a patch has to land after the train has left the -dev/master station | |
# (either because Product thinks it's critical, or we do, or...) we | |
# can catch up to the train by cherry-picking. | |
# Patches should *always* be written against master, and landed on | |
# master first, *unless* it's for a bug or issue that only exists on | |
# next. This is rare, but does happen. | |
# Once the pull req is r+d, and has landed on master (via the merge | |
# button or a fast-forward merge) the commit(s) should be cherry-picked | |
# to next, next pushed to github, and redeployed to stage. | |
mozillians(master)$ git branch -d next # Make sure your local next is up to date. | |
mozillians(master)$ git fetch origin | |
mozillians(master)$ git pull --rebase origin master | |
mozillians(master)$ git checkout -t origin/next # Create a local next branch. | |
mozillians(next)$ git cherry-pick <sha1> | |
mozillians(next)$ git push origin next # You shouldn't need to push -f here. | |
# Woot! Now file an IT bug to redeploy next to stage. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment