A Day on a Team: Putting It All Together

One day, many situations

You now know the pieces: commits, branches, merges, conflicts, undoing, remotes and pull requests. A real day on a team mixes them, and the work is rarely tidy. This lesson walks through a realistic day, and you practise each situation in the terminal.

The project is a small restaurant website. Your team is you and a teammate called Tunde.

9:00: Start the day

Always begin the same way: get the latest work.

git switch main
git pull
git switch -c feature/opening-hours

You pull so you start from what the team has done. Then you make a branch for your task, never working directly on main. Describe the branch by the work: feature/opening-hours.

11:00: An urgent interruption

You are halfway through the opening-hours page, with files edited and not ready to commit. Your manager says there is a typo on the live menu that must be fixed now.

You cannot commit half-finished work, and Git will not let you switch branches if it would overwrite your changes. The answer is the stash (lesson 4):

git stash                       # put your half-done work in the drawer
git switch main                 # go to the stable branch
git switch -c fix/menu-typo     # a branch for the urgent fix
# ...fix the typo...
git add menu.txt
git commit -m "Fix typo in the jollof rice name"
git switch main
git merge fix/menu-typo         # (or a pull request on a team)
git switch feature/opening-hours
git stash pop                   # get your work back

Practise this exact sequence in the first task below.

14:00: Tunde's change collides with yours

You finish the opening-hours page and merge main into your branch to check it still works, and Git says:

CONFLICT (content): Merge conflict in hours.txt

Tunde also edited the Saturday hours. It is routine. You open the file, read the markers (lesson 6), decide together what is right (talk to Tunde!), edit the file, git add, and git commit. In the second task you do exactly this.

16:00: Release

When the work is merged into main and ready, teams mark the moment with a tag: a permanent, named label on a commit, usually a version number.

git tag v1.0
git tag                    # list tags
git push origin v1.0       # send the tag to GitHub

Tags make it easy to say "this is what we shipped on Friday", and to go back to it. On GitHub, you can turn a tag into a Release with notes for users. Version numbers like v1.2.3 usually mean: major changes that break things, minor new features, patch small fixes.

17:00: End of day habits

Before you close your laptop:

• git status: is anything uncommitted that should not be lost?
• Push your branch, even if the work is unfinished. It is a backup, and your team can see your progress.
• Update the issue or leave a note about where you stopped.

The professional's checklist

Print this and stick it beside your desk:

1. Start with git pull on main, then branch.
2. Never work directly on main. One branch per task.
3. Small commits, each one idea, each with a clear message.
4. git status and git diff --staged before every commit.
5. Never commit secrets. .gitignore from day one.
6. Pull before you push, and resolve conflicts calmly.
7. Rewrite history only on private work. Use revert on shared work.
8. Open small pull requests with a good description, and review others kindly.
9. Delete merged branches, and tag releases.
10. Ask for help early. Nobody remembers every command, and everybody searches for them.

Try it

First, the urgent interruption. You have half-finished work. Stash it, fix the urgent bug on its own branch, merge it, and come back.

Now the collision. Tunde changed the same line as you. Resolve it and finish the merge, keeping both pieces of information.