Project: Build the Fest Website as a Team with Git and GitHub

One Fest, Three Friends, One Notice Board

Think about how a college fest committee works. One person handles the stage, one handles registrations, one handles decoration. They work separately, but there is one shared notice board where every task is written, and nothing goes on the official poster until the coordinator has checked it. If two people change the same poster, they sit together and agree on the final version.

That is exactly how a software team uses Git and GitHub. In this project, Asha Verma, a second-year BCA student, builds the website for her college fest Utsav with her friends Ravi and Imran. The repository is the shared workspace, issues are the notice board, branches are each person’s own desk, and pull requests are the coordinator’s check. This is the final project of the Git and GitHub course, so it brings together everything from the earlier lessons.

The Plan for the Week

Monday     Step 1  Asha sets up the repository and adds Ravi and Imran
           Step 2  The team writes one issue for each task
Tuesday    Step 3  Everyone clones the repository and creates a feature branch
Wednesday  Step 4  Each person builds and commits a page
Thursday   Step 5  Pull requests and reviews
           Step 6  One real merge conflict in index.html
Friday     Step 7  Tag v1.0, publish with GitHub Pages, retrospective

Asha’s GitHub username is asha-utsav-demo, Ravi is ravi-utsav-demo and Imran is imran-utsav-demo. Replace these with real usernames, or with your own.

Working alone? Use two folders as two teammates

You do not need friends to practise this project. Git does not care who is typing; it only sees two separate copies of the repository. Create your own repository (Step 1), then clone it twice into two folders. One folder is “Asha”, the other is “Imran”. Open each folder in its own VS Code window and switch between them, just as two people would push and pull from two laptops.

# Working alone? Make two clones in two different folders.
# Each folder plays one teammate.
mkdir fest-practice
cd fest-practice
git clone https://github.com/your-username/college-fest-site.git asha
git clone https://github.com/your-username/college-fest-site.git imran

# Inside the "imran" folder, use a different name for this repository only
cd imran
git config user.name "Imran (practice)"
git config user.email imran@example.com
cd ..

fest-practice/
├── asha/       <- teammate 1: open this folder in one VS Code window
│   └── (college-fest-site files)
└── imran/      <- teammate 2: open this folder in a second VS Code window
    └── (college-fest-site files)

The git config without --global changes the name only for that one folder, so the history clearly shows who did what. On GitHub, both teammates are your account, so you will review your own pull requests. GitHub does not let you formally approve your own pull request, so leave a review comment instead and then merge.

Step 1: Set Up the Repository

Asha creates the repository on GitHub, as in the GitHub Account and First Repository lesson:

1. Click New repository, name it college-fest-site, choose Public (needed for free GitHub Pages on a personal account) and tick Add a README file.
2. Write a short README: what the site is, who is in the team, and one rule: “Nobody pushes to main directly. Every change goes through a pull request.”
3. Open Settings, then Collaborators, click Add people and invite ravi-utsav-demo and imran-utsav-demo. They accept the invitation from their email or GitHub notifications. Collaborators can push branches and merge pull requests.

Then she adds the first files from her computer:

# Asha clones the new, empty-looking repository (it only has README.md)
git clone https://github.com/asha-utsav-demo/college-fest-site.git
cd college-fest-site

# A starting home page and a .gitignore (write them in VS Code, see below)
git add index.html .gitignore
git commit -m "Add home page and .gitignore"
git push

Her .gitignore keeps system and editor files out of the repository, as you learned in the Git Ignore lesson:

# .gitignore: files that should never be committed
.DS_Store
Thumbs.db
.vscode/
node_modules/

And here is the starting home page. Press Try it yourself to see it:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Utsav 2026 | College Fest</title>
</head>
<body>
  <nav>
    <a href="index.html">Home</a>
  </nav>
  <h1>Utsav 2026</h1>
  <p>Three days of music, dance, coding contests and food stalls. 15 to 17 March, main campus.</p>
</body>
</html>

Protect main (optional): under Settings, a branch protection rule or ruleset for main can require a pull request before merging. It turns the team rule from the README into a rule GitHub enforces.

Step 2: Create an Issue for Each Task

On the repository page, open the Issues tab and click New issue. The team writes one issue per task, each with a clear title, a short checklist and an assignee (the person responsible):

Now everyone can see who is doing what, and nobody builds the same page twice. Labels such as page or bug help when the list grows.

Step 3: Clone and Create Feature Branches

Ravi and Imran clone the repository with the green Code button, as in the GitHub Push, Pull and Clone lesson. Then each person creates a branch named after the task:

# Everyone starts from the latest main
git switch main
git pull

# Asha
git switch -c schedule-page

