You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not sure what a *pull request* is, or how to submit one?
17
+
Take a look at GitHub's excellent documentation: https://help.github.com/articles/using-pull-requests/[Using Pull Requests] first.
18
18
19
-
== Search JIRAfirst; create an issue if necessary
19
+
== Search GitHub (or JIRA) issues first; create one if necessary
20
20
21
-
Is there already an issue that addresses your concern? Search the
22
-
https://jira.springsource.org/browse/INT[JIRA issue tracker] to see if you can find something similar.
23
-
If not, please create a new issue before submitting a pull request unless the change is truly trivial, e.g. typo fixes,
24
-
removing compiler warnings, etc.
21
+
Is there already an issue that addresses your concern?
22
+
Search the https://github.com/spring-projects/spring-integration/issues[GitHub issue tracker] (or https://jira.springsource.org/browse/INT[JIRA issue tracker]) to see if you can find something similar.
23
+
If not, please create a new issue before submitting a pull request unless the change is truly trivial, e.g. typo fixes, removing compiler warnings, etc.
25
24
26
25
== Sign the contributor license agreement
27
26
28
-
If you have not previously done so, please fill out and
29
-
submit the https://cla.pivotal.io/sign/spring[Contributor License Agreement (CLA)].
27
+
If you have not previously done so, please fill out and submit the https://cla.pivotal.io/sign/spring[Contributor License Agreement (CLA)].
30
28
31
-
Very important, before we can accept any *Spring Integration contributions*, we will need you to sign the CLA. Signing the CLA does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do.
29
+
Very important, before we can accept any *Spring Integration contributions*, we will need you to sign the CLA.
30
+
Signing the CLA does not grant anyone commit rights to the main repository, but it does mean that we can accept your contributions, and you will get an author credit if we do.
32
31
33
32
== Fork the Repository
34
33
@@ -47,57 +46,46 @@ _you should see only 'origin' - which is the fork you created for your own githu
47
46
_you should now see 'upstream' in addition to 'origin' where 'upstream' is the SpringSource repository from which releases are built_
48
47
6. `git fetch --all`
49
48
7. `git branch -a`
50
-
_you should see branches on origin as well as upstream, including 'master' and 'maint'_
49
+
_you should see branches on origin as well as upstream, including 'master'_
51
50
52
51
== A Day in the Life of a Contributor
53
52
54
-
* _Always_ work on topic branches (Typically use the Jira ticket ID as the branch name).
55
-
- For example, to create and switch to a new branch for issue INT-123: `git checkout -b INT-123`
53
+
* _Always_ work on topic branches (Typically use the GitHub issue ID as the branch name).
54
+
- For example, to create and switch to a new branch for issue 123: `git checkout -b GH-123`
56
55
* You might be working on several different topic branches at any given time, but when at a stopping point for one of those branches, commit (a local operation).
57
-
* Please follow the "Commit Guidelines" described in
58
-
http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[this chapter of Pro Git].
59
-
* Then to begin working on another issue (say INT-101): `git checkout INT-101`. The _-b_ flag is not needed if that
60
-
branch already exists in your local repository.
61
-
* When ready to resolve an issue or to collaborate with others, you can push your branch to origin (your fork),
62
-
e.g.: `git push origin INT-123`
63
-
* If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and
64
-
`git fetch <your-username>` to grab your branch.
56
+
* Please follow the "Commit Guidelines" described in http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project[this chapter of Pro Git].
57
+
* Then to begin working on another issue (say 101): `git checkout GH-101`.
58
+
The _-b_ flag is not needed if that branch already exists in your local repository.
59
+
* When ready to resolve an issue or to collaborate with others, you can push your branch to origin (your fork), e.g.: `git push origin GH-123`
60
+
* If you want to collaborate with another contributor, have them fork your repository (add it as a remote) and `git fetch <your-username>` to grab your branch.
65
61
Alternatively, they can use `git fetch --all` to sync their local state with all of their remotes.
66
62
* If you grant that collaborator push access to your repository, they can even apply their changes to your branch.
67
-
* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical
68
-
spring-integration repository (what you know as 'upstream'), issue a pull request to the SpringSource repository
69
-
(for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]).
70
-
* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet
71
-
add a comment about something that should be modified, or he might reject the pull request by closing it.
63
+
* When ready for your contribution to be reviewed for potential inclusion in the master branch of the canonical `spring-integration` repository (what you know as 'upstream'), issue a pull request to the SpringSource repository (for more detail, see https://help.github.com/articles/using-pull-requests/[Using pull requests]).
64
+
* The project lead may merge your changes into the upstream master branch as-is, he may keep the pull request open yet add a comment about something that should be modified, or he might reject the pull request by closing it.
72
65
* A prerequisite for any pull request is that it will be cleanly merge-able with the upstream master's current state.
73
66
**This is the responsibility of any contributor.**
74
-
If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make
75
-
it merge-able.
67
+
If your pull request cannot be applied cleanly, the project lead will most likely add a comment requesting that you make it merge-able.
76
68
For a full explanation, see http://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing].
77
-
As stated there: _"> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a
78
-
project to which you’re trying to contribute but that you don’t maintain."_
69
+
As stated there: _"> Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain."_
79
70
80
71
== Keeping your Local Code in Sync
81
-
* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want
82
-
to always keep your own 'origin' master branch in synch with the 'upstream' master.
72
+
73
+
* As mentioned above, you should always work on topic branches (since 'master' is a moving target). However, you do want to always keep your own 'origin' master branch in synch with the 'upstream' master.
83
74
* Within your local working directory, you can sync up all remotes' branches with: `git fetch --all`
84
-
* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master
85
-
and merging that into the branch you are in currently)
86
-
* Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b INT-123`
75
+
* While on your own local master branch: `git pull upstream master` (which is the equivalent of fetching upstream/master and merging that into the branch you are in currently)
76
+
* Now that you're in synch, switch to the topic branch where you plan to work, e.g.: `git checkout -b GH-123`
87
77
* When you get to a stopping point: `git commit`
88
-
* If changes have occurred on the upstream/master while you were working you can synch again:
78
+
* If changes have occurred on the upstream/master while you were working you can sync again:
89
79
- Switch back to master: `git checkout master`
90
80
- Then: `git pull upstream master`
91
-
- Switch back to the topic branch: `git checkout INT-123` (no -b needed since the branch already exists)
92
-
- Rebase the topic branch to minimize the distance between it and your recently synched master branch: `git rebase master`
81
+
- Switch back to the topic branch: `git checkout GH-123` (no -b needed since the branch already exists)
82
+
- Rebase the topic branch to minimize the distance between it and your recently synced master branch: `git rebase master`
93
83
(Again, for more detail see http://git-scm.com/book/en/Git-Branching-Rebasing[the Pro Git section on rebasing]).
94
84
* **Note** While it is generally recommended to __not__ re-write history by using `push --force`, and we do not do this on `master` (and release) branches in the main repo, we require topic branches for pull requests to be rebased before merging, in order to maintain a clean timeline and avoid "merge" commits.
95
85
* If, while rebasing for the merge, we find significant conflicts, we may ask you to rebase and `push --force` to your topic branch after resolving the conflicts.
96
-
* Assuming your pull request is merged into the 'upstream' master, you will end up pulling that change into
97
-
your own master eventually and, at that time, you may decide to delete the topic branch from your local repository and
98
-
your fork (origin) if you pushed it there.
99
-
- to delete the local branch: `git branch -d INT-123`
100
-
- to delete the branch from your origin: `git push origin :INT-123`
86
+
* Assuming your pull request is merged into the 'upstream' master, you will end up pulling that change into your own master eventually and, at that time, you may decide to delete the topic branch from your local repository and your fork (origin) if you pushed it there.
87
+
- to delete the local branch: `git branch -d GH-123`
88
+
- to delete the branch from your origin: `git push origin :GH-123`
@@ -197,23 +186,17 @@ or locally for the *spring-integration* repository only by omitting the '--globa
197
186
198
187
== Run all tests prior to submission
199
188
200
-
See the https://github.com/spring-projects/spring-integration#checking-out-and-building[checking out and building]
201
-
section of the README for instructions.
189
+
See the https://github.com/spring-projects/spring-integration#checking-out-and-building[checking out and building] section of the README for instructions.
202
190
Make sure that all tests pass prior to submitting your pull request.
203
191
204
-
== Mention your pull request on the associated JIRA issue
205
-
206
-
Add a comment to the associated JIRA issue(s) linking to your new pull request.
192
+
== Provide a Link to the GitHub issue in the Associated Pull Request
207
193
208
-
== Provide a Link to the JIRA issue in the Associated Pull Request
209
-
210
-
Add a JIRA issue link to your first commit comment of the pull request on the last line, so your commit message
211
-
may look like this:
194
+
Add a GitHub issue link to your first commit comment of the pull request on the last line, so your commit message may look like this:
* some refactoring for `IntegrationEvaluationContextFactoryBean`
223
206
* polishing some failed tests after this change
224
207
----
208
+
209
+
Please, follow Chris Beams' recommendations in regards to the good commit message: https://chris.beams.io/posts/git-commit[How to Write a Git Commit Message].
0 commit comments