Open source cheat sheet

1. 1How open source worksLicences, maintainers, contributing guides and codes of conduct. Most rejected first pull requests break a norm, not a test.9 concepts

   1. 1Open source licenceThe legal terms that let anyone use, change and share a project's code.
   2. 2Permissive licenceA licence that allows almost any use, including in closed source products, as long as you keep the copyright notice.
   3. 3Copyleft licenceA licence requiring that modified versions you distribute are shared under the same licence.
   4. 4MaintainersThe people who review and merge changes, triage issues, cut releases and set a project's direction.
   5. 5Project governanceHow a project makes decisions: a single lead (sometimes called a BDFL), a core team or steering committee, or a foundation such as the Apache Software…
   6. 6Contributing guideA file, usually CONTRIBUTING.md, explaining how to set up the project, which issues to pick, coding style, tests to run, commit rules and how pull requests…
   7. 7Code of conductA document setting expected behaviour in a project's spaces and how to report problems.
   8. 8CLA and DCOAgreements some projects require before merging.
   9. 9Why people contributeCommon reasons include fixing a bug that affects you, learning from experienced reviewers, building a public track record, and companies maintaining software…

   9 in this chapterOpen this chapter
2. 2Git and GitHub for contributorsWorking in a repository you do not own: forks, branches, keeping in sync with upstream, rebasing and readable commits.10 concepts

   1. 1ForkYour own copy of someone else's repository on GitHub, where you can push branches without write access to the original.
   2. 2Origin and upstreamConventional remote names: origin points to your fork, upstream points to the original project you forked from.
   3. 3Feature branchA short-lived branch created from the latest upstream main for one change, named after what it does.
   4. 4Keeping a fork in syncBringing new commits from upstream into your fork and branches, by fetching upstream and rebasing or merging.
   5. 5RebaseReplaying your branch's commits on top of a newer base, such as the latest upstream main, which rewrites their history.
   6. 6Merge conflictWhen Git cannot combine changes automatically because two commits edited the same lines, and it marks the file for you to resolve by hand.
   7. 7Good commit messageA short imperative subject line of about 50 characters, a blank line, then a body explaining what changed and why.
   8. 8Conventional CommitsA commit message convention with a type prefix such as feat:, fix: or docs:, an optional scope, and BREAKING CHANGE for incompatible changes.
   9. 9Squashing and force-pushingCombining several commits into one, for example with interactive rebase, then updating your remote branch with a force push because history changed.
   10. 10Everyday Git commandsThe commands used constantly while contributing: status, diff, add -p, stash, log --oneline and restore.

   10 in this chapterOpen this chapter
3. Your first merged pull requestGet a small change merged. Documentation, tests and labelled beginner issues are where maintainers expect newcomers.9 conceptsOpens with credits
4. Becoming a regular on one projectCommit to one project for months: read the code, triage issues, review others and join discussions until maintainers know your name.7 conceptsOpens with credits
5. Mentored programmesFixed-length, usually paid projects with maintainers as mentors. Learn the timelines, pick early and back your proposal with real contributions.8 conceptsOpens with credits
6. Maintaining your own projectRun a small project the way good maintainers do: a clear README, a licence, CI, templates, releases and a path for contributors.8 conceptsOpens with credits
7. 7Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.143 terms

First contribution to programmes.