You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

WIP

 

 

Bootstrapping (need to be done only once)

You will not have write permission to github apache mirror, you need to
fork https://github.com/apache/incubator-netbeans to your own repositories.

You need to clone the forked repository and setup name and mail. This also may help git rebase to fullfil its task.

git config --global user.name "John Doe"
git config --global user.email "john@doe.org"

--global  can be removed if you want to setup only the current repository.

Use branches

You now want to create a Pull Request for a fix or a new feature. Pull Request are not fixed in time. I you change your history the PR will be impacted.

 A PR will be reviewed by committers and they may ask you additional work.To easy your work it's better to create a branches per feature you want to submit as Pull Request.

Creating and pointing at  a new branch from master requires 3 steps

  1. git checkout master
  2. git branch mywork
  3. git checkout mywork

You can then code, commit and push to your forked repository. You can then use the github UI to create a Pull request from your branch.

https://help.github.com/articles/creating-a-pull-request/

You will need an ICLA (Individual Contributor License Agreement) for important modifications.

Commit message related to JIRA issue must start with [NETBEANS-<issue number>]

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:

#Commit
X
[NETBEANS-xxx] Improved YAML lexer
Improved ability for night vision and
the robustness on I/O errors.
Y
Oops, forgot to include lic file
Z
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.



 

Keeping your own fork in sync with Apache GitHub repo

<to be described :  possible link we can use: https://help.github.com/articles/syncing-a-fork/>

git fetch upstream
git checkout master
git merge upstream/master

Tip: Syncing your fork only updates your local copy of the repository. To update your fork on GitHub, you must push your changes

git push origin master

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>

 

 

 

 

 

 

 

 

 

  • No labels