Working Code
Example 1: Creating a repository with GitHub CLI
Install GitHub CLI (gh) to manage GitHub from the terminal:
brew install gh
gh auth login
Create a repository:
cd ~/my-project
gh repo create my-project --public --push --source=.
This single command:
- Creates a repository on GitHub
- Sets up the
originremote - Pushes the current code
Verify:
gh repo view --web # Open in browser
Example 2: Creating an issue
gh issue create \
--title "Login page bug" \
--body "Auto-login doesn't work after password reset."
Output:
https://github.com/username/my-project/issues/1
List issues:
gh issue list
Output:
ID TITLE LABELS UPDATED
1 Login page bug 2 minutes ago
Example 3: Creating a Pull Request
# Work on a feature branch
git checkout -b fix/login-bug
echo "// Bug fix code" > login-fix.js
git add login-fix.js
git commit -m "fix: fix auto-login bug after password reset"
git push origin fix/login-bug
gh pr create \
--title "fix: fix login bug" \
--body "Resolves #1
## Changes
- Fixed session refresh logic after password reset"
Try It Yourself
Pull Request code review cycle
After creating a PR, teammates review the code:
Developer Reviewer
| |
|-- Create PR -----------------> |
| |-- Review code
| |-- Leave comments
| <-- Review feedback ---------- |
|
|-- Commit fixes
|-- git push (PR auto-updates)
|
|-- Request re-review ----------> |
| |-- Re-review
| |-- Approve
| <-- Approval ----------------- |
|
|-- Merge PR
|-- Delete branch
Responding to review feedback:
# Reviewer commented: "Make the variable names clearer"
vim login-fix.js # Make changes
git add login-fix.js
git commit -m "refactor: clarify variable names"
git push # Automatically reflected in the PR
Since the PR tracks the branch, pushing updates it automatically.
PR list and details:
gh pr list
gh pr view 1 # View PR #1 details
gh pr view 1 --web # Open in browser
Merging a PR:
gh pr merge 1 --squash # Squash merge (combine feature commits into one)
gh pr merge 1 --merge # Merge commit
gh pr merge 1 --rebase # Rebase merge
Draft PR: Signal work in progress
# Draft PR: when it's not ready for review yet
gh pr create \
--title "feat: implement payment system" \
--body "Work in progress..." \
--draft
Draft PR use cases:
- Signal "still working on this, don't review yet"
- Share progress with the team
- Check CI test results
- Request early feedback
Convert to ready for review:
gh pr ready 1
"Why?" -- GitHub is more than a code host
GitHub is Git repository hosting + a collaboration platform.
| Feature | Purpose | | ---------------- | -------------------------------------------- | | Issues | Bug reports, feature requests, task tracking | | Pull Request | Code review + merge request | | Actions | CI/CD automation | | Projects | Kanban board for task management | | Discussions | Team discussions |
Pull Request workflow
Create issue (#1 "Login bug")
|
Create branch (fix/login-bug)
|
Fix code + commit (closes #1)
|
Create PR (request code review)
|
Code review + feedback
|
Apply fixes + re-review
|
Approve -> Merge
|
Delete branch + issue auto-closes
Including closes #1 or fixes #1 in the commit message or PR body auto-closes the issue when the PR is merged.
Checking CI status
Check GitHub Actions results on a PR:
gh pr checks 1
Output:
All checks were successful
✓ CI / test (2m 15s)
✓ CI / lint (45s)
You can block merging when CI fails.
Common Mistakes
Mistake 1: Vague PR titles
# Bad
update
fix
changes
# Good
fix: fix auto-login bug after password reset
feat: add Google social login
docs: add authentication section to API docs
Mistake 2: Too many changes in one PR
# Avoid: dozens of file changes in one PR
# Hard to review and increases merge conflict risk
# Recommended: one purpose per PR
# "Login feature" PR -> only login.js, auth.js, and related tests
Mistake 3: Pushing directly to main without review
# Bad habit
git push origin main # Direct push
# Good habit
# 1. Create a feature branch
# 2. Work + commit
# 3. Create a PR
# 4. Get reviewed
# 5. Merge the PR
Branch protection rules can block direct pushes.
Deep Dive
Forks and open-source contributions
When you don't have push access to a repository:
- Fork: Copy the repository to your account
- Clone: Clone your fork locally
- Branch + edit + push (to your fork)
- PR: Submit a contribution request to the original repository
# Sync with original (set up upstream)
git remote add upstream https://github.com/original/repo.git
git fetch upstream
git merge upstream/main
Setting up a PR template
Create a .github/PULL_REQUEST_TEMPLATE.md file to auto-fill PR descriptions:
## Changes
-
## Related Issue
closes #
## Checklist
- [ ] Feature implemented
- [ ] Tests added
- [ ] Documentation updated
- [ ] Browser tested
## Screenshots (for UI changes)
Useful GitHub keyboard shortcuts
On the GitHub website:
t-- File searchb-- Switch branches.-- Open web editor (vscode.dev)Ctrl+K-- Command palettegc-- Go to commit list
- Create a new GitHub repository and connect it locally.
- Create an issue with
gh issue create. - Work on a new branch, then create a PR with
gh pr create. Include the issue number in the body. - Create a Draft PR and convert it to ready with
gh pr ready. - Merge with
gh pr merge --squashand check if the issue auto-closes.
Q1. What is the primary purpose of a Pull Request?
- A) Uploading code to a remote repository
- B) Automatically deleting branches
- C) Requesting a branch merge through code review
- D) Automatically resolving conflicts