UIMA project logo
GIT work process
Apache UIMA

Search the site

 Git Work Process

This describes the normal way you work on a UIMA project as a contributor.

Preliminaries

You may be working on a feature or a bug fix. These are similar, except typically, features may be worked on over a longer period.

A preliminary step: Sign up for a github.com account, if you don't already have one.

Fork the repo (if not a committer)

The first step is to fork the project on githhub. To do this, point your browser to the repository, and press the fork button.

fork button

This will fork (create a writable-by-you) copy of the repo, in your personal github account.

If you are a committer, skip ahead to Make a branch. You can make the branch on the github.com website by first switching (if needed) the branch you'll be branching from (e.g. master, or master-v2, etc.), and then typing the name of the new branch in the Branch pulldown.

Clone the fork

Next, clone the fork to your local development machine. After the above step, your browser should be positioned at the forked repository. Click the green clone-or-download button near the top, and proceed to clone this repo. For example you could copy the link starting with "https://github.com..." to the clipboard, and then open a command line and CD to a directory where you keep your clones, and then use the git command git clone https://github.com... (paste the address into the command).

Make a branch

Next, make a branch where you'll do the work. Name the branch with the name of the Jira issue ticket this work is being done for; e.g. "UIMA-6455", or some other name of your choosing. Then switch the checkout to that new branch. The git command to do these two steps in one command is git checkout -b the-new-branch-name

The reason to work in a branch is to keep changes related to one issue separate from other work. If you were also not working on a fork, but on the main project, this practice would also separate the changes from the "production-ready" master branch, until things have been reviewed and tested.

Make your changes

Now make your changes. You can commit the changes as you desire, and push them to your forked copy.

Commit / push your changes

When you're ready to have others look at the changes and give feedback, and eventually accept them into the official project, commit the changes and push them to your fork (if not already done).

Open a pull request

Then open a pull request. If you don't see a Create pull request Create pull request button button, click on the Pull requests tab pull requests tab and on the next screen press the New pull request button New pull request button.

Follow the instructions to complete and submit the pull request.

Iterate to resolve any issues

At that point, the reviewers/committers on the project will take a look at your proposed changes, and perhaps give feedback. Work with them to resolve any issues. When the change is OK, a committer will pull this change into the master branch.