MantisBT 1.2 开发者指南：缺陷跟踪与协作

需积分: 9 87 浏览量更新于2024-07-28 收藏 377KB PDF 举报

"Mantis 1.2 缺陷跟踪系统开发者指南" Mantis Bug Tracker 是一个流行的开源缺陷跟踪系统，用于帮助软件开发团队管理和追踪项目中的问题和缺陷。本开发者指南由 Mantis BT 团队编写，旨在为开发人员和社区成员提供参考和文档资料，以了解和参与 Mantis Bug Tracker 的开发工作。指南的版权归属于 Mantis BT 团队，其发布日期为2012年8月21日。值得注意的是，该软件遵循"按原样"（AS IS）条款提供，不提供任何明示或暗示的保修，包括但不限于商品性和特定用途适用性。这意味着使用者在使用过程中如果遇到任何直接或间接的损害，包括但不限于替代品购买费用、数据丢失、利润损失或业务中断，开发者和版权所有者不承担责任。目录概述了以下内容： 1. 对于想要贡献于 Mantis BT 的开发者，指南首先介绍了初始设置： - 克隆仓库：这是获取 Mantis BT 源代码的第一步，通常通过 Git 进行。 - 维护追踪分支：这涉及到保持本地副本与远程主分支同步，以便获取最新更新并进行合并。 - 准备特性分支：在开发新功能或修复时，通常会创建新的分支，以保持主分支的稳定性。 2. 私有分支和公共分支：这部分可能涉及如何管理个人或团队的工作，以便在准备就绪后将更改合并回主分支。 3. 提交和拉取请求：开发者可能会学习如何提交代码变更到自己的分支，并发起拉取请求，以供其他团队成员审查和合并到主分支。 4. 测试和代码审查：在代码合并之前，测试和同行评审是确保质量的关键步骤。指南可能包含关于如何编写测试用例、执行自动化测试以及如何进行有效代码审查的指导。 5. 文档更新：随着代码的更改，相关文档也需要更新。开发者将了解到如何维护和更新 Mantis BT 的用户文档和开发者文档。 6. 版本控制和发布流程：开发者可能需要了解如何管理版本号，以及如何在准备好后发布新版本。 7. 社区参与：对于希望更深入参与 Mantis BT 社区的开发者，可能包含如何参与讨论、报告问题、提交补丁或建议改进的指南。 8. API 和扩展：Mantis BT 可能提供了API，允许开发人员构建自定义集成或插件，这部分会详细介绍如何利用这些接口。 9. 性能优化和调试技巧：指南可能包含有关如何优化 Mantis BT 性能和调试代码的建议。 10. 安全性最佳实践：由于 Mantis BT 处理敏感的项目信息，开发者需要遵循安全编码规范，以防止漏洞。通过此开发者指南，读者可以全面了解 Mantis Bug Tracker 的开发过程，从代码贡献到社区协作，从而提升其对项目的贡献能力。

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.

$ git checkout feature

$ git merge master

At this point, you can push the branch to your public repository, and anyone following

the branch can then pull the changes directly into their local branch, either with another

merge, or with a rebase, as necessitated by the public or private status of their own changes.

Running PHPUnit tests

MantisBT has a suite of PHPUnit tests found in the tests directory. You are encouraged

to add your own tests for the patches you are submitting, but please remember that your

changes must not break existing tests.

In order to run the tests, you will need to have the PHP Soap extension , PHPUnit 3.4 or

newer

and Phing 2.4 or newer

installed. The tests are conﬁgured using a bootstrap.php

ﬁle. The boostrap.php.sample ﬁle contains the settings you will need to adjust to run all

the tests.

Running the unit tests is done from root directory using the following command:

$ phing test

Running the SOAP tests

MantisBT ships with a suite of SOAP tests which require an initial set up to be executed.

The required steps are:

• Install MantisBT locally and conﬁgure a project and a category.

• Adjust the bootstrap.php ﬁle to point to your local installation.

