Message-ID: <2110821577.35511.1408800486482.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_35510_63117764.1408800486482" ------=_Part_35510_63117764.1408800486482 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Please keep in mind, that pull reques= ts are the official way how make a code contribution. They help us by launc= hing an automatic verification, reviewing and accepting it preserving a cle= an changelog and the contributor's list for later releases.
We use the opensource platform Github= (github.com) for the active development, because it offers the possibility= code of pull requests for reviewing/staging contributions before merging t= hem without using patch files. Intermediate and final states are more or le= ss frequently pushed back to the Codehaus GIT repository.
You should be familar with Git to sen= d contributions as pull request.
Th= e developers are automatically informed on incoming pull requests, and a ve= rification is automatically launched by the build system to ensure compilat= ion, unit and integration tests work on defined platforms.
Here is a HOWTO to start from scratch= :
Make sure the existing tests pass
A basic tutorial how to handle reposi= tories on Github can be found here: https://help.github.com/articl= es/fork-a-repo.
The steps described below are use-cases for a quick start with practical= examples for contributing code to IzPack. They are kept simple especially = for users new to Git and Github.
The basic steps for a quick start are= :
Clone your repo to a local computer.
dd the official IzPack repository as remote, i.e. izpack, to easily pick up changes from it or reset the user repository=
with it's latest state:
In case you have already made changes= in your master branch, they can still be easily included in a newly create= d Git branch.
The changes in files to be included in the branch require these files to= be already added. If you added new files, use
to achieve this
After this launch:
which creates a new branch IZPACK-123= and activates it at once. The commands git branch and git checkout can be = combined to do these steps separately
The files can now be further edited o= r pushed to the user's repository add Github.
After you've finished your implementa= tion including all necessary tests, you can commit these changes locally wi= th a message best containing the issue I= D and title:
If you leave out the -m option you ca= n add a commit message interactively.
If you do several commits within the = same development branch just fixing the same things you worked on before, u= se
to leave a clean history behind. Be aware, that on accepting your pull r= equests later all your intermediate commit messages appear in the history a= nd might confuse other developers or an automatically generated changelog.<= /p>
from where you can create a pull requ= est using the Github web interface.
After your pull request has been acce= pted and merged by a developer, the temporary branch is always deleted in t= he official IzPack repository at Github.
At this stage, you can also delete it= locally:
For being sure changes can be really applied on a pull request next time= it is recommended to reset a current repository to the current development= state from time to time. Provided you already added the original izpack/iz= pack repository as a remote izpack, this can be done by
This way you avoi= d future merge conflicts to be manually resolved.