Using GitHub for Project Management and Collaboration

In industry, GitHub is a cornerstone for managing code, collaborating with teams, and tracking project progress. As modern software development increasingly relies on distributed teams and structured workflows, being comfortable with GitHub is an essential professional skill.

This guide introduces a simple, practical workflow using Issues, branches, Pull Requests (PRs), and code reviews-practices that are widely used in real-world engineering teams.

Why GitHub?

Version Control: Track and manage changes to your code over time.
Collaboration: Work effectively with teammates without overwriting each other’s work.
Transparency: Make tasks, discussions, and contributions visible.
Industry Standard: GitHub (or similar platforms) is expected knowledge in most engineering roles.

Step-by-Step Workflow

Below is a streamlined GitHub workflow suitable for both this course and real-world team projects.

Create an Issue for Each New Task

Go to the Issues tab in your repository.
Click New Issue, add a clear title (e.g., “Add user authentication to login page”), and describe the task.
Assign the Issue to a teammate if applicable.
Why: Issues help track work, decisions, and progress.

Tip: Large tasks should be broken down into multiple Issues.

Create a New Branch

Create a new branch locally:
```
git checkout -b feature/task-name
```

Use descriptive names (common prefixes include feature/, fix/, or docs/).
Why: Branches isolate changes and keep the main branch stable.

Develop and Commit Code

Write and test your code locally.
Stage changes:
```
git add .
```
Commit your changes with a clear message:
```
git commit -m "feat: add login form"
```
Push your branch:
```
git push origin feature/task-name
```
Why: Commits record progress and communicate intent to your teammates.

Open a Pull Request (PR)

Go to Pull Requests → New Pull Request on GitHub.
Select your branch and write a short description of what you changed.
Link the related Issue using Closes #IssueNumber (e.g., Closes #12).
Request a teammate’s review.
Why: PRs enable discussion, review, and quality control.

Address Feedback and Merge

Respond to review comments with additional commits if needed.
Once approved, merge the PR into the main branch (e.g., Squash and Merge).
Delete the feature branch after merging.

Commit Message Format

Why Commit Messages Matter

Commit messages are not just for you. They are a communication tool for your entire team. In real workplaces, teams agree on a commit message format and use it consistently. Following the team’s convention is more important than personal preference.

Recommended Format

In this course project, we recommend a lightweight Conventional Commits–style format:


<type>(optional scope)[!]: <short imperative summary>

Guidelines

Use imperative mood (e.g., “add”, “fix”, “remove”)
Keep the subject line ≤ 50 characters
scope and ! are optional — use them when helpful

In real projects, always follow the commit message convention used by your team or organization — even if it differs from this one.

Common Types

feat: new functionality
fix: bug fixes
docs: documentation changes
refactor: code changes without behavior change
chore: cleanup, configuration, maintenance
ci: GitHub Actions / automation

Examples


feat: add login form
fix: handle empty request body
fix(api)!: change /tasks response to paginated format
docs: add local dev setup instructions
refactor(api): simplify request validation

Best Practices

Small, Focused PRs: One Issue per PR makes reviews faster and clearer.
Clear Communication: Write concise titles and descriptions for Issues and PRs.
Review Code Thoughtfully: Code reviews are about improving quality, not criticizing people.
Automate Where Appropriate: Many teams use GitHub Actions for testing or checks, but understanding the basics comes first.

Resources

GitHub Docs : Official documentation for Issues, PRs, and workflows
Git Cheat Sheet : Quick reference for common commands
Learn Git Branching : Interactive way to practice Git concepts
Lazygit : Optional terminal UI for Git (not required)