• Customize the config_inc.php to enable all the features tested using the SOAP tests.

The simplest way to do that is to run all the tests once and ajust it based on the skipped

tests.

Submitting Changes

When you have a set of changes to MantisBT that you would like to contribute to the

project, there are two preferred methods of making those changes available for project

developers to ﬁnd, retrieve, test, and commit. The simplest method uses Git to generate

a specially-formatted patch, and the other uses a public repository to host changes that

developers can pull from.

Formatted patches are very similar to ﬁle diffs generated by other tools or source control

systems, but contain far more information, including your name and email address, and

for every commit in the set, the commit’s timestamp, message, author, and more. This

formatted patch allows anyone to import the enclosed changesets directly into Git, where

all of the commit information is preserved.

Using a public repository to host your changes is marginally more complicated than

submitting a formatted patch, but is more versatile. It allows you to keep your changesets

up to date with the ofﬁicial development repository, and it lets anyone stay up to date

Chapter 1. Contributing to MantisBT

with your repository, without needing to constantly upload and download new formatted

patches whenever you change anything. There is no need for a special server, as free host-

ing for public repositories can be found on many sites, such as MantisForge.org

, GitHub

or Gitorious

Via Formatted Patches

Assuming that you have an existing local branch that you’ve kept up to date with master

as described in Preparing Feature Branches, generating a formatted patch set should be

relatively straightforward, using an appropriate ﬁlename as the target of the patch set:

$ git format-patch --binary --stdout origin/master..HEAD > feature_branch.patch

Once you’ve generated the formatted patch ﬁle, you can easily attach it to a bug report,

or even use the patch ﬁle as an email to send to the developer mailing list. Developers, or

other users, can then import this patch set into their local repositories using the following

command, again substituting the appropriate ﬁlename:

$ git am --signoff feature_branch.patch

Via Public Repository

We’ll assume that you’ve already set up a public repository, either on a free repository

hosting site, or using git-daemon on your own machine, and that you know both the public

clone URL and the private push URL for your public repository.

For the purpose of this demonstration, we’ll use a public clone

URL of git://mantisbt.org/contrib.git, a private push URL of

git@mantisbt.org:contrib.git, and a hypothetical topic branch named feature.

You’ll need to start by registering your public repository as a ’remote’ for your working

repository, and then push your topic branch to the public repository. We’ll call the remote

public for this; remember to replace the URL’s and branch name as appropriate:

$ git remote add public git@mantisbt.org:contrib.git

$ git push public feature

Next, you’ll need to generate a ’pull request’, which will list information about your

changes and how to access them. This process will attempt to verify that you’ve pushed

the correct data to the public repository, and will generate a summary of changes that you

should paste into a bug report or into an email to the developer mailing list:

$ git request-pull origin/master git://mantisbt.org/contrib.git feature

Once your pull request has been posted, developers and other users can add your pub-

lic repository as a remote, and track your feature branch in their own working repository

using the following commands, replacing the remote name and local branch name as ap-

propriate:

$ git remote add feature git://mantisbt.org/contrib.git

$ git checkout -b feature feature/feature

If a remote branch is approved for entry into master, then it should ﬁrst be rebased

onto the latest commits, so that Git can remove any unnecessary merge commits, and cre-

ate a single linear history for the branch. Once that’s completed, the branch can be fast-

forwarded onto master:

剩余38页未读，继续阅读

HoneyMoose

粉丝: 1651
资源: 271

MantisBT 1.2 开发者指南：缺陷跟踪与协作

Mantis操作手册.doc

Mantis搭建和管理帮助文档

mantis工具使用PPT培训.ppt

利用mantis进行缺陷管理

如何安装使用mantis

软件质量保证与测试对常见的在线缺陷管理工具分别进行介绍

xampp和mantis的使用

mantis api

常见的bug管理工具

软件质量保证与测试对常见的在线缺陷管理工具分别进行介绍，以表格的形式

最新资源