...

$ mvn clean install

----------------------------------

or, if you want to build the kits and run the integration tests, add the "integration" profile:

$ mvn clean install -Pintegration

NOTE: We didn't include the "-s settings.xml" argument on this or any other Maven commands shown on this page. We've assumed that you've modified your Maven settings. If you didn't, you will probably need to add this argument to all your Maven commands. If you get an error stating that some artifacts cannot be found, this is the reason.

If you need to make more changes, be sure to stage them and re-build.

Committing

Once everything builds, you can then commit your changes to this branch. There are various ways to commit, but this form will commit those changes you've staged and launches the editor where you can type out your commit message: 

$ git commit

Be sure to use an appropriate comment. The first line should list issue numbers and a summary sentence; additional paragraphs describe the commit in more detail. (See ModeShape Development Guidelines.)

If you think it makes sense to commit multiple times on your topic branch, then feel free to do so. Having multiple commits on a topic branch is perfectly fine for large changes. However, if your topic branch only contains a small number of changes (e.g., fixing a bug in one class and then adding or changing a test case), then we do prefer it is preferred that they all be made in a single commit. You can create multiple commits and then squash them before pushing to your fork, but it is often easier to create the first commit as usual but then to amend that commit with subsequent changes: 

$ git commit --amend

This will modify the previous commit to include the staged changes. Obviously, you should only amend your own commits on your topic branch - never amend a commit that on an official branch.

Rebasing

...

If you 've have been working on this branch for a while, we other changes may have been merged other changes (from other pull-requests) into the upstream repository. Often times this is okay, as we can deal with overlaps like this. However, sometimes your local change will be affected by recent merges. It 's is best to make sure that you update your local clone before you create your pull-request.

 

To do this, switch to the "master" branch, have Git obtain all recent commits, and then update your branch: 

Code Block
$ git

...

checkout master # switches to the 'master' branch

...

$ git pull

...

upstream master # fetches all 'upstream' changes and

...

merges # 'upstream/master' onto your 'master' branch

...

$ git checkout fcrepo-

...

$ git rebase master            # reapplies your changes on top of the latest

...

1234 # switches to your topic branch $ git rebase master # reapplies your changes on top of the latest # in master (i.e., the latest from master

...

will # be the new base for your changes)

                               # be the new base for your changes)

 

At this point, your "fcrepo-1234" branch has been updated (rebased), and you can proceed. 

NOTE: Do not ever merge these topic branches onto other official branches, even on your fork repository. That's our job. If you do that, your "master" branch (or any other official branch) will no longer reflect the official repository.

 

 

Push Changes

After you 've have committed changes locally (and pulled from upstream), you can commit your changes to your fork repository and generate a pull-request. Pushing the changes is easy: 

$ git push origin fcrepo-1234

This will push the commits on 'fcrepo-1234' up to the 'origin' repository (which is your fork on GitHub). 

Create Pull-Request

After pushing your changes into your GitHub fork, you 've have published your changes but haven't have not really told the ModeShape Fedora community about them. To do this, generate a pull-request on GitHub; if you're . If your commits are on a branch other than 'master', be sure to update the commit range (changing 'master' to the correct branch name). Then record this on the JIRA issue "Workflow -> Link Pull Request" actionPivotal ticket, and use the URL to the pull-request and include a good comment that describes your changes. 

NOTE: If you use good commit descripitons descriptions and fill out a good pull-request description, then you can just paste the same description as the JIRA Pivotal comment (without the summary line). 

Meanwhile, one of ModeShapeFedora's integration managers will be notified of your new pull-request. The role of an integration manager is to review the incoming pull-requests and decide whether and they should be accepted and on which branch(es) they should be merged. As such, only a few people have this responsibility.

An integration manager will review your request within a few days, and often much faster. They 'll will comment on your pull-request via the discussion or line nodes. If they like what they see, they 'll will merge your proposed changes into the correct branch(es). However, they may like to see additional changes, in which case they 'll will describe in the pull-request discussion area (or in line notes) what they 'd would like you to change. If you disagree, just use the discussion area. Otherwise, go back to your local topic branch for this issue, make the requested changes, commit them locally, and push them to same branch in your fork repository (using the same commands as before). As long as you 're are on the same branch (not simply named the same, but actually the same branch), GitHub will automatically update the pull-request with your additional commit(s) and notify the integration managers again. Once they 're are acceptable, the integration managers will merge your commits into the upstream repository.

The aforementioned process adds your new commits to the pull-request. But sometimes, the integration managers will request just a few smaller changes, and making a separate commit for those small changes is less desirable. Instead, in this case we suggest that you make the changes and then amend your previous commit. This helps keep related changes in fewer commits, and makes it easier to apply the changes to other branches. Yes, amended commits actually do change history, so be sure to do this only with commits that appear only on a topic branch. We think it It is perfectly acceptable (and sometimes preferable) to amend/change the commits on a pull request before it is merged onto an official branch (before this, a PR is really "proposed code"). The procedure is pretty straightforward. On your local branch (e.g., "fcrepo-1234") that you used to push to your fork (e.g., "origin") and create the PR, make any additional changes to the code and then: 

$ git commit --amend .

...

$ git push -f origin fcrepo-1234

GitHub will automatically update the pull-request, where it can be reviewed once again.

Cleanup

There 's is actually nothing else you need to do. However, you may want to periodically clean up the topic branches that are no longer needed. (Note that if you want to make additional changes on a topic branch and have them go into the original pull-request, don't do not delete the topic branch in your local repository or your fork repository on GitHub.)

This command will delete a local topic branch: 

$ git branch -D fcrepo-1234

while this This command deletes the remote branch in your fork repository on GitHub: 

$ git push origin :fcrepo-1234

...

At first blush, the syntax of this second command is a little strange. It 's is actually a form of the "git push <remote> <localBranch>:<remoteBranch>" command. If you don't do not specify the local branch, this basically means push nothing onto the remote branch, and Git removes the remote branch.

The reviewer should:

...