3. GIT アクセス¶

このセクションでは、QGIS GITリポジトリの使用を開始する方法について説明します。これを行う前には、まずgitのクライアントがシステムにインストールされている必要があります。

3.1. インストール ¶

3.1.1. GNU/Linuxに git をインストール ¶

Debianベースのディストリビューションユーザーは以下を行うことができます：

sudo apt install git

3.1.2. Windowsに git をインストール ¶

Windows users can obtain msys git or use git distributed with cygwin.

3.1.3. OSXに git をインストール ¶

The git project has a downloadable build of git. Make sure to get the package matching your processor (x86_64 most likely, only the first Intel Macs need the i386 package).

一度開いたディスクイメージをダウンロードし、インストーラを実行します。

PPC/source note

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=

3.2. リポジトリにアクセスする ¶

QGISマスターのクローンを作成するには：

git clone git://github.com/qgis/QGIS.git

3.3. ブランチをチェックアウト ¶

ブランチ、例えばリリース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では、現在のリリースブランチで私たちの最も安定したコードを維持します。マスターには、いわゆる「不安定」リリースシリーズ用のコードが含まれています。定期的に私たちはマスターオフのリリースをブランチにして、マスターに新しい機能の安定化と選択的取り込みを継続します。

開発バージョンをビルドする具体的な手順については、ソースツリー中のINSTALLファイルを参照してください。

3.5. QGISウェブサイトのソース ¶

QGISウェブサイトのソースをチェックアウトすることに興味がある場合：

git clone [email protected]:qgis/QGIS-Website.git

また、より多くの情報のためのウェブサイトのレポに含まれているREADMEを見てみることができます。

The complexity of the QGIS source code has increased considerably during the last years. Therefore it is hard to anticipate the side effects that the addition of a feature will have. In the past, the QGIS project had very long release cycles because it was a lot of work to reestablish the stability of the software system after new features were added. To overcome these problems, QGIS switched to a development model where new features are coded in GIT branches first and merged to master (the main branch) when they are finished and stable. This section describes the procedure for branching and merging in the QGIS project.

3.7.2. 手順 ¶

メーリングリストでの初期の発表：
開始する前に、別の開発者がすでに同じ機能に取り組んでいるかどうかを確認するために、開発者メーリングリストで発表を行います。また、プロジェクト運営委員会（PSC）の技術顧問にお問い合わせください。新機能はQGISアーキテクチャへの変更を必要とする場合は、コメント要求（RFC）が必要とされます。

ブランチを作成します。新機能の開発のための新たなGITブランチを作成します。

git checkout -b newfeature

今、開発を開始できます。そのブランチで広範囲を行うことを計画している場合、他の開発者と仕事を共有したい、上流のレポへの書込アクセス権を持ちたい場合、以下を実行することでQGIS公式レポに自分のレポをプッシュアップできます：

git push origin newfeature

注釈

ブランチがすでに存在する場合、変更はそこにプッシュされます。

定期的にマスターにリベースする：マスターにおける変更をブランチに組み込むために定期的にリベースすることをお勧めします。これは、後で簡単に逆にマスターへとブランチをマージできます。リベースした後、あなたのフォークレポに git push -f する必要があります。

注釈

決してオリジナルのリポジトリに git push -f しないでください！これはご自身の作業ブランチのために使用してください。

git rebase master

3.7.3. マスターに戻してマージする前にテスト ¶

新しい機能性と安定性に満足して終了したら、開発者リストで発表を行います。戻してマージする前に、変更は開発者とユーザーによってテストされるでしょう。

3.8. パッチを提出して要求をプル ¶

パッチを取得し簡単にQGISに要求をプルするのに役立つ、そして簡単に使用するために送信されるそのパッチを扱うのに役立つ、いくつかのガイドラインがあります。

3.8.1. 要求をプル ¶

In general it is easier for developers if you submit GitHub pull requests. We do not describe Pull Requests here, but rather refer you to the GitHub pull request documentation.

If you make a pull request we ask that you please merge master to your PR branch regularly so that your PR is always mergeable to the upstream master branch.

If you are a developer and wish to evaluate the pull request queue, there is a very nice tool that lets you do this from the command line

「パッチを通知する」に関する以下のセクションを参照してください。一般的に、PRを提出する際には最後までそれをフォロースルーするために責任を取る必要があります - あなたのPRが作用していないと見れば、他の開発者によって投稿された照会に応答し、あなたの機能のための「チャンピオン」を探し出し、時折それらについて軽く催促します。QGISプロジェクトはボランティアの努力によって運営され、人々が瞬時にPRに出席できないかもしれないことを心に留めておいてください。PRがふさわしい注意を受けていないと感じた場合、加速するためのあなたの選択肢は（優先順に）：

あなたのPRおよびそれがコードベースに含まれるとどれほど素晴らしいかを「売り込む」メッセージをメーリングリストに送信します。
PRキュー内であなたのPRが割り当てられている人にメッセージを送信します。
（PRキューを管理している）マルコ・ヒュージェントブラーにメッセージを送信します。
プロジェクトの運営委員会にメッセージを送信し、あなたのPRがコードベースに組み込まれるのを見るのを助けるよう求めます。

3.8.1.1. プル要求を作成するためのベストプラクティス ¶

