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).
The git site does not offer PPC builds. If you need a PPC build, or you just want a little more control over the installation, you need to compile it yourself.
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
export NO_PERL= export NO_TCLTK= export NO_PYTHON=
cd QGIS git fetch git branch --track origin release-2_6_1 git checkout release-2_6_1
cd QGIS git checkout master
git clone [email protected]:qgis/QGIS-Documentation.git
git clone [email protected]:qgis/QGIS-Website.git
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.
在开始之前，需要在开发邮件列表里声明一下，看是否有其他开发人员已经在做同样的功能了。同时联系项目控制委员会（project steering committee， PSC）的技术顾问。如果一个新功能需要改动QGIS的架构，还需要提一个记录（request for comment，RFC）。
git checkout -b newfeature
git push origin newfeature
定期从主版本库更新代码：强烈建议你定期从主版本库更新代码到你的分支库，以便拿到主版本库里最新的改动。这样可以使你的分支库再合并回主版本库的时候，变得简单一些。更新完代码后，你需要在你的分支库上执行“git push -f”。
注意：千万不要在源库里执行“git push -f”！只能在你的开发分支库里执行。
git rebase master
There are a few guidelines that will help you to get your patches and pull requests into QGIS easily, and help us deal with the patches that are sent to use easily.
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
Please see the section below on 'getting your patch noticed'. In general when you submit a PR you should take the responsibility to follow it through to completion - respond to queries posted by other developers, seek out a 'champion' for your feature and give them a gentle reminder occasionally if you see that your PR is not being acted on. Please bear in mind that the QGIS project is driven by volunteer effort and people may not be able to attend to your PR instantaneously. If you feel the PR is not receiving the attention it deserves your options to accelerate it should be (in order of priority):
Send a message to the mailing list 'marketing' your PR and how wonderful it will be to have it included in the code base.
Send a message to the person your PR has been assigned to in the PR queue.
Send a message to Marco Hugentobler (who manages the PR queue).
Send a message to the project steering committee asking them to help see your PR incorporated into the code base.
Always start a feature branch from current master.
If you are coding a feature branch, don't "merge" anything into that branch, rather rebase as described in the next point to keep your history clean.
Before you create a pull request do
git fetch originand
git rebase origin/master(given origin is the remote for upstream and not your own remote, check your
git remote -v | grep github.com/qgis).
You may do a git rebase like in the last line repeatedly without doing any damage (as long as the only purpose of your branch is to get merged into master).
Attention: After a rebase you need to
git push -fto your forked repo. CORE DEVS: DO NOT DO THIS ON THE QGIS PUBLIC REPOSITORY!
Besides common tags you can add to classify your PR, there are special ones you can use to automatically generate issue reports in QGIS-Documentation repository as soon as your pull request is merged:
[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 functionality. Filling a good description in your PR will be a good start.
Please devs use these labels (case insensitive) so doc writers have issues to work on and have an overview of things to do. BUT please also take time to add some text: either in the commit OR in the docs itself.
click the merge button (Creates a non-fast-forward merge)
Test (Also required for option A, obviously)
checkout master, git merge pr/1234
git pull --rebase: Creates a fast-forward, no "merge commit" is made. Cleaner history, but it is harder to revert the merge.
git push(NEVER EVER use the -f option here)
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.
This makes it easier for us to apply the patches since we don't need to navigate to a specific place in the source tree to apply the patch. Also when I receive patches I usually evaluate them using merge, and having the patch from the top level dir makes this much easier. Below is an example of how you can include multiple changed files into your patch from the top level directory:
cd QGIS git checkout master git pull origin master git checkout newfeature git format-patch master --stdout > bug777fix.patch
This will make sure your master branch is in sync with the upstream repository, and then generate a patch which contains the delta between your feature branch and what is in the master branch.
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).
Write access to QGIS source tree is by invitation. Typically when a person submits several (there is no fixed number here) substantial patches that demonstrate basic competence and understanding of C++ and QGIS coding conventions, one of the PSC members or other existing developers can nominate that person to the PSC for granting of write access. The nominator should give a basic promotional paragraph of why they think that person should gain write access. In some cases we will grant write access to non C++ developers e.g. for translators and documentors. In these cases, the person should still have demonstrated ability to submit patches and should ideally have submitted several substantial patches that demonstrate their understanding of modifying the code base without breaking things, etc.
Since moving to GIT, we are less likely to grant write access to new developers since it is trivial to share code within github by forking QGIS and then issuing pull requests.
Always check that everything compiles before making any commits / pull requests. Try to be aware of possible breakages your commits may cause for people building on other platforms and with older / newer versions of libraries.
When making a commit, your editor (as defined in $EDITOR environment variable) will appear and you should make a comment at the top of the file (above the area that says 'don't change this'). Put a descriptive comment and rather do several small commits if the changes across a number of files are unrelated. Conversely we prefer you to group related changes into a single commit.