...
PATCH AVAILABLE
state....
Instructions on how to build source and binary releases can be found at DEVNOTES.txt
. Please see "Ignite Release Instructions"
section. On how to make official release please refer to Release Process.
There are 3 way several ways how you can make contribution
...
+------------+ +---------------+ +-----------------+
...
git fetch upstream pull/<id>/head:pull-<id>-head
git merge --squash pull-<id>-head
git commit --author=“<saved_author>" -s -m “<comment> - Fixes #<id>.”
Now, you will have one commit at master with all changes from pull-request. Changes can be reviewed again. If you accept all changes and want to push it, do next:
git push apache master
You can start by cloning the Ignite GIT repo.
Info | ||
---|---|---|
| ||
git clone https://gitbox.apache.org/repos/asf/ignite.git |
We use git as our version control system. To streamline the process of giving proper credit to the contributors when committing patches, we encourage contributors to submit patches generated using "git format-patch"
command. This has many benefits:
Long story short, it makes both the contributors' and committers' lives easier, so please generate your patches using git format-patch
.
We have the following requirements for patches:
We prefer that you use the following step-by-step instructions when developing with Ignite.
For example, if you are starting working on the feature IGNITE-9999.
Code Block |
---|
## Get the repo
git clone https://github.com/apache/ignite.git
## Some development here with many commits at ignite-9999.
git commit -a -m 'ignite-9999: Intermediate commit 1';
...
git commit -a -m 'ignite-9999: Intermediate commit 100';
## Commit the last changes.
git commit -a -m 'ignite-9999: Implemented.';
## Making patch.
## There are a lot of changes at ignite-sprint-999 and we need to get it, resolve conflicts (if exists), rerun tests for ignite-9999.
git checkout master
git pull
git checkout ignite-9999
git merge master
## Run script to make patch. Patch will have all changes as one commit.
<ignite_home>/scripts/git-format-patch.sh |
Note: it is strongly recommended to merge 'master' branch to your development branch, for example, every day (or after each commit).
Created patch-file should be attached to a JIRA ticket and the ticket status should be changed on Patch Available.
If you do everything correctly, then all necessary TeamCity test builds will be triggered automatically in 3 minutes period, and a comment with triggered build information (test package names, TeamCity build links) will be added to the JIRA.
Once tests are passed, the patch can be reviewed and merged by a committer.
Requirements (to auto triggering the test builds):
Info | ||||
---|---|---|---|---|
| ||||
Note: All TeamCity test builds can be triggered manually via "Ignite/ -> Run All for patch" (by 'Jira number'). A comment will be added to the jira with all new triggered builds. |
Contributor patches have to be applied by next command.
git am -s <patch-file>
This command apply a patch file generated by 'git format-patch', stores information who created a patch and who applied a patch. So, it gives proper credit to the contributor and store an information who decide to take these changes.
If patch file has been created by scripts/git-format-patch.sh then a name of a patch-file contains a short hash revision of master branch revision against which patch has been created. Patch file template is
master_<hash>_ignite-<ticket-number>.patch
For example
master_b001525_ignite-9999.patch
So, in case, if a patch can't be applied without conflicts on the HEAD of master and the patch has been created by scripts/git-format-patch.sh then a commiter can apply the patch to master by a revision hash, review changes and resolve the conflicts by yourself.
...
Whenever working on bigger features, committers can also create 'ready to be reviewed' branch ignite-XXXX, where XXXX is the number of the JIRA ticket.
...