Git and Github
Unless you have a good reason you should be using
git and GitHub
for version control. One notable exception is many of our projects
rely on SVN for localizers. We'll be attempting to phase that out.
If you don't know
git or haven't used it in a team, fear not! There are
lots of awesome sites for git newbies. We recommend:
- Help.Github can help you get started with
gitregardless of your operating system. If you haven't used GitHub before, it's the perfect crash course. There's also some good info about
gititself. You can ignore the "deploy" section, as we have our own deployment process at Mozilla.
- Pro Git is probably the best
gitresource in existence. It covers pretty much everything you'd want to know about
git, so it's quite lengthy, but it's a great read to get to know the basics or to use as a reference. Pro Git is written by one of the developers at GitHub.
- There's a good list of git resources on StackOverflow. It lists tools, tutorials, reference guides, etc. A lot of handy stuff there.
Next time you start a project, use
git/GitHub! Working on a
project by yourself is a bit different than working with others, but
start with some basic
git commands (clone, branch, merge) and some of
the more wild stuff (multiple origins, rebasing, etc.) will make more sense.
Git Practices at Mozilla
- Read about the git-flow model. We work similarly to this at
Mozilla, except we use
masteras our development branch,
prodfor our production branch, and
bug-$BUG_NUMBERas our feature branches. Once you get to know
git, understanding how to use/manage branches effectively will allow you to keep different bug fixes and features in their own branches. This is really awesome, especially if regressions crop up!
- We use
git submodulefor our libraries. This git submodules explained article helps you understand how they work.
- We often use
git rebaseto combine and fix commits before merging to mozilla origin repositories. This helps code reviews and keeps commit history clean. GitHub has a good rebase article.
New projects for Mozilla websites should start in the Mozilla account.
jsocol to be added to individual projects
you want to have your way with. They hang out in #webdev on IRC,
which is a fine place to ask for access when you start at Mozilla.
GitHub has some service hooks that are helpful to Mozilla projects.
- Bugzilla - posts comments on bugzilla when commit messages reference a bug by id, and closes bugs when commit message says 'fix' or 'close'
- IRC - announces repository pushes in an irc channel
wenzel to get access parameters for the
Working on projects
In order to work on a project:
- Fork it into your own account (do not develop directly in
- Make a branch for your work
- Submit a pull request for review
- Merge your commit into
masterwhich should track the
- Place a link to the commit (as it appears in the origin repository) in the relevant bug.
- Follow these guidelines.
- Should begin with a 50 character summary, with details if needed below.
- Should contain
bug 1234somewhere in the summary.
Keeping master in sync
You will want to keep your local
master branch in sync. Typically
you will rebase your branches with your
master and ultimately you
will push your
Let's assume you've defined your
origin remote properly in GitHub.
E.g. for Zamboni.
You will want your
.gitconfig to have the following:
[branch "master"] remote = jbalogh merge = master rebase = true
Making life easier
In order to make life easier we maintain a repository of
git-tools. These are shell scripts or python scripts that commit
all kinds of magic.
Here's a sampling:
git herewill tell you the name of your branch, this is an excellent building block
git bugbranch $BUGNUMwill copy your current branch to an appropriately named bug branch. This uses the :ref:`Bugzilla API <bugzilla-api>`.
git comparewith the appropriate
git.configsettings will give you a Github compare URL for your branch (you'll need to push to Github on your own).
git urlwith the appropriate
git.configsettings gives you the last commit's URL on Github.
Put these in your path and then fork and make your own tools and share.
Oh My Zsh
Oh My Zsh <https://github.com/robbyrussell/oh-my-zsh> is an
excellent collection of zshell scripts that can make your zsh
environment amazing. It includes a collection of plugins, including
git and Github.
Some of these overlap with
git-tools. Additionally by using Oh My
Zsh you can easily display your current branch and it's dirtiness on
Here is my prompt:
dash@awesomepants in ~/Projects/bootcamp/the_code/docs (bootcamp) ± on master!
bootcampis my active virtualenv.
±signifies that I'm in a
masteris the branch I am in.
!indicates that there are uncommitted things in my branch.
Looking at someone's code
Sometimes you need to run someone else's code locally. If they've given you a pull request, or a commit hash this is what you need to do to see there code:
git remote add davedash firstname.lastname@example.org:davedash/zamboni.git git fetch davedash git co davedash/branch
- The above assumes that someone else was me.
- The first line defines a "remote". A remote is simply an alias to a repository.
- The second line fetches all my commit hashes that you don't already have. Usually this is just branches, and commits, but in theory it can be anything.
- In the third line I can check out your branch. If you just gave me
a commit hash I would do
git co $COMMIT_HASH.