Skip to content
This repository
tree: 6c2edca6f0
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 184 lines (135 sloc) 6.284 kb

Git and Github

System Message: ERROR/3 (<string>, line 1)

Unknown directive type "index".

.. index:: git, 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.

Git Resources

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 git regardless of your operating system. If you haven't used GitHub before, it's the perfect crash course. There's also some good info about git itself. You can ignore the "deploy" section, as we have our own deployment process at Mozilla.
  • Pro Git is probably the best git resource 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.
  • Read about the git-flow model. We work similarly to this at Mozilla, except we use master as our development branch, prod for our production branch, and bug-$BUG_NUMBER as 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!

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 using the basics of git and some of the more wild stuff (multiple origins, rebasing, etc.) will make more sense.

github.com/mozilla

New projects for Mozilla websites should start in the Mozilla account.

Contact jbalogh or 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.

Working on projects

In order to work on a project:

  • Fork it into your own account (do not develop directly in origin)
  • Make a branch for your work
  • Submit a pull request for review
  • Merge your commit into master which should track the origin/master
  • git push
  • Place a link to the commit (as it appears in the origin repository) in the relevant bug.

Commit Messages

  • Follow these guidelines.
  • Should begin with a 50 character summary, with details if needed below.
  • Should contain bug 1234 somewhere 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 master to origin/master.

Let's assume you've defined your origin remote properly in github. E.g. for Zamboni.

origin      git@github.com:jbalogh/zamboni.git

You will want your .gitconfig to have the following:

[branch "master"]
    remote = jbalogh
    merge = master
    rebase = true

Making life easier

Git Tools

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 here will tell you the name of your branch, this is an excellent building block

  • git bugbranch $BUGNUM will copy your current branch to an appropriately named bug branch. This uses the :ref:`Bugzilla API <bugzilla-api>`.

    System Message: ERROR/3 (<string>, line 122); backlink

    Unknown interpreted text role "ref".

  • git compare with the appropriate git.config settings will give you a Github compare URL for your branch (you'll need to push to Github on your own).

  • git url with the appropriate git.config settings 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 ones for 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 your prompt.

Here is my prompt:

dash@awesomepants in ~/Projects/bootcamp/the_code/docs
(bootcamp) ±                                                    on master!

Where:

  • bootcamp is my active virtualenv.
  • ± signifies that I'm in a git repository.
  • master is the branch I am in.
  • ! indicates that there are uncommitted things in my branch.

Development Process

See :ref:`bug-life`

System Message: ERROR/3 (<string>, line 161); backlink

Unknown interpreted text role "ref".

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 git@github.com:davedash/zamboni.git
git fetch davedash
git co davedash/branch

Note:

  • 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.
Something went wrong with that request. Please try again.