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
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 aboutgit
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 aboutgit
, 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, andbug-$BUG_NUMBER
as our feature branches. Once you get to knowgit
, 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.
New projects for Mozilla websites should start in the Mozilla account.
Contact jbalogh
or jsocol
to be added to the webdev group of the Mozilla account. They hang out in #webdev on IRC, which is a fine place to ask for access when you start at Mozilla.
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 theorigin/master
git push
- 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 1234
somewhere in the summary.
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
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 theBugzilla API bugzilla-api
.git compare
with the appropriategit.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 appropriategit.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 <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!
Note:
bootcamp
is my active virtualenv.±
signifies that I'm in agit
repository.master
is the branch I am in.!
indicates that there are uncommitted things in my branch.
See bug-life
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 add remote 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
.