:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
The following is a set of guidelines for contributing to NodeMCU on GitHub. These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
It is appreciated but optional if you raise an issue before you start changing NodeMCU, discussing the proposed change; emphasising that the you are proposing to develop the patch yourself, and outling the strategy for implementation. This type of discussion is what we should be doing on the issues list and it is better to do this before or in parallel to developing the patch rather than having «you should have done it this way» type of feedback on the PR itself.
Use the platform and tools you feel most comfortable with. There are no constraints imposed by this project. You have (at least) two options to set up the toolchain to build the NodeMCU firmware:
Pull requests for new features and major fixes should be opened against the dev
branch.
Avoid intermediate merge commits. Rebase your feature branch onto dev
to pull updates and verify your local changes against them before placing the pull request.
dev
branch.git clone https://github.com/<your-account>/<nodemcu-fork>.git
cd <nodemcu-fork>
then run git remote add upstream https://github.com/nodemcu/nodemcu-firmware.git
git checkout <branch-name>
git commit -a -m 'Look ma, I did it'
dev
running git rebase dev
.git push
This is just one way of doing things. If you’re proficient in Git matters you’re free to choose your own. If you want to read more then the GitHub chapter in the Git book is a way to start. GitHub’s own documenation contains a wealth of information as well.
You need to sync your fork with the NodeMCU upstream repository from time to time, latest before you rebase (see flow above).
git fetch upstream
git checkout dev
but you may do this for master
as wellgit merge upstream/dev
From: http://git-scm.com/book/ch5-2.html
Short (50 chars or less) summary of changesMore detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together.
Further paragraphs come after blank lines.
Bullet points are okay, too
Typically a hyphen or asterisk is used for the bullet, preceded by a single space, with blank lines in between, but conventions vary here
Don’t forget to reference affected issues in the commit message to have them closed automatically on GitHub.
Amend your commit messages if necessary to make sure what the world sees on GitHub is as expressive and meaningful as possible.