Is Collaboration & Git free to learn?

Yes. Every Collaboration & Git lesson on CodeMaster is completely free, with no ads. No login required to read the concept notes.

Can beginners follow Collaboration & Git?

Yes. Each lesson goes concept explanation → code example → interactive demo → quick quiz, so you can follow with no prior knowledge.

How long does Collaboration & Git take?

Each lesson is about 30–60 minutes. At 1–2 lessons a day you can finish the whole category in roughly 1–2 months.

Collaboration — GitHub Flow · PR · Code Review · Commit Conventions

🎯 After reading this lesson

After finishing this lesson, you will be able to confidently do the following 3 things.

▸✅ Standard Pull Request / Code Review workflow
▸✅ Writing a PR Template + Test plan
▸✅ Feature flags + incremental deployment

Keep the learning objectives as a checklist, and close the lesson once you can answer all of them.

GitHub Flow — The Simplest Collaboration Pattern

1. Branch from main — git checkout -b feature/awesome
2. Work + push often — commit + push immediately (backup + CI trigger)
3. Open a PR early — Draft PR — enables review in parallel while work continues
4. Discussion & revisions — comments → additional commits → re-run CI
5. Approve + merge — review OK + CI green → merge to main
6. Automatic deployment — CD automatically deploys main to production (usually within 5 minutes)

> 💡 Difference from Git Flow: no develop/release branches. Just a single main line + feature branches. Optimized for SaaS.

Pull Request 6-Step Cycle

1. Branch + commit — work on feature branch + commit + push
2. Create PR — GitHub Compare & pull request → write title and description
3. CI runs automatically — GitHub Actions runs build, tests, and linting automatically
4. Request peer review — assign Reviewers. Notifications via Slack and email as well
5. Discussion & revisions — comments → additional commits → auto-updated. Repeat until approved
6. Merge — approved + CI passed → merge to main. Branch deleted automatically

Good PR title:

▸❌ fix bug
▸✅ fix(auth): Handle JWT expiration — 401 response + refresh token reissue

Good PR description (template):

markdown

## Changes
- What was changed

## Reason
- Why was it needed

## Test
- How was it verified (screenshots·test results)

## Related Issues
Closes #123

6 Principles of Code Review

1. Review the code, not the person — not "this part is wrong" but "what if we did it this way?" No personal attacks
2. Ask questions — "Why this approach?" ✅ / "This is wrong" ❌. Invite discussion
3. Reason + suggestion — "NPE risk. How about adding a null check?" — problem and solution together
4. Indicate priority — [Blocking]·[Suggestion]·[Nit] — mark importance explicitly
5. Praise the good — "This part is clean!" — encourage positive feedback
6. Attach learning resources — link relevant docs and blog posts — grow together

Reviewer checklist:

▸[ ] Does the code match the PR description?
▸[ ] Are there sufficient tests?
▸[ ] Are names clear and meaningful?
▸[ ] Error handling & edge cases
▸[ ] Security (secrets · SQL injection · XSS)
▸[ ] Performance (N+1 · unnecessary computation)

Commit Conventions — Conventional Commits

Format: <type>(<scope>): <description>

Types:

type	meaning	example
`feat`	new feature	`feat(auth): add JWT issuance`
`fix`	bug fix	`fix(api): handle null response`
`refactor`	refactoring	`refactor(db): separate Repository`
`docs`	documentation	`docs: update README API section`
`test`	tests	`test(auth): add expiry case`
`chore`	build / config	`chore: upgrade pnpm 9`

Automation benefits:

▸git log --grep "^feat" — view only feat commits
▸Auto-generate CHANGELOG (semantic-release)
▸Automatic SemVer: feat=minor / fix=patch / BREAKING CHANGE=major
▸Block non-conforming PRs in CI with commitlint

> 💡 Korean messages are fine too. The key is the type prefix and stating the reason.

💻 📌 Collaboration Workflow Command Reference

# === GitHub Flow One Cycle ===
# 1. Sync with latest main
git checkout main
git pull origin main

# 2. Branch off feature branch
git checkout -b feature/awesome

# 3. Work + frequent commit + push
git add .
git commit -m "feat(awesome): Add core logic"
git push -u origin feature/awesome

# 4. Create PR (GitHub CLI)
gh pr create --title "feat: awesome feature" \
             --body "## Changes\n..." \
             --reviewer @teammate

# 5. Check PR status
gh pr status
gh pr checks                  # CI results
gh pr view                    # View review comments

# 6. Additional commits after reflecting review
git add .
git commit -m "refactor(awesome): Reflect review - add null check"
git push                      # PR auto-update

# 7. Merge (after approval + CI green)
gh pr merge --squash --delete-branch
# Or 'Squash and merge' button in GitHub UI

# === Good Commit Message Example ===
git commit -m "feat(auth): JWT issuance + refresh token

- POST /api/auth/login → issue access·refresh tokens
- access 15 min / refresh 7 days
- Store refresh as httpOnly cookie (XSS defense)

Closes #42"

# === Change Statistics ===
git shortlog -sn --since="1 month ago"   # Commits per person
git log --author="Hong Gildong" --oneline       # Specific person's commits
gh pr list --author "@me" --state merged  # My merged PRs

🤖 Try asking AI like this

Knowing the concepts in this lesson lets you give AI specific instructions — not a vague "fix this" but a request with vocabulary — and that is where token savings begin.

▸"Rewrite this PR body using the '## Summary / ## Test plan / ## Risks' template"
▸"Give me 3 examples of effective code review comments (question-style + alternative suggestions) for this code"

Why does this reduce tokens?

Without the concepts, even after receiving an AI answer you have to ask "What does that mean?" again. Those follow-up questions eat tokens. Learn the concepts once and the conversation ends in a single exchange.