Feedback
Sign in./start

Site navigation

Theme

Learn

  • Roadmaps

Build

  • Projects
  • Developer Tools

Contribute

  • Open Source Projects
  • Issues
  • Reviews
  • First Contribution
  • BountiesSoon
  • Feedback

Prove

  • Builders

Ecosystem

  • Partners
  • Get Funded↗
  • HackathonsSoon
Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute. Prove.

Feedback welcome — open a GitHub issue.

Learn

RoadmapsStart Building

Build

ProjectsDeveloper Tools

Contribute

Open Source ProjectsIssuesReviewsFirst ContributionSupportFeedback

Prove

Builders Directory

Account

Sign in

Legal

PrivacyTermsCredits

© 2026 Pull // code MIT · curriculum CC BY-SA 4.0

PrivacyTermsCredits

lesson // bitcoin

Git & Open Source Workflow

Learn branching, pull requests, and how maintainers review contributions.

beginner4 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Use feature branches and pull requests confidently
  • Write clear commits that maintainers can review
  • Understand ACK / NACK culture in Bitcoin projects

study // plan

Lessons are primers. Start with Step 1 (required reading) when present, then follow the numbered steps in the article. Depth comes from primary sources, labs, reflection, and evidence.

Research on Bitcoin Search
Git workflowpull requestconventional commitsACK NACK

Step 1 // Required reading

Complete these before the numbered steps in the lesson body. Links are listed here once — not repeated below.

  • docsGitHub Flow
  • articleConventional Commits
  • docsBitcoin Core contributing

Reflection prompts

  1. Explain Git & Open Source Workflow to a teammate without jargon - what problem does it solve?
  2. What would break in production if you misunderstood Git & Open Source Workflow?
  3. Which BIP, book chapter, or Core doc is authoritative here, and what did you verify?

Lab // Practice PR hygiene

Complete Steps 2–4. Create a focused branch, make a clear commit, and draft a PR description (even if you only open it on a personal fork or keep it as a written draft).

evidence required

  • ·Branch name + commit message you used (paste or screenshot)
  • ·PR description answering problem / how tested / what to watch
  • ·Link to the CONTRIBUTING or GitHub Flow section you followed
  1. 01

    Worked mental model

    Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit the Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

  2. 02

    Hands-on habit

    Every protocol idea should be paired with one local experiment. That habit turns reading into builder instinct.

    1. Reproduce the happy path on regtest (or Polar for Lightning)
    2. Break it on purpose (wrong fee, expired invoice, offline peer)
    3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)
  3. 03

    Glossary check

    Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

  4. 04

    Resource order

    Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Open source Bitcoin work is collaboration under a microscope. Your code is not “done” when it runs on your laptop — it is done when reviewers can understand, test, and trust it.

Complete Step 1 // Required reading in the study plan above, then continue here.

Step 2 — Key terms and why this matters

TermMeaningWhere you use it
Feature branchShort-lived branch for one changeEvery contribution
Pull request (PR)Proposal to merge your branchReview and CI
ACK“I support this after review”Bitcoin Core–style review
NACK“I object,” with reasonsSame — silence is not approval

Analogy: A pull request is a work order: what changed, why it is safe, and how to verify it. Maintainers are inspectors protecting users’ money.

Bitcoin repositories move carefully. A confusing history or a PR that mixes five unrelated changes will stall.

Done when: You can explain branch, PR, ACK, and NACK without looking them up.

Step 3 — The daily loop (setup and practice)

Loading diagram…

Most contributions follow a short cycle from branch to reviewed merge.
git checkout -b fix/clarify-fee-docs
# ...edit files...
git add -p
git commit -m "docs: clarify fee estimation examples"
git push -u origin HEAD

Expected: A new remote branch exists; git log -1 --oneline shows a clear message.

Prefer messages that explain why:

  • Good: wallet: avoid double-counting change in balance
  • Weak: fix stuff

A strong PR description answers: (1) What problem? (2) How did you test? (3) What should reviewers watch for?

ACK / NACK

Silence is not approval. Expect technical pushback — it is normal.

Common mistakes

  • Opening a PR from main with dozens of unrelated commits
  • Force-pushing during active review without warning
  • Ignoring CI failures and asking for review anyway

Done when: You have created at least one focused branch with a clear commit on a machine you control.

Step 4 — Hands-on check (lab)

  1. Fork or clone a small Bitcoin-adjacent repo (or use your own).
  2. Fix a typo or docs issue on a feature branch.
  3. Commit with a conventional-style message.
  4. Open a PR or paste a full PR description as lab evidence.

Done when: Lab evidence includes branch/commit + PR text + which required guide you followed.

Next lesson

With Git habits in place, study the Cryptography Primer — hashes, key pairs, ECDSA, and Schnorr.

review // club

Review club

Practice on real Bitcoin OSS changes tied to this chapter. Read the diff, use the checklist, and optionally paste your review comment URL in your lab notes.

  • Bitcoin Core CONTRIBUTING guide

    Read Core's contribution guidelines and note how PR scope, review culture, and CI differ from typical web repos.

    spec review
    workflowtestingscope
    35 min·beginneropen on GitHub
review checklist
  1. Does the change solve the stated problem?
  2. Are edge cases and rollout behavior covered?
  3. Are tests or test vectors included?
  4. Is the diff minimal and clearly explained?

More repos and GFIs on /discover and /issues.

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track

discussion

Discussion

prevRegtest DevelopmentnextCryptography Primer

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.

No questions yet — be the first to ask.