Bugzilla:Git: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Add category)
(Updating some URLs to match reality, and updating tag name to match new best practice.)
Line 1: Line 1:
The Bugzilla Project uses the [http://git-scm.com/ git] Version-Control System. You can see the contents of the Bugzilla git repository at [http://git.mozilla.org/bugzilla/bugzilla/].
The Bugzilla Project uses the [http://git-scm.com/ git] Version Control System. You can see the contents of the Bugzilla git repository on [http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=summary Mozilla's git server].


= Checking Code Out of git =
= Checking Code Out of git =
Line 5: Line 5:
The simplest way to get the latest Bugzilla development code is:
The simplest way to get the latest Bugzilla development code is:


   git clone http://git.mozilla.org/bugzilla/bugzilla
   git clone https://git.mozilla.org/bugzilla/bugzilla.git


That will clone the Bugzilla git repository into a directory called "bugzilla" and will checkout the "master" branch.
That will clone the Bugzilla git repository into a directory called "bugzilla" and will check out the "master" branch.


If you want other branches, in the bugzilla directory simply checkout another branch:
If you want other branches, in the bugzilla directory simply checkout another branch:
Line 14: Line 14:
   git checkout 4.2
   git checkout 4.2


That will switch the files in the working directory to latest commit to the 4.2 branch.
That will switch the files in the working directory to latest commit on the 4.2 branch. Note that this doesn't necessarily correspond to the latest release in that series; additional patches may have been checked in since.


== Getting A Specific Release ==
== Getting A Specific Release ==
Line 20: Line 20:
Every time we release a version of Bugzilla, we tag the git repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:
Every time we release a version of Bugzilla, we tag the git repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:


   git checkout bugzilla-4.1.3
   git checkout release-4.1.3


That will switch the files in the working directory to the commit released as version 4.1.3.
That will switch the files in the working directory to the commit released as version 4.1.3.

Revision as of 13:29, 29 November 2014

The Bugzilla Project uses the git Version Control System. You can see the contents of the Bugzilla git repository on Mozilla's git server.

Checking Code Out of git

The simplest way to get the latest Bugzilla development code is:

 git clone https://git.mozilla.org/bugzilla/bugzilla.git

That will clone the Bugzilla git repository into a directory called "bugzilla" and will check out the "master" branch.

If you want other branches, in the bugzilla directory simply checkout another branch:

 cd bugzilla
 git checkout 4.2

That will switch the files in the working directory to latest commit on the 4.2 branch. Note that this doesn't necessarily correspond to the latest release in that series; additional patches may have been checked in since.

Getting A Specific Release

Every time we release a version of Bugzilla, we tag the git repository so that the point in history that matches with that release can be explicitly checked out of the repository. For example, to check out Bugzilla 4.1.3, you would do:

 git checkout release-4.1.3

That will switch the files in the working directory to the commit released as version 4.1.3.

You will usually get a warning here about being in a "detached HEAD" state; this is fine unless you'll be modifying the code in your installation, at which point you should create a local branch to preserve your change history.

To see a list of all the tags available do

 git tag

Updating to a Newer Release

No local changes

If you have no local changes to any tracked files, upgrading to both minor and major releases is simple:

 git fetch
 git checkout bugzilla-(version)

where (version) is the version number that you want to update to, like 4.4.2.

Local, uncommitted changes

The above checkout command will fail if you've made any modifications to files you checked out from git with a warning about overwriting local changes. In this case, the simple solution is to stash and then reapply your changes (assuming you've done the "git fetch" already):

 git stash save
 git checkout bugzilla-(version)
 git stash apply

However, it is better to create a local branch, which is one of git's strengths. You can track your customizations and merge in changes from upstream.

Local branch

...

Creating patches with git

Checking in using git

See Bugzilla:Committing_Patches.

Writing Patches On Top of Other Patches