Learn the natural collocations for forking, cloning, submitting, and maintaining open-source projects.
0 / 5 completed
1 / 5
The first step to contributing to an open-source project is to ___ the repository to your own GitHub account.
Fork a repository is the standard GitHub/Git collocation for creating a personal copy of an open-source project to contribute to. 'Clone' creates a local copy without a fork. 'Copy over' and 'split off' are not standard Git terms.
2 / 5
After forking, you need to ___ the repository locally before making any changes.
Clone a repository is the git command and standard collocation for creating a local working copy. 'Copy down' and 'download into' are informal. 'Pull over' is not a Git term (you 'pull' changes, but 'pull over' means something different).
3 / 5
Once your changes are ready, you can ___ a pull request to the upstream repository.
Submit a pull request is the standard open-source collocation for formally requesting that your changes be merged. 'Open a PR' is also common. 'Push in' and 'create along' are not standard collocations.
4 / 5
The maintainer decided to ___ the pull request after a thorough code review.
Merge a pull request is the standard Git/GitHub collocation for integrating changes from a PR into the main branch. 'Accept in' is informal. 'Join into' and 'combine along' are not used in version control contexts.
5 / 5
The organisation committed to actively ___ the open-source library they depended on.
Maintain an open-source project is the standard collocation for long-term stewardship — triaging issues, reviewing PRs, and releasing updates. 'Look after' is informal. 'Keep running' implies availability. 'Service' applies to hardware or contracts.