このセクションでは、QGIS GITリポジトリの使用を開始する方法について説明します。これを行う前には、まずgitのクライアントがシステムにインストールされている必要があります。
Windows users can obtain msys git or use git distributed with cygwin.
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 http://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では、現在のリリースブランチで私たちの最も安定したコードを維持します。マスターには、いわゆる「不安定」リリースシリーズ用のコードが含まれています。定期的に私たちはマスターオフのリリースをブランチにして、マスターに新しい機能の安定化と選択的取り込みを継続します。
開発バージョンをビルドする具体的な手順については、ソースツリー中のINSTALLファイルを参照してください。
QGISのドキュメントソースをチェックアウトすることに興味がある場合：
git clone [email protected]:qgis/QGIS-Documentation.git
詳細についてはドキュメントレポに付属のREADMEを見てみることもできます。
QGISウェブサイトのソースをチェックアウトすることに興味がある場合：
git clone [email protected]:qgis/QGIS-Website.git
また、より多くの情報のためのウェブサイトのレポに含まれているREADMEを見てみることができます。
QGISソースコードの複雑さは近年大幅に増加しています。そのため、機能の追加が持つ副作用を予測することは困難です。新しい機能が追加された後のソフトウェアシステムの安定性を再確立するのは大変な仕事だったので、過去には、QGISプロジェクトは非常に長いリリースサイクルを持っていました。これらの問題を克服するために、QGISでは開発モデルを切り替え、新機能は最初にGITブランチでコーディングし、完成して安定したときにマスター（メインブランチ）にマージするようにします。このセクションでは、QGISプロジェクトでブランチ作成およびマージするための手順を説明します。
開始する前に、別の開発者がすでに同じ機能に取り組んでいるかどうかを確認するために、開発者メーリングリストで発表を行います。また、プロジェクト運営委員会（PSC）の技術顧問にお問い合わせください。新機能はQGISアーキテクチャへの変更を必要とする場合は、コメント要求（RFC）が必要とされます。
ブランチを作成します。新機能の開発のための新たなGITブランチを作成します。
git checkout -b newfeature
今、開発を開始できます。そのブランチで広範囲を行うことを計画している場合、他の開発者と仕事を共有したい、上流のレポへの書込アクセス権を持ちたい場合、以下を実行することでQGIS公式レポに自分のレポをプッシュアップできます：
git push origin newfeature
ノート
ブランチがすでに存在する場合、変更はそこにプッシュされます。
定期的にマスターにリベースする：マスターにおける変更をブランチに組み込むために定期的にリベースすることをお勧めします。これは、後で簡単に逆にマスターへとブランチをマージできます。リベースした後、あなたのフォークレポに git push -f する必要があります。
ノート
決してオリジナルのリポジトリに git push -f しないでください！これはご自身の作業ブランチのために使用してください。
git rebase master
It is also recommended to document the intended changes and the current status of the work on a wiki page.
新しい機能性と安定性に満足して終了したら、開発者リストで発表を行います。戻してマージする前に、変更は開発者とユーザーによってテストされるでしょう。
パッチを取得し簡単にQGISに要求をプルするのに役立つ、そして簡単に使用するために送信されるそのパッチを扱うのに役立つ、いくつかのガイドラインがあります。
一般的に、GitHubのプル要求を送信する場合は開発者にとって簡単です。ここではプル要求を記述していませんが、むしろ GitHubのプル要求の文書 を参照してください。
プル要求を行った場合、ご自身のPRが常に上流のマスターブランチにマージ可能であるように、そのPRにマスターブランチを定期的にマージしてくださいますようお願いいたします。
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がコードベースに組み込まれるのを見るのを助けるよう求めます。
常に現在のマスターから機能ブランチを開始します。
機能ブランチをコーディングしている場合は、そのブランチに何かを「マージ」しないでください。むしろ、あなたの履歴をきれいなままに保持するために、次のポイントで説明されるように、リベースしてください。
プル要求を作成する前に git fetch origin および git rebase origin/master を実行してください（原点が独自のリモート上流および自身のリモートでないため与えられ、 .git/config をチェックするか git remote -v | grep github.com/qgis してください）。
何らかのダメージを与えることなく繰り返し、最後の行のようにgitリベースを行うことができます（あなたのブランチの唯一の目的がマスターにマージされることである限り、）。
注意：リベースした後、あなたのフォークレポに git push -f する必要があります。 CORE DEVS：QGIS公開リポジトリ上でこれをしないでください！
PRを分類するために追加できる共通のタグのほかに、プル要求がマージされるとすぐにQGIS-ドキュメントリポジトリ内の問題点レポートを自動的に生成するために使用できる特別なものがあります。
[needs-docs] 既存の機能に修正や追加した後、いくつかの余分なドキュメントを追加してくださいとお願いするドキュメントライターを指示します。
[feature] 新しい機能functionnalityの場合。あなたのPRに適切な説明を記入することは良いスタートとなります。
開発者はこれらのラベル（大小文字を区別しない）を使用してください、ドキュメントの作成者が作業する問題を持ち、するべきことの概要を持つように。しかし、また、いくつかのテキストを追加する時間をかけてください：コミットまたはドキュメント自体のいずれかで。
オプションA:
マージボタンをクリックします（非早送りマージを作成します）
オプションB:
テスト（また、明らかに、オプションAのために必要）
マスターをチェックアウト、 git merge pr/1234
オプションの： git pull --rebase ：早送りを作成します、「コミットマージ」は行われません。履歴はよりきれいですが、マージを元に戻すのは困難です。
git push (ここで -f オプションは決してEVER使用しないでください)
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 trac.
If the bug is an enhancement or new feature, its usually a good idea to create a ticket in trac first and then attach your patch.
これにより、パッチを適用するために、ソースツリー内の特定の場所に移動する必要がないので、パッチを適用することが容易になります。また、パッチを受信したときに、通常、マージ使用してそれらを評価し、トップレベルのディレクトリからパッチを持つことは、これは非常に簡単になります。以下は、トップレベルのディレクトリからあなたのパッチに複数の変更されたファイルを含めることができる方法の例です。
cd QGIS
git checkout master
git pull origin master
git checkout newfeature
git format-patch master --stdout > bug777fix.patch
これは、マスターブランチが上流リポジトリと同期していることを確認した後、あなたの機能ブランチとマスターブランチ中にあるものと間でデルタを含むパッチを生成します。
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 - using the Technical Resources 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).
QGISソースツリーへの書き込みアクセス権は招待によります。人はC ++とQGISコーディング規約の基本的な能力と理解を示し、いくつかの（ここには一定の数が存在しない）かなりのパッチを提出する場合、通常、PSCのメンバーや他の既存の開発者の一人は、書き込みアクセスを許可するためのPSCにその人を指名できます。推薦は、彼らがその人が書き込みアクセス権を取得すべきだと思う理由の基本的なプロモーション段落を与える必要があります。いくつかのケースでは、我々は、翻訳者とdocumentors用など非C ++開発者への書き込みアクセスを許可します。これらのケースでは、人はまだパッチを提出する能力を実証している必要があり、理想的に物事を壊すことなく、コードベースを変更することの理解を示し、いくつかのかなりのパッチなどを提出している必要があります
ノート
GITに移動するので、QGISをforkしてプル要求を発行することによってgithubの内のコードを共有することは簡単なので、新しい開発者に書き込みアクセスを許可する可能性は低いです。
常にすべてがコミット/プル要求を作成する前にコンパイルされることを確認してください。あなたのコミットは、人々が他のプラットフォーム上で構築するためのライブラリとの古い/新しいバージョンの原因となる可能性のある破損を認識するようにしてください。
コミット行うとき、（ $EDITOR 環境変数で定義されている）エディタが表示されますので、ファイルの先頭（「これを変更しないでください」と言う領域の上）にコメントをする必要があります。多数のファイルの変更が無関係であれば、説明のコメントを入れて、いくつかの小さなコミットを行います。逆に、関係した変更は単一のコミットにグループ化していただくのが好ましいです。