Collaboration Workflows and What’s Next
Pull requests
A pull request (called a “merge request” on GitLab) is how most real teams actually merge code — instead of merging directly on your own machine, you push your branch to the remote and open a pull request asking for it to be reviewed and merged into main. This gives teammates a chance to comment, request changes, and approve before anything reaches the main branch.
A typical team workflow
git checkout -b add-search-featuren# ... make changes, commit as you go ...ngit push origin add-search-featuren# open a pull request on GitHub, request review, address feedbackn# once approved, merge through GitHub's interfacengit checkout mainngit pull origin mainngit branch -d add-search-featureFetch vs pull
git fetch origin # download remote changes, but don't merge them yetngit pull origin main # fetch AND merge in one stepfetch lets you see what has changed on the remote before deciding whether and how to bring it into your own branch — slightly more cautious than pull, which merges immediately.
Stashing work in progress
git stash # temporarily shelve uncommitted changesngit checkout mainn# ... handle something urgent ...ngit checkout add-search-featurengit stash pop # bring your shelved changes backstash is genuinely useful when you need to quickly switch branches (to fix an urgent bug, say) without committing half-finished work — it sets your changes aside temporarily and lets you bring them back exactly where you left off.
Where to go from here
- GitHub Actions / CI — automatically running tests on every pull request, a natural next step once you are comfortable with the basic workflow here
- Interactive rebase — a more advanced tool for cleaning up commit history before opening a pull request
You have completed the course
You now know how to commit, branch, merge, work with remotes, resolve conflicts, and undo mistakes safely — the everyday Git workflow used on virtually every real software team, in every language covered on this site.