You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@gearpump.apache.org by ap...@apache.org on 2016/04/11 20:26:32 UTC
[30/50] incubator-gearpump git commit: fix #1963,
rename CommitGuideline.md to CONTRIBUTING.md
fix #1963, rename CommitGuideline.md to CONTRIBUTING.md
Project: http://git-wip-us.apache.org/repos/asf/incubator-gearpump/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-gearpump/commit/0851765b
Tree: http://git-wip-us.apache.org/repos/asf/incubator-gearpump/tree/0851765b
Diff: http://git-wip-us.apache.org/repos/asf/incubator-gearpump/diff/0851765b
Branch: refs/heads/master
Commit: 0851765ba7ba234b2d18b0a686555a5dc8ab90a7
Parents: 9405961
Author: manuzhang <ow...@gmail.com>
Authored: Sat Feb 13 18:02:20 2016 +0800
Committer: manuzhang <ow...@gmail.com>
Committed: Sat Feb 13 18:02:56 2016 +0800
----------------------------------------------------------------------
CONTRIBUTING.md | 92 +++++++++++++++++++++++++++++++++++++++++++++++++
CommitGuideline.md | 92 -------------------------------------------------
2 files changed, 92 insertions(+), 92 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-gearpump/blob/0851765b/CONTRIBUTING.md
----------------------------------------------------------------------
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..a523344
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,92 @@
+This documents are for committers which have direct write permission to intel-hadoop/gearpump
+
+Commit Guideline
+========================
+1. For all commit(except doc), must create an issue id.
+2. For all commit log message, must contain the issue id, Like this: fix #issueId, comments.
+3. For all PR, the title must contains issue Id.
+4. We use rebase and squash instead of merge to ensure the log message is clean. Check section "Pull Request merge process for Gearpump"
+5. Every commit (except doc) must have 1 guy to review before commit.
+
+Pull Request merge process for Gearpump
+========================
+1. Fork in github to create a /gearpump repo. After fork, you will have a new repo at http://github.com/<git-user_id>/gearpump.
+2. Add gearpump/gearpump as an external repo 'upstream' by following the [guide](https://help.github.com/articles/configuring-a-remote-for-a-fork/).
+
+ ```bash
+ git remote add upstream https://github.com/gearpump/gearpump.git
+ ```
+
+3. In local master branch, periodically sync the forked master with the main master with
+
+ ```
+ git pull --rebase upstream master
+ git push origin master
+ ```
+No work should ever be done in the forked master. Another way to do this is to
+
+ ```
+ git checkout master
+ git fetch upstream
+ git rebase upstream/master
+ ```
+
+4. Create a working branch
+
+ ```
+ git branch branch_issueId
+ git checkout branch_issusId
+ ```
+
+ Work on the branch, make changes, then push to your forked gearpump repo http://github.com/<git-user_id>/gearpump
+
+ ```
+ git push origin branch_issueId
+ ```
+
+5. When there is changes in upstream/master, rebase your work on upstream/master. with
+
+ ```bash
+ git checkout branch_issueId
+ git rebase -i upstream/master
+ ```
+
+ You can also use this when you want to squash(merge) multiple commits into one.
+ ```git rebase -i``` will popup a window, which allow you to squash(merge) multiple commits into one commit.
+ For example I might have 12 commits in my branch. "rebase -i upstream/master" opens a nice editor where you can mark some commits to be squashed(merged) into prior commits, and make 1 big commit (or several) out of it. In this way, I can tidy up what will be committed to the project master's history since otherwise my commit messages are like "not working" or "got it working" or "more fix" or "merged <git-user-id>/gearpump to master".
+
+6. If there is conflict, resolve the conflict, and then
+
+ ```bash
+ git rebase --continue
+ ```
+
+ After the code is successfully rebased, a window will pop up to edit the commit log, edit it then save and exit.
+7. After rebase, now you have a clean log history. push to your remote working branch
+
+ ```
+ git push origin branch_issueId
+ ```
+
+ If commits have already been pushed to <git-user-id>/gearpump fork on github, you will have to "git push --force" to overwrite them with squashed commits.
+
+ ```
+ git push origin -f branch_issueId
+ ```
+
+8. Ensure all the unit tests are passed by running command "sbt test".
+6. Open a PR, which is a one-click thing in github.com; it knows you likely are opening a PR against upstream master. [Guide](https://help.github.com/articles/creating-a-pull-request) is here.
+7. [Merge PR](https://help.github.com/articles/merging-a-pull-request), [delete branch](https://help.github.com/articles/deleting-unused-branches).
+
+
+You can skip using branches in your fork if desired, and just work out of your master. Less overhead, but, you can't pursue different unrelated changes then.
+
+The key here is using rebase, not merge. The downstream forks never need to use merge unless the work is a long-lived collaboration with someone else who is pulling from your fork.
+
+More details on Squash before pull request
+---------------------------
+More about squash, please check
+
+http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
+
+https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
http://git-wip-us.apache.org/repos/asf/incubator-gearpump/blob/0851765b/CommitGuideline.md
----------------------------------------------------------------------
diff --git a/CommitGuideline.md b/CommitGuideline.md
deleted file mode 100644
index a523344..0000000
--- a/CommitGuideline.md
+++ /dev/null
@@ -1,92 +0,0 @@
-This documents are for committers which have direct write permission to intel-hadoop/gearpump
-
-Commit Guideline
-========================
-1. For all commit(except doc), must create an issue id.
-2. For all commit log message, must contain the issue id, Like this: fix #issueId, comments.
-3. For all PR, the title must contains issue Id.
-4. We use rebase and squash instead of merge to ensure the log message is clean. Check section "Pull Request merge process for Gearpump"
-5. Every commit (except doc) must have 1 guy to review before commit.
-
-Pull Request merge process for Gearpump
-========================
-1. Fork in github to create a /gearpump repo. After fork, you will have a new repo at http://github.com/<git-user_id>/gearpump.
-2. Add gearpump/gearpump as an external repo 'upstream' by following the [guide](https://help.github.com/articles/configuring-a-remote-for-a-fork/).
-
- ```bash
- git remote add upstream https://github.com/gearpump/gearpump.git
- ```
-
-3. In local master branch, periodically sync the forked master with the main master with
-
- ```
- git pull --rebase upstream master
- git push origin master
- ```
-No work should ever be done in the forked master. Another way to do this is to
-
- ```
- git checkout master
- git fetch upstream
- git rebase upstream/master
- ```
-
-4. Create a working branch
-
- ```
- git branch branch_issueId
- git checkout branch_issusId
- ```
-
- Work on the branch, make changes, then push to your forked gearpump repo http://github.com/<git-user_id>/gearpump
-
- ```
- git push origin branch_issueId
- ```
-
-5. When there is changes in upstream/master, rebase your work on upstream/master. with
-
- ```bash
- git checkout branch_issueId
- git rebase -i upstream/master
- ```
-
- You can also use this when you want to squash(merge) multiple commits into one.
- ```git rebase -i``` will popup a window, which allow you to squash(merge) multiple commits into one commit.
- For example I might have 12 commits in my branch. "rebase -i upstream/master" opens a nice editor where you can mark some commits to be squashed(merged) into prior commits, and make 1 big commit (or several) out of it. In this way, I can tidy up what will be committed to the project master's history since otherwise my commit messages are like "not working" or "got it working" or "more fix" or "merged <git-user-id>/gearpump to master".
-
-6. If there is conflict, resolve the conflict, and then
-
- ```bash
- git rebase --continue
- ```
-
- After the code is successfully rebased, a window will pop up to edit the commit log, edit it then save and exit.
-7. After rebase, now you have a clean log history. push to your remote working branch
-
- ```
- git push origin branch_issueId
- ```
-
- If commits have already been pushed to <git-user-id>/gearpump fork on github, you will have to "git push --force" to overwrite them with squashed commits.
-
- ```
- git push origin -f branch_issueId
- ```
-
-8. Ensure all the unit tests are passed by running command "sbt test".
-6. Open a PR, which is a one-click thing in github.com; it knows you likely are opening a PR against upstream master. [Guide](https://help.github.com/articles/creating-a-pull-request) is here.
-7. [Merge PR](https://help.github.com/articles/merging-a-pull-request), [delete branch](https://help.github.com/articles/deleting-unused-branches).
-
-
-You can skip using branches in your fork if desired, and just work out of your master. Less overhead, but, you can't pursue different unrelated changes then.
-
-The key here is using rebase, not merge. The downstream forks never need to use merge unless the work is a long-lived collaboration with someone else who is pulling from your fork.
-
-More details on Squash before pull request
----------------------------
-More about squash, please check
-
-http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
-
-https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request