Collaboration Workflows and Open Source

Choosing a workflow

• GitHub Flow (recommended for web apps): main is always deployable; every change is a short-lived branch and a PR; merging deploys.
• Git Flow: long-lived develop and release branches. Useful for software shipped in versions, usually too heavy for web apps.
• Trunk-based: everyone merges to main at least daily behind feature flags. Fast, but needs strong tests.

Forks: contributing without write access

# fork on GitHub, then:
git clone git@github.com:you/project.git
git remote add upstream git@github.com:owner/project.git
git switch -c fix/typo-in-docs
# commit, push to your fork, open a PR to upstream
git fetch upstream && git rebase upstream/main   # stay current

Before contributing, read CONTRIBUTING.md, look for issues labelled good first issue, and comment that you are working on one so effort is not duplicated.

Issues and planning

• One issue per bug or feature, with steps to reproduce for bugs.
• Reference issues in commits and PRs: Fixes #42 closes issue 42 when merged.
• Use labels (bug, enhancement, security) and a project board (To do / In progress / Done) to see the state of work.

Semantic versioning

Version numbers MAJOR.MINOR.PATCH:

• PATCH (1.4.2): bug fixes only.
• MINOR (1.5.0): new features, nothing breaks.
• MAJOR (2.0.0): something that worked before may now break.

Licences, briefly

A public repository without a licence is not open source; others may not legally reuse it. MIT is permissive, GPL requires derivatives to stay open, and "all rights reserved" (no licence) suits code you sell, like the premium projects in the PandaDev portfolio.

Check yourself

• What does Fixes #42 in a PR do?
• Which version number changes for a breaking change?
• What is the upstream remote for?