...
All changes should be made on topic branches, typically named according to the PivotalTracker issueJIRA issue. (Recommended naming convention "fcrepo-xxxx".) There is nothing special about a "topic" branch -- it is just a normal Git branch that you create and use for a specific topic (i.e., Pivotal issueJIRA issue).
NOTE: Pull-requests that use the 'master' branch will not be accepted, even in your fork repository. There are too many things that can go wrong. Firstly, doing so will make it difficult to work on more than one (independent) set of changes at a time; working on 'master' will make your second set of changes dependent upon the first set of changes. Secondly, GitHub pull-requests are tied to branches, so GitHub will want to include all your commits into the same pull-request. Thirdly (and perhaps most importantly), if your commits are not approved, your 'master' branch history will have commits that don't actually appear in the official 'master' branch, and this could be problematic in the future. The 'master' branch in your fork should really be just the local branch that represents the official repository's 'master' branch - use it to pull changes from upstream and merge/rebase onto your topic branches.
...
| No Format |
|---|
Address invisible resources during transactions - Disable Last-Modified and Etag headers during transactions Resolves: https://wwwjira.pivotaltrackerduraspace.comorg/story/show/67755044 browse/FCREPO-1234 |
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 it is preferred that they all be made in a single commit.
...
After pushing your changes into your GitHub fork, you have published your changes but have not really told the Fedora community about them. To do this, generate a pull-request on GitHub. 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 Pivotal ticketJIRA ticket, and use the URL to the pull-request and include a good comment that describes your changes. Finish the Pivotal ticketJIRA ticket; the ticket will then be ready to deliver, and the integration managers will be alerted that you have a pull request outstanding.
NOTE: If you use good commit descriptions and fill out a good pull-request description, then you can just paste the same description as the Pivotal comment JIRA comment (without the summary line).
After the ticket is put "FinishedIn Review", one of Fedora'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 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 will comment on your pull-request via the discussion or line notes, or in the Pivotal ticketJIRA ticket. If they like what they see, they will merge your proposed changes into the correct branch(es), then "Deliver" and "AcceptClose" your Pivotal ticketJIRA ticket. However, they may like to see additional changes, in which case they will describe in the pull-request discussion area (or in line notes, or Pivotal ticketJIRA ticket) what they would like you to change, and "Reject" the ticket, to indicate to the ticket owner that the ball is back in their court. 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 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. Finish the Pivotal ticket JIRA ticket again. Once the changes are accepted, the integration managers will merge your commits into the upstream repository.
...