Proposed workflow

This is a proposed workflow for using Git with an Apache codebase. This workflow is mainly targeted to contributors who don't already have commit access to a project.

Once you have cloned or pulled the latest changes to your local Git repository of an Apache codebase, you can start working on it. Whenever you make some changes to the codebase, it's good to have a related issue filed in the issue tracker of the project and to use a similarly named branch in your Git repository. For example, to create a branch for an issue with the key TIKA-123:

git branch TIKA-123 origin/trunk

With per-issue branches you can easily switch back and forth between different issues without worrying about unwanted side-effects from unfinished changes to other issues. Whenever you want to work on the TIKA-123 example issue, simply checkout that branch and start making your changes:

git checkout TIKA-123

It's a good idea to commit your changes whenever you have finished one logical part of the issue. For example when refactoring, make a new commit for each refactoring step you take:

git commit

Once you're ready to share your changes with the rest of the project team, you can use the git format-patch command to produce a nice set of patches to attach to the relevant issue:

git format-patch origin/trunk

The sooner you share your work the better. You can repeat the steps of this workflow as often as you like, producing more patches to be attached to the issue tracker. Once some of your patches are accepted and committed to svn, you can rebase your work against the latest trunk. Alternatively, if you're asked to make some changes, you can go back to the original Git commit and modify it until the project team accepts your changes.