Page History

...

Squashing commits on a Pull Request

Before submitting your Pull Request it should ideally consist of a single commit only. Consider you've done the following on your branch:

[NETBEANS-xxx] Improved YAML lexer

Improved ability for night vision and
the robustness on I/O errors.

Oops, forgot to include lic file

Javadoc update - corrected spelling

If the PR is merged into master as-is then all these commits will be in the master too, forever. Therefore, in this example, all three commits should be squashed into one so that only X is left.

<How to squash guide here>

After submission (and certainly after someone starts reviewing the PR) you shouldn't touch the PR's history. <squashing: to be described ....>

Keeping your own fork in sync with Apache GitHub repo

<to be described>

Updating a stale Pull Request

Over time your Pull Request is likely to go stale. A "stale" pull request is one that is no longer up to date with the main line of development, and it needs to be updated before it can be merged into the project. This typically happens because there's meanwhile been changes in main branch on the same files that are included in the PR, thus resulting in a merge conflict.

<to be described :  possible link we can use: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request>