常に現在のマスターから機能ブランチを開始します。
機能ブランチをコーディングしている場合は、そのブランチに何かを「マージ」しないでください。むしろ、あなたの履歴をきれいなままに保持するために、次のポイントで説明されるように、リベースしてください。
プル要求を作成する前に git fetch origin および git rebase origin/master を実行してください（原点が独自のリモート上流および自身のリモートでないため与えられ、 .git/config をチェックするか git remote -v | grep github.com/qgis してください）。
何らかのダメージを与えることなく繰り返し、最後の行のようにgitリベースを行うことができます（あなたのブランチの唯一の目的がマスターにマージされることである限り、）。
注意：リベースした後、あなたのフォークレポに git push -f する必要があります。 CORE DEVS：QGIS公開リポジトリ上でこれをしないでください！

3.8.1.2. documentorsを通知する特別なラベル ¶

PRを分類するために追加できる共通のタグのほかに、プル要求がマージされるとすぐにQGIS-ドキュメントリポジトリ内の問題点レポートを自動的に生成するために使用できる特別なものがあります。

[needs-docs] 既存の機能に修正や追加した後、いくつかの余分なドキュメントを追加してくださいとお願いするドキュメントライターを指示します。
[feature] in case of new functionality. Filling a good description in your PR will be a good start.

開発者はこれらのラベル（大小文字を区別しない）を使用してください、ドキュメントの作成者が作業する問題を持ち、するべきことの概要を持つように。しかし、また、いくつかのテキストを追加する時間をかけてください：コミットまたはドキュメント自体のいずれかで。

3.8.1.3. プル要求をマージするには ¶

オプションA:

マージボタンをクリックします（非早送りマージを作成します）

オプションB:

プル要求をチェックアウト
テスト（また、明らかに、オプションAのために必要）
マスターをチェックアウト、 git merge pr/1234
オプションの： git pull --rebase ：早送りを作成します、「コミットマージ」は行われません。履歴はよりきれいですが、マージを元に戻すのは困難です。
git push (ここで -f オプションは決してEVER使用しないでください)

3.9. パッチファイルの命名 ¶

If the patch is a fix for a specific bug, please name the file with the bug number in it e.g. bug777fix.patch, and attach it to the original bug report in GitHub.

If the bug is an enhancement or new feature, it's usually a good idea to create a ticket in GitHub first and then attach your patch.

3.10. トップレベルのQGISソースディレクトリにパッチを作成 ¶

これにより、パッチを適用するために、ソースツリー内の特定の場所に移動する必要がないので、パッチを適用することが容易になります。また、パッチを受信したときに、通常、マージ使用してそれらを評価し、トップレベルのディレクトリからパッチを持つことは、これは非常に簡単になります。以下は、トップレベルのディレクトリからあなたのパッチに複数の変更されたファイルを含めることができる方法の例です。

cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout > bug777fix.patch

これは、マスターブランチが上流リポジトリと同期していることを確認した後、あなたの機能ブランチとマスターブランチ中にあるものと間でデルタを含むパッチを生成します。

3.10.1. パッチを通知する ¶

QGIS developers are busy folk. We do scan the incoming patches on bug reports but sometimes we miss things. Don't be offended or alarmed. Try to identify a developer to help you and contact them asking them if they can look at your patch. If you don't get any response, you can escalate your query to one of the Project Steering Committee members (contact details also available in the Technical Resources).

3.10.2. 適当な注意 ¶

QGISはGPLの下でライセンスされています。あなたは、矛盾する知的財産権によって妨げられないパッチを提出するよう、あらゆる努力をする必要があります。また、GPLの下で利用可能になって嬉しくないコードを提出しないでください。

3.11. GIT書き込みアクセス権の取得 ¶

QGISソースツリーへの書き込みアクセス権は招待によります。人はC ++とQGISコーディング規約の基本的な能力と理解を示し、いくつかの（ここには一定の数が存在しない）かなりのパッチを提出する場合、通常、PSCのメンバーや他の既存の開発者の一人は、書き込みアクセスを許可するためのPSCにその人を指名できます。推薦は、彼らがその人が書き込みアクセス権を取得すべきだと思う理由の基本的なプロモーション段落を与える必要があります。いくつかのケースでは、我々は、翻訳者とdocumentors用など非C ++開発者への書き込みアクセスを許可します。これらのケースでは、人はまだパッチを提出する能力を実証している必要があり、理想的に物事を壊すことなく、コードベースを変更することの理解を示し、いくつかのかなりのパッチなどを提出している必要があります

注釈

GITに移動するので、QGISをforkしてプル要求を発行することによってgithubの内のコードを共有することは簡単なので、新しい開発者に書き込みアクセスを許可する可能性は低いです。

常にすべてがコミット/プル要求を作成する前にコンパイルされることを確認してください。あなたのコミットは、人々が他のプラットフォーム上で構築するためのライブラリとの古い/新しいバージョンの原因となる可能性のある破損を認識するようにしてください。

コミット行うとき、（ $EDITOR 環境変数で定義されている）エディタが表示されますので、ファイルの先頭（「これを変更しないでください」と言う領域の上）にコメントをする必要があります。多数のファイルの変更が無関係であれば、説明のコメントを入れて、いくつかの小さなコミットを行います。逆に、関係した変更は単一のコミットにグループ化していただくのが好ましいです。