This section explains how the community can contribute code to Wechaty via pull requests. If you're interested in how committers handle them, see committing code.
Below, we are going to show how to create a GitHub pull request containing the changes for issue #xxxxx. By creating a fully-ready pull request, you will make the reviewer's job easier, meaning that your work is more likely to be merged into Wechaty.
After installing Git, the first thing you should do is setup your name and email:
user.name should be your real name, not your GitHub nick. GitHub
should know the email you use in the
user.email field, as this will be
used to associate your commits with your GitHub account.
When you have created your GitHub account, with the nick "GitHub_nick", and forked Wechaty's repository, create a local copy of your fork:
This will create a new directory "wechaty", containing a clone of your GitHub repository. The rest of the git commands on this page need to be run within the cloned directory, so switch to it now:
Your GitHub repository will be called "origin" in Git.
You should also setup
wechaty/wechaty as an "upstream" remote (that is, tell
git that the reference Wechaty repository was the source of your fork of it):
You can add other remotes similarly, for example:
When working on an issue, create a new branch for the work, and base that work
The -b flag creates a new branch for you locally. Don't hesitate to create new branches even for the smallest things - that's what they are there for.
If instead you were working for a fix on the 1.4 branch, you would do:
Assume the work is carried on the ticket_xxxxx branch. Make some changes and commit them:
When writing the commit message, follow the [commit message guidelines][committing-guidelines.md] to ease the work of the committer. If you're uncomfortable with English, try at least to describe precisely what the commit does.
If you need to do additional work on your branch, commit as often as necessary:
You can publish your work on GitHub by running:
When you go to your GitHub page, you will notice a new branch has been created.
If you are working on an GitHub issue, you should mention in the issue that your work is available from branch ticket_xxxxx of your GitHub repo. Include a link to your branch.
Note that the above branch is called a "topic branch" in Git parlance. You are
free to rewrite the history of this branch, by using
git rebase for
example. Other people shouldn't base their work on such a branch, because
their clone would become corrupt when you edit commits.
There are also "public branches". These are branches other people are supposed
to fork, so the history of these branches should never change. Good examples
of public branches are the
stable/A.B.x branches in the
When you think your work is ready to be pulled into Wechaty, you should create a pull request at GitHub. A good pull request means:
commits with one logical change in each,
well-formed messages for each commit: a summary line and then paragraphs wrapped at 72 characters thereafter,
documentation and tests, if needed -- actually tests are always needed, except for documentation changes.
The test suite must pass and the documentation must build without warnings.
Once you have created your pull request, you should add a comment in the related GitHub issue explaining what you've done. In particular, you should note the environment in which you ran the tests, for instance: "all tests pass under wechaty-puppet-mock".
Pull requests at GitHub have only two states: open and closed. The committer who will deal with your pull request has only two options: merge it or close it. For this reason, it isn't useful to make a pull request until the code is ready for merging -- or sufficiently close that a committer will finish it themselves.
In the example above, you created two commits, the "Fixed ticket_xxxxx" commit and "Added two more tests" commit.
We do not want to have the entire history of your working process in your repository. Your commit "Added two more tests" would be unhelpful noise. Instead, we would rather only have one commit containing all your work.
To rework the history of your branch you can squash the commits into one by using interactive rebase:
The HEAD~2 above is shorthand for two latest commits. The above command will open an editor showing the two commits, prefixed with the word "pick".
Change "pick" on the second line to "squash" instead. This will keep the first commit, and squash the second commit into the first one. Save and quit the editor. A second editor window should open, so you can reword the commit message for the commit now that it includes both your steps.
You can also use the "edit" option in rebase. This way you can change a single commit, for example to fix a typo in a docstring:
If your topic branch is already published at GitHub, for example if you're making minor changes to take into account a review, you will need to force-push the changes:
Note that this will rewrite history of ticket_xxxxx - if you check the commit hashes before and after the operation at GitHub you will notice that the commit hashes do not match anymore. This is acceptable, as the branch is a topic branch, and nobody should be basing their work on it.
When upstream (
wechaty/wechaty) has changed, you should rebase your work. To
do this, use:
The work is automatically rebased using the branch you forked on, in the
example case using
The rebase command removes all your local commits temporarily, applies the upstream commits, and then applies your local commits again on the work.
If there are merge conflicts, you will need to resolve them and then use
git rebase --continue. At any point you can use
git rebase --abort
to return to the original state.
Note that you want to rebase on upstream, not merge the upstream.
The reason for this is that by rebasing, your commits will always be on top of the upstream's work, not mixed in with the changes in the upstream. This way your branch will contain only commits related to its topic, which makes squashing easier.
It is unusual to get any non-trivial amount of code into core without changes requested by reviewers. In this case, it is often a good idea to add the changes as one incremental commit to your work. This allows the reviewer to easily check what changes you have done.
In this case, do the changes required by the reviewer. Commit as often as necessary. Before publishing the changes, rebase your work. If you added two commits, you would run:
Squash the second commit into the first. Write a commit message along the lines of:
Finally, push your work back to your GitHub repository. Since you didn't touch the public commits during the rebase, you should not need to force-push:
Your pull request should now contain the new commit too.
Note that the committer is likely to squash the review commit into the previous commit when committing the code.
One of the ways that developers can contribute to Wechaty is by reviewing patches. Those patches will typically exist as pull requests on GitHub and can be easily integrated into your local repository:
This will create a new branch and then apply the changes from the pull request to it. At this point you can run the tests or do anything else you need to do to investigate the quality of the patch.
- Work on GitHub if you can.
- Announce your work on the issue by linking to your GitHub pull request.
- When you have something ready, make a pull request.
- Make your pull requests as good as you can.
- When doing fixes to your work, use
git rebase -ito squash the commits.
- When upstream has changed, do
git fetch upstream; git rebase.
I have to credit Django doc authors, because this documentation page is inspired by, and mostly copy/pasted from Django contributing docs