Starting a feature called search on a fresh branch and sharing it takes git switch -c search, then git push -u origin search.
The switch -c from lesson 5-2 creates the branch at your current commit and moves you onto it, and the push -u from lesson 7-2 uploads it to the remote and links the two branches, so later pushes and pulls need no arguments.
This pair is the opening move of the workflow the whole unit describes, and it is worth noticing that main is not involved in either command. That is the point of the arrangement.
The feature-branch workflow
On a real team, almost nobody commits straight to main. The shared main has to work at all times, because it is what gets deployed. Instead every change follows the same loop.
- Branch with
git switch -c add-search, from lesson 5-2. - Commit your work on that branch, small and often, from lesson 2-3.
- Push the branch with
git push -u origin add-search, from lesson 7-2.mainis still untouched. - Open a pull request on GitHub, which is a request that your branch be pulled into
main. - Review, where teammates read your changes, comment, and ask for tweaks. That is the next lesson.
- Merge, usually a button on GitHub, after which everyone pulls the new
main.
Steps 4 through 6 happen on the GitHub website rather than in your terminal, which is the first time in this course that a step is not a Git command.
A pull request, universally shortened to PR, is not a Git feature at all. It is GitHub's collaboration layer wrapped around the git merge from lesson 5-3, adding a place to see the diff, discuss it, and approve it before the merge happens.
The value of the loop is that review happens before anything reaches main. A branch that turns out to be wrong is closed and deleted with no consequences, which is only possible because the work was never in the shared history to begin with.
Forks: contributing without permission
The workflow above assumes you are allowed to push branches to the repository. For open-source projects you do not own, you are not.
The answer is a fork, your own complete copy of the repository under your GitHub account, made with the Fork button on the project's page.
The loop grows by one hop. Fork the project, clone your fork, branch, commit, push to your fork, then open a pull request from your fork's branch to the original project. Maintainers review and merge it exactly as teammates would.
This is how strangers safely collaborate on Linux, Python, React, and the rest of open source. Nobody needs push access in order to propose a change, and maintainers keep the only keys to main, so the project stays open to contributions without being open to damage.
No, git pull-request is not a real Git command.
Pull requests are a feature of hosting sites, layered on top of Git's branches and merges. Git itself knows nothing about them, which is why nothing in units 1 through 7 hinted at their existence.
GitHub built the concept, and GitLab and Bitbucket offer their own versions, sometimes under the name merge request. What they add is a web page proposing that one branch be merged into another, with diff viewing, line comments, and an approve-and-merge button. The merge it eventually performs is the ordinary one from lesson 5-3.
After pushing your feature branch, you open a pull request on GitHub to propose merging it into main and invite review.
It packages your branch's diff, a description, and a discussion thread in one place, and ends with a merge button once the team is satisfied.
The name is literal. You are requesting that the maintainers pull your branch in, which is why it exists as a request rather than an action: you can propose the merge without having the permission to perform it.