Git and GitHub Project: Simulate a Real Team Collaboration Workflow

Time to practise Git and GitHub the way real teams use them. In this project you will set up a protected repository, plan work, build features in parallel, review pull requests, resolve a conflict, publish releases and ship a hotfix.

---

🎯 Project Brief

You will run a realistic team workflow on GitHub from start to finish: planning, branching, pull requests, reviews, conflicts, releases and a hotfix. Work with one or two friends (best), or simulate teammates with a second GitHub account or a second clone.

Goal: prove you can collaborate on GitHub the way professional teams do. This is excellent material for interviews: “Walk me through how your team uses Git.”

Time needed: 4 to 6 hours. Skills used: Modules 1 to 8.

---

👥 Roles

Role	Responsibilities
Maintainer (you)	Creates the repo, sets rules, reviews and merges, cuts releases
Contributor A	Builds feature 1, reviews feature 2
Contributor B	Builds feature 2, reviews feature 1, reports a bug

Solo? Play all roles, using a second clone (git clone <url> contributor-b) and, if possible, a second GitHub account for reviews.

---

🧱 Phase 1: Set Up the Repository (Maintainer)

1. Create a public repository team-qa-notes with a README and a Node or Python .gitignore (create and push).
2. Add collaborators: Settings, Collaborators, Add people.
3. Add community files:

• CONTRIBUTING.md with branch naming (feature/, fix/) and Conventional Commits.
• .github/CODEOWNERS making the maintainer owner of everything (CODEOWNERS).
• .github/pull_request_template.md and a bug report issue form.

4. Protect main with a ruleset: pull request required, 1 approval, no force pushes or deletions (branch protection).
5. Add a simple CI workflow that runs on pull requests (for example echo checks or a linter) and make it a required check.

✅ Checkpoint: a direct git push origin main is rejected.

---

🗂️ Phase 2: Plan the Work

1. Create a Project board with Todo, In progress, In review, Done (Issues and Projects).
2. Create a milestone v0.1.0.
3. Create issues and add them to the board and milestone:

– #1 “Add Git basics notes” (assign A) – #2 “Add GitHub Actions notes” (assign B) – #3 “Add a glossary to README” (maintainer)

---

🌿 Phase 3: Build Features in Parallel

Each contributor:

git clone git@github.com:maintainer/team-qa-notes.git
cd team-qa-notes
git switch -c feature/1-git-basics-notes          # B uses feature/2-actions-notes
# create docs/git-basics.md, commit in small steps
git commit -m "docs(git): add commit and branch notes"
git commit -m "docs(git): add undo commands table"
git push -u origin feature/1-git-basics-notes

Open pull requests with Closes #1 / Closes #2, filling in the template (pull requests).

---

👀 Phase 4: Review

• A reviews B’s PR and B reviews A’s: at least one line comment, one suggestion, and one Request changes (code review).
• Authors address the feedback with new commits, resolve conversations and re-request review.
• Before merging, each author tidies their commits with interactive rebase and git push --force-with-lease (their own branch only).

---

🧯 Phase 5: Create and Resolve a Conflict

1. Both contributors edit the same lines of README.md on their branches (for example the title line).
2. Merge A’s PR first (Squash and merge).
3. B’s PR now shows a conflict. B updates the branch locally:

git switch feature/2-actions-notes
git fetch origin
git rebase origin/main
# resolve README.md, then:
git add README.md
git rebase --continue
git push --force-with-lease

1. CI passes again; the maintainer merges (merge conflicts, rebase).

✅ Checkpoint: issues #1 and #2 closed automatically, board items moved to Done.

---

🏷️ Phase 6: Release

The maintainer:

git switch main && git pull
git tag -a v0.1.0 -m "First release of team QA notes"
git push origin v0.1.0
gh release create v0.1.0 --generate-notes

See tags and releases and GitHub CLI.

---

🚑 Phase 7: Hotfix

1. Contributor B reports a bug issue: “Typo in the undo commands table” using the issue form.
2. Contributor A fixes it on fix/4-undo-typo, opens a PR with Fixes #4, gets approval, merges.
3. Maintainer tags v0.1.1 and publishes a release.

---

🔄 Phase 8: Stay in Sync and Clean Up

git switch main
git pull
git branch -d feature/1-git-basics-notes
git fetch --prune

---

✅ Deliverables Checklist

• [ ] Protected main with required review and CI check
• [ ] CONTRIBUTING, CODEOWNERS, PR template and issue form
• [ ] Project board and milestone with linked issues
• [ ] At least 3 merged PRs with reviews, suggestions and resolved conversations
• [ ] One conflict resolved by rebasing
• [ ] Releases v0.1.0 and v0.1.1 with generated notes
• [ ] Clean history on main (one commit per PR)

---

🏅 Evaluation Rubric

Criterion	Weight
Repository setup and rules	20%
Planning with issues, board and milestone	15%
Quality of PRs and reviews	25%
Conflict resolution and clean history	20%
Releases and hotfix flow	20%

---

❓ FAQ

🤔 Can I do this project alone?

Yes. Use a second clone to simulate another developer, and a second GitHub account if you want real review approvals.

🤔 Why is main protected in this project?

Protection forces the team workflow: every change goes through a reviewed, tested pull request, exactly as in professional teams.

🤔 Should I merge or rebase to fix the conflict?

Either works. The project uses rebase on the contributor’s own branch to keep history linear; never rebase main.

🤔 How do I show this project in an interview?

Share the repository link and walk through the board, a reviewed PR, the conflict resolution and the releases.

---

🎯 Next Steps

• 🚀 Project 2: CI/CD Pipeline for a Test Automation Repo
• 📝 Module-wise Practice Assignments
• 📘 Git and GitHub Tutorial: full course