activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [2/2] activemq-artemis git commit: Improving the merging process doc, based on rebasing
Date Tue, 02 Feb 2016 14:57:07 GMT
Improving the merging process doc, based on rebasing


Branch: refs/heads/master
Commit: f4481cbdb6ddf03de8def4a5c10aa85091cab4a8
Parents: c9dd9b2
Author: Clebert Suconic <>
Authored: Fri Jan 29 10:03:06 2016 -0500
Committer: jbertram <>
Committed: Tue Feb 2 08:56:47 2016 -0600

 docs/hacking-guide/en/ | 53 +++++++++++++++++++++----------
 scripts/                  |  5 ++-
 2 files changed, 41 insertions(+), 17 deletions(-)
diff --git a/docs/hacking-guide/en/ b/docs/hacking-guide/en/
index b6dafd4..5bc99f8 100644
--- a/docs/hacking-guide/en/
+++ b/docs/hacking-guide/en/
@@ -23,6 +23,12 @@ broken and code quality has not decreased.
 If the build does break then developer is expected to make their best effort to get the builds
fixed in a reasonable
 amount of time. If it cannot be fixed in a reasonable amount of time the commit can be reverted
and re-reviewed.
+# Using the dev profile.
+Developers are encouraged also to use the Dev profile, which will activate checkstyle during
the build:
+    mvn -Pdev install
 ## Commit Messages
 Please ensure the commit messages follow the 50/72 format as described [here](
@@ -68,38 +74,41 @@ Here are the basic commands to retrieve pull requests, merge, and push
them to t
 1. Checkout the pull request you wish to review
-        $ git checkout pr/105
+        $ git checkout pr/105 -B 105
+1. Rebase the branch against master, so the merge would happen at the top of the current
+        $ git pull --rebase apache master
 1. Once you've reviewed the change and are ready to merge checkout `master`.
         $ git checkout master
-1. Ensure you are up to date
+1. Ensure you are up to date on your master also.
+        $ git pull --rebase apache master
-        $ git pull
+1. We actually recommend checking out master again, to make sure you wouldn't add any extra
commits by accident:
+        $ git fetch upstream apache
+        $ git checkout apache/master -B master
 1. Create a new merge commit from the pull-request. IMPORTANT: The commit message here should
be something like: "This
    closes #105" where "105" is the pull request ID.  The "#105" shows up as a link in the
GitHub UI for navigating to
-   the PR from the commit message.
+   the PR from the commit message. This will ensure the github pull request is closed even
if the commit ID changed due
+   to eventual rebases.
-        $ git merge --no-ff pr/105
+        $ git merge --no-ff 105 -m "This closes #105"
 1. Push to the canonical Apache repo.
         $ git push apache master
-## Rebasing before you merge
-If the pull request gets too behind master, it would be better to rebase the branch before
merging it.
-You can do that by either asking the author of the pull request to do such rebase (what is
not always possible) or you could do it yourself during merging.
-In case you rebase the pull request it is mandatory that write "This closes #105" Where 105
is the pull request ID.
+## Using the automated script
-There is a script that helps doing such thing at <project root>/scripts/
+If you followed the naming conventions described here you can use the ```scripts/```
script to automate
+the merging process. This will execute the exact steps described on this previous section.
-The script is assuming you have defined remotes named at upstream, apache and origin like
specified previously here.
-to execute such script simply use:
+- Simply use:
 $ <checkout-directory>/scripts/ <PR number> Message on the PR
@@ -111,7 +120,7 @@ Example:
 $  pwd
-$  ./scripts/ 175 ARTEMIS-229 address on Security Interface
+$  ./scripts/ 175 ARTEMIS-229 address on Security Interface
 The previous example was taken from a real case that generated this [merge commit on #175](
@@ -121,6 +130,18 @@ The previous example was taken from a real case that generated this [merge
 $ git push apache master
+## Use a separate branch for your changes
+It is recommended that you work away from master for two reasons:
+1. When you send a PR, your PR branch could be rebased during the process and your commit
ID changed. You might
+   get unexpected conflicts while rebasing your old branch.
+1. You could end up pushing things upstream that you didn't intend to. Minimize your risks
by working on a branch
+   away from master.
 ## Notes:
 The GitHub mirror repository (i.e. `upstream`) is cloning the canonical Apache repository.
 Because of this there may be
diff --git a/scripts/ b/scripts/
index daf0800..b12e02f 100755
--- a/scripts/
+++ b/scripts/
@@ -17,6 +17,8 @@
 # under the License.
+# Use this to simplify the rebasing of PRs. PRs will be rebased during the merge on this
+# use: ./rebase-PR <PRID> textual description
 # this script assumes the following remote entries on your config
@@ -29,8 +31,9 @@
 git fetch origin
 git fetch apache
-git checkout apache/master -B master
 git fetch upstream 
+git checkout apache/master -B master
 git checkout upstream/pr/$1 -B $1
 git pull --rebase apache master
 git checkout master

View raw message