# Imran (in his own clone, or your "imran" folder)
git switch -c registration-form

# Ravi
git switch -c photo-gallery

A branch per task keeps unfinished work away from main, which must always be ready to publish.

Step 4: Build the Pages and Commit

Asha builds the schedule page. Try it and change an event:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Schedule | Utsav 2026</title>
  <style>
    body { font-family: sans-serif; margin: 20px; }
    table { border-collapse: collapse; width: 100%; max-width: 600px; }
    th, td { border: 1px solid #ccc; padding: 8px; text-align: left; }
    th { background: #6a1b9a; color: white; }
  </style>
</head>
<body>
  <h1>Fest Schedule</h1>
  <table>
    <tr><th>Day</th><th>Time</th><th>Event</th><th>Venue</th></tr>
    <tr><td>15 March</td><td>10:00 AM</td><td>Opening ceremony</td><td>Main auditorium</td></tr>
    <tr><td>15 March</td><td>2:00 PM</td><td>Coding contest</td><td>Computer lab 2</td></tr>
    <tr><td>16 March</td><td>11:00 AM</td><td>Group dance</td><td>Open-air stage</td></tr>
    <tr><td>17 March</td><td>5:00 PM</td><td>Music night and prizes</td><td>Open-air stage</td></tr>
  </table>
</body>
</html>

Imran builds the registration form. Press Register without filling it in to see the browser’s validation:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Register | Utsav 2026</title>
  <style>
    body { font-family: sans-serif; margin: 20px; }
    form { display: grid; gap: 10px; max-width: 360px; }
    button { padding: 10px; background: #6a1b9a; color: white; border: none; }
  </style>
</head>
<body>
  <h1>Register for an Event</h1>
  <form>
    <label for="name">Full name</label>
    <input id="name" name="name" required>

    <label for="email">College email</label>
    <input id="email" name="email" type="email" placeholder="you@example.com" required>

    <label for="event">Event</label>
    <select id="event" name="event" required>
      <option value="">Choose an event</option>
      <option>Coding contest</option>
      <option>Group dance</option>
      <option>Music night</option>
    </select>

    <button type="submit">Register</button>
  </form>
</body>
</html>

Each person commits in small steps with clear messages, then pushes the branch:

# Asha, after saving schedule.html
git add schedule.html
git commit -m "Add schedule page with all three days"

# She also adds a menu link on the home page
#   (in index.html, under the Home link: <a href="schedule.html">Schedule</a>)
git commit -am "Link schedule page from the menu"

# Send the branch to GitHub
git push -u origin schedule-page

Notice that Asha and Imran both add a menu link to index.html, on the same line. Remember this: it causes the conflict in Step 6.

Step 5: Open Pull Requests and Review

After the push, GitHub shows a Compare & pull request button. Asha clicks it and writes:

• Title: Add schedule page
• Description: what she changed, how to test it, and the line Closes #1. This links the pull request to the issue and closes the issue automatically when the pull request is merged into main.
• Reviewers: ravi-utsav-demo

Ravi opens the Files changed tab, clicks a line to leave a comment (“Please use 12-hour times everywhere”), then clicks Review changes and chooses Request changes. Asha fixes it on the same branch:

# Ravi asked for a change in his review. Asha fixes it on the same branch:
git commit -am "Use 12-hour times in the schedule"
git push
# The pull request updates by itself. No new pull request is needed.

Ravi checks again, chooses Approve, and Asha clicks Merge pull request. GitHub offers to delete the branch; she accepts. Issue #1 closes by itself. If you added the check workflow from the GitHub Actions Basics lesson, a green tick also appears on the pull request before merging.

Step 6: Solve a Real Merge Conflict in index.html

Imran’s pull request now shows This branch has conflicts that must be resolved. Both he and Asha added a link under “Home” in the menu, and Asha’s version is already in main. Imran brings main into his branch to solve it on his computer:

# Imran, in his clone, on registration-form
git switch main
git pull
git switch registration-form
git merge main

You will see something like:

Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

Inside index.html:

<nav>
  <a href="index.html">Home</a>
<<<<<<< HEAD
  <a href="register.html">Register</a>
=======
  <a href="schedule.html">Schedule</a>
>>>>>>> main
</nav>

The part under HEAD is Imran’s branch, and the part above >>>>>>> main is Asha’s merged work. Neither is wrong; the menu needs both links. Imran deletes the three marker lines and keeps both links, in the order of the fest:

<nav>
  <a href="index.html">Home</a>
  <a href="schedule.html">Schedule</a>
  <a href="register.html">Register</a>
</nav>

# After editing index.html and removing all markers
git add index.html
git commit -m "Merge main into registration-form, keep both menu links"
git push

The pull request updates and shows that it can be merged. Asha reviews, approves and merges it, and issue #2 closes. Ravi’s gallery follows the same path. Small, frequent pull requests keep conflicts small like this one. GitHub also has a Resolve conflicts button for simple cases, but solving them locally lets you test the page before you push.

Step 7: Tag v1.0 and Publish with GitHub Pages

On Friday all three pull requests are merged. Asha marks the launch version with an annotated tag, as in the Stash, Cherry-pick and Tags lesson:

# Asha, after all three pull requests are merged
git switch main
git pull
git log --oneline --graph -10        # check that everyone's work is there

git tag -a v1.0 -m "Utsav 2026 site launch"
git push origin v1.0

Then she publishes the site, as in the GitHub Pages Deploy lesson: open Settings, then Pages, choose Deploy from a branch, select main and the / (root) folder, and click Save. After a minute or two the site is live at https://asha-utsav-demo.github.io/college-fest-site/. She also creates a Release from the v1.0 tag and clicks Generate release notes, which lists the three merged pull requests. The team shares the link in the fest group, and registrations begin.

What We Learned: The Team Retrospective

A retrospective is a short meeting after a project where the team asks three questions: what went well, what was difficult, and what will we do differently next time. Here is the Utsav team’s list:

• Went well: issues made it clear who was doing what. Reviews caught the time format and a missing alt text before visitors saw them.
• Difficult: the menu conflict, because two people edited the same lines of index.html.
• Next time: pull main into your branch every morning, keep pull requests small, and agree in the issue who edits shared files such as the menu.

Try these changes:

1. Add a “Rules” section to the README describing the branch naming and review rules.
2. Create a bug issue for a typo, fix it on a branch named fix-typo, and close it with Fixes #4 in the pull request.
3. Add the check.yml workflow from the GitHub Actions Basics lesson and make a branch protection rule require it.

Common Mistakes

• Working on main. Fix: run git switch -c task-name before your first edit. If you already have changes, create the branch now: uncommitted changes come with you.
• Starting from an old main. Branches made from an old copy cause bigger conflicts. Fix: always git switch main and git pull before creating a branch.
• One giant pull request. Three pages in one pull request are hard to review. Fix: one issue, one branch, one pull request.
• Leaving conflict markers in the file. The page shows <<<<<<< on the live site. Fix: search the file for <<< before you commit, and open the page in the browser.
• Using the wrong folder when practising alone. Fix: check the VS Code window title and run git status before every commit.

Practice Task: Version 1.1 with Two Teammates

Use your two folders (asha and imran) or a real friend:

1. Create issue #5 “Sponsors page” and issue #6 “Contact page”.
2. In the asha folder, build sponsors.html on a branch and add a Sponsors link to the menu.
3. In the imran folder, build contact.html on another branch and add a Contact link to the menu.
4. Open two pull requests that close the issues. Merge the first one.
5. Solve the menu conflict in the second branch, push, and merge it.
6. Tag v1.1, push the tag, and check that the live site shows both new pages.

# In the "asha" folder
git switch main
git pull
git switch -c sponsors-page
#   (create sponsors.html, add <a href="sponsors.html">Sponsors</a> to the menu)
git add sponsors.html
git commit -am "Add sponsors page and menu link"
git push -u origin sponsors-page

# In the "imran" folder
git switch main
git pull
git switch -c contact-page
#   (create contact.html, add <a href="contact.html">Contact</a> to the menu)
git add contact.html
git commit -am "Add contact page and menu link"
git push -u origin contact-page

# On GitHub: open Issues #5 and #6, open two pull requests with
# "Closes #5" and "Closes #6", review and merge sponsors-page first.

# In the "imran" folder: bring in main and solve the menu conflict
git switch main
git pull
git switch contact-page
git merge main
#   (keep both links in index.html, remove the markers)
git add index.html
git commit -m "Merge main, keep Sponsors and Contact links"
git push
#   Merge the second pull request on GitHub.

# In the "asha" folder: release
git switch main
git pull
git tag -a v1.1 -m "Add sponsors and contact pages"
git push origin v1.1

Key Takeaways

• A team workflow is: issue, branch, commits, pull request, review, merge, repeated for every task.
• A README, a .gitignore and invited collaborators make a good start for any team repository.
• Closes #1 in a pull request closes the issue automatically when it is merged.
• Conflicts are normal when two people edit the same lines: merge main into your branch, keep the right lines, remove the markers, commit and push.
• Mark the launch with git tag -a v1.0 and publish with GitHub Pages.
• Working alone, two clones in two folders act as two teammates.