Page History

Code contributions

All changes to the Geode codebase are tracked via the via ASF JIRA. Anybody contributing to Geode is highly encouraged to create a JIRA issue describing the nature of the contribution. Remember that even if you start with sending us a pull request, ASF JIRA will be required anyway.

When submitting actual code to Apache Geode in a the form of a patch, contributors have pretty much two alternatives: GitHub pull request or a git-format patch attached to a JIRA ticket.
This document covers the steps for GitHub pull requests, but if a contributor decides to go the JIRA + Attachement Attachment route, the review step of this document should still apply.

Using GitHub

1. Fork the Apache Geode mirror project on GitHub
    

   Code Block
   [img]

   - https://github.com/apache/geode

   
   Image Added

   
   

   
   

2. Clone the apache repository Clone your fork locally so you can actually start working.:

   Code Block
   git clone https://github.com/markitoapache/incubator-geode

   
   

3. After cloning add your fork as an upstream additional remote so your fork can actually reference the original Apache Geode repository.you can push code to your fork. Substitute your GitHub username for 'markito' in this example, or use the GitHub 'HTTPS Clone URL':

   Code Block
   cd geode git remote add upstreammyfork https://github.com/apachemarkito/incubator-geode

   
   

4. Your git remote should look like the following:

   Code Block
   git remote -v origin https://github.com/markitoapache/incubator-geode (fetch) origin https://github.com/markitoapache/incubator-geode (push) upstream myfork https://github.com/apachemarkito/incubator-geode (fetch) upstream myfork https://github.com/apachemarkito/incubator-geode (push)

   
   

5. Create a local develop branch (develop is where all new development work goes).

   Code Block

   Fetch remote branches and checkout develop

   Code Block
   git fetch upstream # update your local branch git checkout develop

6. Geode follows git-flow conventions so if you do have git-flow installed in your system just do:

   Code Block
   git flow init

7. 
   

8. Then create your feature branch with the number of the JIRA task that describes your work (fix/feature). You can call the branch whatever your want (it's your fork!) but the convention is to use feature/GEODE-XXX.

   Code Block
   git flowcheckout feature start GEODE-41 Switched to a new branch 'develop git pull git checkout -b feature/GEODE-41' Summary of actions: - A new branch 'feature/GEODE-41' was created, based on 'develop' - You are now on branch 'feature/GEODE-41' Now, start committing on your feature. When done, use: git flow feature finish GEODE-41

9. Complete your work (commits) and in order to update the ticket with your progress use the following syntax in your commit messages:

   Code Block
   git commit -a -m "[GEODE-41] #comment My new cool feature XYZ"

10. 
    
    

11. Before committing and pushing your work, run the code formatter to format your code according to geode conventions

    Code Block
    ./gradlew spA

    
    

12. Run any relevant tests and the basic build against your changes

    Code Block
    ./gradlew build

    
    

13. Complete your work and commit it.

    Code Block
    git commit -a

    
    Follow the guidelines for good commit messages. Here's an example:

    No Format
    GEODE-526: Fix oplog unit test race condition KRF files are created asynchronously. The test needs to wait for the files to be created before checking header content.

    Execute the precheckin gradle task in order to perform tests related to the components affected by your change. All tests must pass. When in doubt ask on @dev list.

    Code Block
    ./gradlew build

    
    

14. When work is complete, consider whether documentation needs to be updated or created due to the new feature.

15. If/When needed to push your local work to GitHub use the following command:

    Code Block
    git push --set-upstream originu myfork feature/GEODE-41

    
    

16. Open the GitHub web inteface and interface and you should see your just-pushed branch with a 'Compare & pull request' button:
    
    
    
    

17. This will lead to the Open a pull request page with detailed information on which fork and branch you going from/to. You should add some descriptive information, if needed, and finally click on Create pull request
    Image Removed  . Once your PR is created, the CI system will run checks against your PR, which may take a couple of hours. You may want to create your PR as a draft PR so that you can see if your PR passes the checks before opening it up for review.  All checks must pass before your PR can be merged.
    
    Image Added

    
    

The review process starts

...

. Once approved, your PR will be need to be merged into develop.

...

If it's not approved or

...

requires some additional work, make changes and go back to the commit step.

...

Now you can go ahead and finish your feature

...

Accepting

...

a Pull-request

...

Once the PR is approved

...

,

...

if you are a committer, you can just merge the PR using the Merge button at the bottom of the pull request. Click the arrow next to the merge button and select the appropriate merge choice (Usually squash and merge to create a single commit on develop).
Image Added

Website publishing

The

...

Clone the ASF git repository (if you haven't done yet)

 git clone https://git-wip-us.apache.org/repos/asf/incubator-geode.git

...

Add GitHub remote

 git remote add github https://github.com/apache/incubator-geode

...

(for local review) Fetch the pull request into a feature branch for review

 git fetch github pull/6/head:feature/GEODE-41
git checkout feature/GEODE-41
Where:
6 -> PR number
feature/GEODE-41 -> local destination branch

...

(for local review) After review is complete you can merge the feature into develop and remove the branch

 git flow feature finish GEODE-41 -F
Switched to branch 'develop'
Your branch is up-to-date with 'origin/develop'.
Updating f7af251..1f2e32a
Fast-forward
COMPILING.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Deleted branch feature/GEODE-41 (was 1f2e32a).
Summary of actions:
- The feature branch 'feature/GEODE-41' was merged into 'develop'
- Feature branch 'feature/GEODE-41' has been removed
- You are now on branch 'develop'

...

(if review was done through GitHub) Pull and squash the pull request

 git pull --squash github pull/6/head

...

 git commit --amend

Finally push the commit the origin repository

 git push origin

...

commit c562d3439577c0bf12cc0e39157761a8dd69da1f
Author: Dan Smith <dsmith@pivotal.io>
Commit: William Markito <wmarkito@pivotal.io>

Rejecting PRs without committing

If reviewers or committers needs to close a PR if for instance, after proper evaluation it's something that won't get fixed it can be done through an empty commit message

git commit --allow-empty -m "Closes #6 *Won't fix*"
git push github develop

Website publishing

Geode website is maintained as part of the repository under the gemfire, within the geode-site/ folder. We use JBake template management system to turn markdown (.md) templates into static html pages. Those static html pages can then be published as http://geode.incubator.apache.org by committing them to a dedicated publishing branch in Geode's repo: asf-site. The whole process is automated using Gradle tasks and consists of the following steps: 

...

Edit the content in a usual manner (md files are located under src/jbake/content)

...

Take a look at you changed by building and running the website via:
   $ gradle jbakeRun
and navigating to: http://localhost:8820

...

If you're satisfied with the result make sure to commit the changes to md files to the develop branch

...

 directory. Instructions for updating the website are in the geode-site/website/README.md file.