Mantis Bug Tracker Developers Guide
Contributing to MantisBT
MantisBT uses the source control tool Git1 for tracking development of the project. If you
are new to Git, you can find some good resources for learning and installing Git in the
Appendix.
Initial Setup
There are a few steps the MantisBT team requires of contributers and developers when
accepting code submissions. The user needs to configure Git to know their full name (not
a screen name) and an email address they can be contacted at (not a throwaway address).
To set up your name and email address with Git, run the following commands, substituting
your own real name and email address:
$ git config --global user.name "John Smith"
$ git config --global user.email "jsmith[at]mantisbt.org"
Optionally, you may want to also configure Git to use terminal colors when displaying
file diffs and other information, and you may want to alias certain Git actions to shorter
phrases for less typing:
$ git config --global color.diff "auto"
$ git config --global color.status "auto"
$ git config --global color.branch "auto"
$ git config --global alias.st "status"
$ git config --global alias.di "diff"
$ git config --global alias.co "checkout"
$ git config --global alias.ci "commit"
Cloning the Repository
The primary repository for MantisBT is hosted and available in multiple methods depending
on user status and intentions. For most contributers, the public clone URL is
git://mantisbtmantisbt.git. To clone the repository, perform the following from your
target workspace:
$ git clone git://mantisbtmantisbt.git
If you are a member of the MantisBT development team with write access to the repository,
there is a special clone URL that uses your SSH key to handle access permissions and
allow you read and write access. Note: This action will fail if you do not have developer
access or do not have your public SSH key set up correctly.
$ git clone git[at]mantisbt.org:mantisbt.git
After performing the cloning operation, you should end up with a new directory in your
workspace, mantisbt/. By default, it will only track code from the primary remote branch,
master, which is the latest development version of MantisBT. For contributers planning to
work with stable release branches, or other development branches, you will need to set up
local tracking branches in your repository. The following commands will set up a tracking
branch for the current stable branch, master-1.2.x.
$ git checkout -b master-1.2.x origin/master-1.2.x
1
Chapter 1. Contributing to MantisBT
Maintaining Tracking Branches
In order to keep your local repository up to date with the official, there are a few simple
commands needed for any tracking branches that you may have, including master and
master-1.2.x.
First, you’ll need to got the latest information from the remote repo:
$ git fetch origin
Then for each tracking branch you have, enter the following commands:
$ git checkout master
$ git rebase origin/master
Alternatively, you may combine the above steps into a single command for each remote
tracking branch:
$ git checkout master
$ git pull --rebase
Preparing Feature Branches
For each local or shared feature branch that you are working on, you will need to keep it
up to date with the appropriate master branch. There are multiple methods for doing this,
each better suited to a different type of feature branch. Both methods assume that you have
already performed the previous step, to update your local tracking branches.
Private Branches
If the topic branch in question is a local, private branch, that you are not sharing with other
developers, the simplest and easiest method to stay up to date with master is to use the
rebase command. This will append all of your feature branch commits into a linear history
after the last commit on the master branch.
$ git checkout feature
$ git rebase master
Do note that this changes the commit ID for each commit in your feature branch, which
will cause trouble for anyone sharing and/or following your branch. In this case, if you
have rebased a branch that other users are watching or working on, they can fix the resulting
conflict by rebasing their copy of your branch onto your branch:
$ git checkout feature
$ git fetch remote/feature
$ git rebase remote/feature
Public Branches
For any publicly-shared branches, where other users may be watching your feature
branches, or cloning them locally for development work, you’ll need to take a different
approach to keeping it up to date with master.
To bring public branch up to date, you’ll need to merge the current master branch,
which will create a special "merge commit" in the branch history, causing a logical "split" in
Chapter 1. Contributing to MantisBT
commit history where your branch started and joining at the merge. These merge commits
are generally disliked, because they can crowd commit history, and because the history is
no longer linear. They will be dealt with during the submission process.
For more information about this article,please follow the link:
http://googleurl?sa=t&source=web&cd=1&ve...lopers.pdf&ei=S4q1TP7mHIqSuwO_5IGuCg&usg=AFQjCNHwpPPk8D6ACVHC7gUnIJNSg_evcg
