本节介绍如何开始使用QgisGit存储库。在这样做之前,首先需要在系统上安装一个Git客户端。
这个 git project 有一个可下载的git版本。确保获得与您的处理器匹配的软件包(最有可能的情况是,只有第一台Intel Mac需要i386软件包)。
下载后,打开磁盘映像并运行安装程序。
PPC/源注释
Git网站不提供PPC版本。如果您需要一个PPC构建,或者您只是希望对安装有更多的控制,那么您需要自己编译它。
Download the source from https://git-scm.com/. Unzip it, and in a Terminal cd to the source folder, then:
make prefix=/usr/local
sudo make prefix=/usr/local install
如果您不需要任何附加程序、Perl、python或tcltk(gui),可以在运行make之前禁用它们:
export NO_PERL=
export NO_TCLTK=
export NO_PYTHON=
要签出分支,例如2.6.1版分支,请执行以下操作:
cd QGIS
git fetch
git branch --track origin release-2_6_1
git checkout release-2_6_1
要签出主分支,请执行以下操作:
cd QGIS
git checkout master
注解
在QGIS中,我们将最稳定的代码保存在当前的发布分支中。master包含所谓的“不稳定”发布系列的代码。我们将定期从master中分支一个发布,然后继续稳定和选择性地将新特性合并到master中。
有关构建开发版本的具体说明,请参见源代码树中的安装文件。
如果您有兴趣查看QGIS文档源:
git clone git@github.com:qgis/QGIS-Documentation.git
您还可以查看文档repo中包含的自述文件以了解更多信息。
如果您有兴趣查看QGIS网站源:
git clone git@github.com:qgis/QGIS-Website.git
您还可以查看网站repo中包含的自述文件以了解更多信息。
在过去的几年中,qgis源代码的复杂性大大增加。因此,很难预测添加功能会产生的副作用。在过去,qgis项目有很长的发布周期,因为在添加了新特性之后,重新建立软件系统的稳定性是一项很大的工作。为了克服这些问题,qgis切换到一个开发模型,首先在git分支中对新特性进行编码,并在完成和稳定后合并到master(主分支)中。本节描述了QGIS项目中的分支和合并过程。
创建一个分支:为新特性的开发创建一个新的git分支。
git checkout -b newfeature
现在您可以开始开发了。如果您计划在该分支机构上做大量工作,希望与其他开发人员共享工作,并具有对上游回购的写访问权限,则可以通过执行以下操作将回购推送到QGIS正式回购:
git push origin newfeature
注解
如果分支已经存在,您的更改将被推送到它中。
定期转主:建议定期将主变更合并到分支机构。这使得以后将分支合并回master更容易。在一根钢筋之后,你需要 git push -f
到你的分叉回购。
注解
从未 git push -f
到原始存储库!仅用于您的工作分支。
git rebase master
当您完成新功能并对稳定性感到满意时,在开发人员列表上发布公告。在重新合并之前,开发人员和用户将测试这些更改。
有一些指导原则可以帮助您轻松获取补丁并将请求拉入QGIS,并帮助我们处理发送到易用的补丁。
一般来说,如果您提交Github Pull请求,开发人员就更容易接受。我们这里不描述拉取请求,而是将您推荐给 GitHub pull request documentation .
如果您提出请求,我们要求您定期将master合并到您的pr分支机构,以便您的pr始终可以与上游master分支机构共享。
如果您是开发人员,并且希望评估请求队列,那么有一个非常好的 tool that lets you do this from the command line
请参阅下面的“注意补丁”部分。一般来说,当你提交一个公关时,你应该有责任完成它——对其他开发人员发布的查询作出响应,为你的功能寻找一个“拥护者”,如果你发现你的公关没有被执行,偶尔给他们一个温和的提醒。请记住,QGIS项目是由志愿者的努力推动的,人们可能无法立即关注您的公关。如果你觉得公关没有得到重视,你应该选择加速(按优先顺序):
git fetch origin
和 git rebase origin/master
(如果原点是上游的遥控器,而不是您自己的遥控器,请检查您的 .git/config
或做 git remote -v | grep github.com/qgis
)git push -f
到你的分叉回购。核心开发人员:不要在QGIS公共存储库上执行此操作!除了可以添加用于分类您的PR的常用标记外,还有一些特殊的标记,您可以在合并Pull请求后在QGIS文档库中自动生成问题报告:
[needs-docs]
to instruct doc writers to please add some extra documentation
after a fix or addition to an already existing functionality.[feature]
in case of new functionnality. Filling a good description in your
PR will be a good start.请开发人员使用这些标签(不区分大小写),这样文档编写人员就有问题要处理,并对要做的事情进行概述。但也请花时间添加一些文本:在提交或文档本身中。
选项A:
选项B:
git pull --rebase
:创建快进,不进行“合并提交”。更清晰的历史记录,但更难恢复合并。git push
(NEVER EVER use the -f option here)如果修补程序是针对特定bug的修补程序,请使用其中的bug编号命名文件,例如bug777fix.patch,并将其附加到 original bug report in trac .
如果bug是一个增强或新特性,那么创建一个 ticket in trac 先贴上你的补丁。
这使得我们更容易应用补丁,因为我们不需要导航到源树中的特定位置来应用补丁。另外,当我收到补丁时,我通常使用merge对它们进行评估,并且从顶级dir获取补丁会使这变得容易得多。下面是一个示例,说明如何从顶层目录将多个已更改的文件包含到修补程序中:
cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout > bug777fix.patch
这将确保主分支与上游存储库同步,然后生成一个补丁,其中包含功能分支和主分支中的内容之间的增量。
QGIS开发人员都很忙。我们确实扫描了bug报告中传入的补丁,但有时我们会错过一些东西。不要被冒犯或惊慌。尝试确定一个开发人员来帮助您-使用 Technical Resources 联系他们,询问他们是否可以查看你的补丁。如果您没有得到任何回复,您可以将您的查询升级到项目指导委员会成员之一(联系方式也可在技术资源中找到)。
对qgis源树的写访问是通过邀请进行的。通常情况下,当一个人提交几个(这里没有固定数量)的基本补丁,显示基本能力和理解C++和QGIS编码约定时,PSC成员或其他现有开发人员可以将该人提名给PSC以授予写访问权限。提名人应该给出一个基本的宣传段落,说明为什么他们认为此人应该获得写访问权。在某些情况下,我们将授予对非C++开发人员的访问权限,例如对于翻译人员和文档管理员。在这些情况下,这个人应该仍然展示了提交补丁的能力,并且在理想情况下应该提交了几个实质性的补丁,以展示他们对修改代码库的理解,而不会破坏代码库等。
注解
由于迁移到Git,我们不太可能授予新开发人员写访问权限,因为在GitHub内通过分叉QGIS然后发出请求来共享代码是很简单的。
在发出任何提交/拉请求之前,请务必检查所有内容是否都已编译。请注意,您的提交可能会导致人们在其他平台上以及使用旧/新版本的库进行构建。
提交时,编辑器(在$editor环境变量中定义)将出现,您应在文件顶部(在显示“不更改此内容”的区域上方)进行注释。如果多个文件之间的更改不相关,请使用描述性的注释,而不是执行几个小的提交。相反,我们希望您将相关的更改分组为单个提交。