Developer Workflow

Introduction

Now that you know the individual Git commands, this lesson ties them together into the workflows real teams actually use. You will learn about pull requests (the collaboration mechanism), .gitignore (keeping secrets and noise out of the repo), and commit message conventions that make history readable months later.

Pull Requests

A pull request (PR) is a request to merge your branch into another branch (usually main). It happens on GitHub, not in the terminal. PRs are the primary way teams review each other's code before it goes into production.

The PR workflow

1. Create a feature branch locally: git switch -c feature/login-form
2. Do your work and make commits.
3. Push the branch to GitHub: git push -u origin feature/login-form
4. On GitHub, click Compare & pull request.
5. Write a description explaining what the PR does and why.
6. Request a review from a teammate.
7. Teammate reviews the code, leaves comments, approves or requests changes.
8. Once approved, click Merge pull request.
9. Delete the feature branch on GitHub (button appears after merge).
10. Locally: git switch main && git pull && git branch -d feature/login-form

Forking

A fork is your personal copy of someone else's repository on GitHub. Forking is used for open-source contributions:

1. Fork the project on GitHub (button top-right of any repo).
2. Clone your fork locally.
3. Create a branch, make changes, push to your fork.
4. Open a PR from your fork's branch to the original project's main.

.gitignore

A .gitignore file tells Git which files and folders to ignore — they will never be staged or committed. This is critical for:

• Secrets and credentials (.env, API keys)
• Build output (dist/, build/)
• Dependencies (node_modules/) — these are huge and can be reinstalled
• OS-generated files (.DS_Store, Thumbs.db)
• Editor files (.vscode/, .idea/)

Example .gitignore for a frontend project

# Dependencies
node_modules/

# Build output
dist/
build/
.cache/

# Environment variables (NEVER commit these)
.env
.env.local
.env.*.local

# OS files
.DS_Store
Thumbs.db

# Editor files
.vscode/settings.json
.idea/

# Logs
*.log
npm-debug.log*

Syntax rules

node_modules/     # Ignore a folder
*.log             # Ignore all .log files
.env              # Ignore a specific file
!.env.example     # But DO track .env.example (the ! negates)
/dist             # Only ignore dist/ in the root, not subdirs

Commit Message Conventions

A clean commit history is documentation. The Conventional Commits standard is widely used in professional teams:

<type>: <short description>

[Optional body — more detail if needed]

[Optional footer — issue references]

Common types

feat:     A new feature
fix:      A bug fix
docs:     Documentation changes only
style:    Formatting changes (no logic change)
refactor: Code restructure (no feature/bug change)
test:     Adding or fixing tests
chore:    Build process, dependency updates

Examples

feat: add dark mode toggle to navigation
fix: prevent form submission with empty email field
docs: add setup instructions to README
style: remove trailing whitespace from index.html
refactor: extract password validation into separate function
chore: update dependencies to latest versions

Rules for good commit messages

• Use the imperative mood: "Add feature" not "Added feature"
• Keep the subject line under 72 characters
• Do not end with a period
• Explain what and why, not how

Branching Strategies

GitHub Flow (simple — good for solo/small teams)

1. main is always deployable.
2. Create a branch for every piece of work.
3. Open a PR when ready.
4. Merge to main after review.
5. Deploy immediately after merge.

Git Flow (complex — good for scheduled releases)

• main — production code only
• develop — integration branch
• feature/* — new features, branch from develop
• release/* — preparation for release
• hotfix/* — urgent fixes to production

Useful Daily Commands

# See a compact, colourful branch graph
git log --oneline --graph --all --decorate

# Stash work-in-progress without committing
git stash
git stash pop            # Restore the stash
git stash list           # See all stashes

# Cherry-pick a specific commit onto the current branch
git cherry-pick abc1234

# Find which commit introduced a bug (binary search)
git bisect start
git bisect bad           # current commit is broken
git bisect good abc1234  # this commit was fine

# Clean untracked files (dry run first!)
git clean -n    # shows what would be deleted
git clean -f    # actually deletes

Common Mistakes

• Writing a .gitignore after committing secrets. Once committed and pushed, a secret is compromised even if you delete it in a later commit — it is still in the history. Rotate any exposed credentials immediately.
• Merging without a code review. Even reviewing your own PR catches bugs. Never merge directly without looking at the diff.
• Accumulating long-lived feature branches. The longer a branch lives, the harder it is to merge. Prefer small, short-lived branches merged frequently.
• Vague commit messages. "fix", "update", "wip" are useless in a team. Future you (and your colleagues) will be grateful for descriptive messages.

Practice Exercise

1. Create a .gitignore file in your practice project. Add *.log, .DS_Store, and node_modules/ to it.
2. Create a file called secret.env with some fake content, then add *.env to your .gitignore. Run git status — verify that secret.env does NOT appear.
3. Commit the .gitignore file.
4. Push a feature branch to GitHub and open a pull request into main.
5. Merge the PR on GitHub, then update your local main with git pull.

Assignment — Portfolio Commit

Apply the full workflow to your best mini project:

1. Make sure it has a .gitignore.
2. Create a README.md with: project name, description, what you learned, and a screenshot (you can drag an image into the GitHub README editor).
3. Commit with feat: add README with project description.
4. Push to GitHub and enable GitHub Pages.
5. The live URL is now something you can put on your CV and LinkedIn.

Interview Questions

• What is a pull request? — A request to merge a branch into another branch (usually main), with a diff view and comment thread for code review. It is a GitHub feature, not a Git command.
• What is .gitignore? — A file listing patterns of files/folders that Git should not track. Used to exclude secrets, dependencies, build output, and OS files.
• Explain GitHub Flow. — A simple branching strategy: main is always deployable; every piece of work goes on a short-lived branch; PRs are used for review and merging.
• What does git stash do? — Temporarily saves uncommitted changes (both staged and unstaged) so you can switch branches with a clean working directory. git stash pop restores them.