Skip to content

Latest commit

 

History

History
105 lines (83 loc) · 3.87 KB

5.workflow.md

File metadata and controls

105 lines (83 loc) · 3.87 KB
Raw

Collaborative workflow via github (pull requests and code reviews)

What does branching mean?

https://learngitbranching.js.org/

https://learngitbranching.js.org/?NODEMO

  • Create a new branch locally from your main
$ cd scikit-learn
$ git status
$ git branch my-awesome-branch
$ git status
$ git checkout my-awesome-branch
$ git status

  • Make your modifications and commit

  • Check that the remote repository named origin points to your own github fork:

git remote --verbose
  • Push the new branch to your fork:
$ git push origin my-awesome-branch
  • From the github interface open a Pull Request (PR) to the main branch of your own scikit-learn fork. Please do not open the PR to the scikit-learn/scikit-learn main repository at this point!

When a contributor opens a pull request it will show up in the list of open pull requests at:

https://github.com/scikit-learn/scikit-learn/pulls

This will start a review process where anybody (and hopefully project maintainers in particular) can start reviewing the diff of the files changed by the PR.

The original contributors can then take those comments into account by making further changes as new commits in the same branch.

When those commits are pushed to his or her fork, the PR github is automatically updated to aggregate those changes.

The reviewers typically check that:

  • the change is actually implementing what is described in the title and description of the pull request or a related github issue referenced in the PR description or a referenced paper from the scientific literature.

  • if the change implements a new feature, the maintainers first discuss if this falls under the scope of the scikit-learn project.

  • the tests are properly updated to demonstrate that the code works as its supposed to and the tests pass with all supported version of Python, numpy, scipy... and on all 3 supported Operating Systems (Windows, macOS and Linux). More on this point in the next section on Continuous Integration.

  • the documentation and examples related to the change have been properly updated.

  • the code is correct, easy to understand, efficient enough to execute and consistent with the rest of the code base. To ensure style consistency the project follows the PEP8 code style conventions.

Once a consensus emerges among the reviewers and the contributors, and no comment is left unaddressed, maintainers can merge the commits from the contributor's branch into the main branch of the project (the main branch).

How to take over stalled PRs

Sometimes you want to take over stalled PRs. In general a lot of work has already been done by previous contributors and it is fair to have their name in the commit history.

Assuming the stalled PR comes from the some-modifications branch of the some-contributor github user, the workflow is:

$ git remote add other-contributor https://github.com/some-contributor/scikit-learn.git
$ git fetch other-contributor
$ git checkout -b my-modifications -t other-contributor/some-modifications

Once pulled the stalled PR, the new branch should be synchronized with the upstream main branch: you can do that merging upstream/main into the new branch. Assuming your main branch even with scikit-learn/scikit-learn, run

$ git merge main

You don't have push rights on other contributors fork, so you need to push to your fork either specifying your remote at each push

git push origin my-modifications

or setting once for all your origin for this branch

git push --set-upstream origin my-modifications

Now you are ready to open a new Pull Request: please, refer to the old one in describing your PR, using "Resolve" or "Close" the old PR will automatically close it when yours is merged (like issues).