sharpetronics/QGIS
1
0
Fork 0
mirror of https://github.com/qgis/QGIS.git synced 2025-02-25 00:58:06 -05:00
Code Issues Packages Projects Releases Wiki Activity

Added notes on merging pull requests based on Matthias's message in mailing list.

Browse Source
This commit is contained in:
Tim Sutton 2014-01-13 12:29:49 +02:00
parent e3d6236ac2
commit e745b2ffa5
2 changed files with 63 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
CODING
View File

@ -629,6 +629,39 @@ deserves your options to accelerate it should be (in order of priority):
PR incorporated into the code base. PR incorporated into the code base.
2.7.1.1. Best practice for creating a pull request
==================================================
* Always start a feature branch from current master.
* If you are coding a feature branch, don't "merge" anything in other than
master (see below).
* Before you create a pull request do "git fetch origin" and "git rebase
origin/master" (given origin is the remote for upstream and not your own
remote, check your .git/config or do "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 -f" to your forked repo.
CORE DEVS: DO NOT DO THIS ON THE QGIS PUBLIC REPOSITORY!
2.7.1.2. For merging a pull request
===================================
Option A
* click the merge button (Creates a non-fast-forward merge)
Option B
* Checkout the pull request (See https://gist.github.com/piscisaureus/3342247)
* Test (Also required for option A, obviously)
* checkout master, git merge pr/1234
* Optional: git pull --rebase: Creates a fast-forward, no "merge commit" is
made. Cleaner history, but it is harder to revert the merge.
* git push
2.7.2. Patch file naming 2.7.2. Patch file naming
======================== ========================

30
doc/CODING.t2t
View File

@ -602,6 +602,36 @@ deserves your options to accelerate it should be (in order of priority):
* Send a message to the project steering committee asking them to help see your * Send a message to the project steering committee asking them to help see your
PR incorporated into the code base. PR incorporated into the code base.
==== Best practice for creating a pull request ====
* Always start a feature branch from current master.
* If you are coding a feature branch, don't "merge" anything in other than
master (see below).
* Before you create a pull request do "git fetch origin" and "git rebase
origin/master" (given origin is the remote for upstream and not your own
remote, check your .git/config or do "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 -f" to your **forked repo**.
**CORE DEVS**: DO NOT DO THIS ON THE QGIS PUBLIC REPOSITORY!
==== For merging a pull request ====
Option A
* click the merge button (Creates a non-fast-forward merge)
Option B
* Checkout the pull request (See https://gist.github.com/piscisaureus/3342247)
* Test (Also required for option A, obviously)
* checkout master, ``git merge pr/1234``
* Optional: ``git pull --rebase``: Creates a fast-forward, no "merge commit" is
made. Cleaner history, but it is harder to revert the merge.
* ``git push``
=== Patch file naming === === Patch file naming ===