...

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.offer a brief description of the change (less than 50 characters), followed by an empty line, followed by a more detailed description on one or more lines (each line not to exceed 72 characters), followed by an empty line, followed by "Resolves: <ticket URL>"

Address invisible resources during transactions

- Disable Last-Modified and Etag headers during transactions

Resolves: https://www.pivotaltracker.com/story/show/67755044 

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 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. 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

Note: After a pull-request has been submitted (see below), subsequent commits (based on response to code review comments) should be pushed to the same development branch so that they will automatically be added to the pull-request. Do not squash or amend subsequent commits into your original pull-request commits because it makes finding the deltas much more difficult for the code reviewerThis 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 have been working on this branch for a while, other changes may have been merged (from other pull-requests) into the upstream repository. Often times this is okay. However, sometimes your local change will be affected by recent merges. It is best to make sure that you update your local clone before you create your pull-request.

...