Integrated Git Workflow Simulation

Integrated Git Workflow Simulation

This lesson brings together every Git skill from the course into one realistic team exercise. You will act as a three-person development team, taking a project from an empty repository all the way to a published, versioned release on GitHub. Professional teams follow this kind of workflow every day, and being able to execute it smoothly is what employers expect.

Setting Up the Shared Repository

One team member creates the GitHub repository and adds the others as collaborators with write access. Immediately after creation, protect the `main` branch: go to Settings → Branches → Branch protection rules, add a rule for `main`, and enable Require a pull request before merging and Require approvals (set to at least one reviewer). This single step enforces code review and prevents anyone from pushing directly to production history—a practice used in nearly every professional shop.

All three members then clone the repository locally:

```

git clone https://github.com/team/project.git

```

Each member creates their own feature branch from `main` before writing a single line of code:

```

git checkout -b feature/header

git checkout -b feature/main-content

git checkout -b feature/footer

```

Working on Feature Branches and Opening Pull Requests

Each member builds their assigned section of `index.html` on their branch, commits frequently with clear messages, and pushes to GitHub:

```

git add index.html

git commit -m "Add navigation links to header section"

git push origin feature/header

```

On GitHub, each member opens a pull request (PR) targeting `main`. Write a short PR description explaining what changed and why. A teammate then reviews the PR: read the diff carefully, leave inline comments if something looks wrong, and approve or request changes. The PR author addresses any feedback with additional commits—GitHub automatically updates the PR. Only merge when at least one reviewer approves, satisfying the branch protection rule.

Resolving a Deliberate Merge Conflict

Your instructor will edit the same line in `index.html` on two different branches to produce a conflict. When the second PR attempts to merge, GitHub will flag it as conflicted and block the merge. This is normal; conflicts are an expected part of team development, not a sign that something is broken.

To resolve locally:

1. Fetch the latest state and check out the conflicting branch:

```

git fetch origin

git checkout feature/main-content

```

2. Merge `main` into your branch to bring in the already-merged changes:

```

git merge origin/main

```

3. Open the file. Git marks conflicts with `<<<<<<<`, `=======`, and `>>>>>>>` delimiters. Everything between `<<<<<<< HEAD` and `=======` is your version; everything between `=======` and `>>>>>>> origin/main` is the incoming version. Decide what the final content should be, delete all conflict markers, and save.

4. Stage the resolved file and complete the merge:

```

git add index.html

git commit -m "Resolve merge conflict: reconcile header link order"

git push origin feature/main-content

```

5. Document every command you ran and your resolution decision in your lab log before moving on.

Communication is the real solution to merge conflicts—talk to your teammate first so you understand what each version intended.

Creating a Develop Branch and Final Release

After all feature PRs are merged into `main`, create a `develop` branch to represent ongoing integration work. Open one final PR from `develop` into `main` and merge it. This simulates a release-candidate workflow.

Now apply a semantic version annotated tag. Semantic versioning follows `MAJOR.MINOR.PATCH`—`v1.0.0` means first stable release:

```

git tag -a v1.0.0 -m "Release v1.0.0: initial site with header, content, footer"

git push origin v1.0.0

```

Annotated tags store the tagger's name, date, and message, making them far more useful for release history than lightweight tags.

On GitHub, go to Releases → Draft a new release, select the `v1.0.0` tag, and write a changelog listing every feature merged and any known issues. Publish the release. Your project now has a permanent, citable snapshot.

Presenting the Repository History

Your team presents a 10-minute walkthrough using:

```

git log --graph --oneline --all

```

This command shows the full branch graph in the terminal. Walk the class through each branch, the conflict resolution commit, the PRs, and the tag. Explain why you made each workflow decision, not just what you did. GitLens in VS Code can supplement the terminal view with a visual graph if that helps your audience follow along.

Safety and Professional Practices

Version control carries its own safety rules. Never force-push to `main` or any shared branch (`git push --force`) without team agreement—it rewrites shared history and can destroy teammates' work. Never commit secrets such as passwords, API keys, or private configuration files; use `.gitignore` and environment variables instead. If a secret is accidentally committed, rotate it immediately—deleting the file in a later commit does not remove it from history.

Keep commit messages honest and specific. A vague message like "fixed stuff" is a liability when a future teammate needs to understand what changed and why.