Working with other people: Git and code review

Copy a project from a server, send your commits back, and ask for them to be reviewed.

So far, everything lived on your computer. To work with others, or just to keep a backup, you store the project on a hosting service such as GitHub.

Remote

Another copy of the repository, usually on a server. The default name for the main one is origin.

Clone

Make your own full copy of a remote repository, including all of its history.

Push and pull

Push sends your new commits to a remote. Pull fetches other people's new commits from a remote and brings them into your branch.

Step 1: Connect your project to a remote

On GitHub, create an empty repository (a "New repository" button, with no README added), copy its address, then:

$ git remote add origin https://github.com/asha/hello-git.git
$ git remote -v
origin  https://github.com/asha/hello-git.git (fetch)
origin  https://github.com/asha/hello-git.git (push)

origin is just a nickname for that address. -v shows the addresses it fetches from and pushes to. (The address above is an example. Use your own.)

Step 2: Push your commits

$ git push -u origin main
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

git push sends your main branch to origin. The -u flag remembers the link once, so that later you can simply type git push and git pull. The output above was captured from a local test. GitHub prints a few extra lines that begin with remote: and some progress counters, which you can ignore.

When this works, your commits appear on the GitHub page. If it asks you to sign in, see the box at the end of this part.

Step 3: Get a copy on another machine, and pull changes

Someone else (or you, on another computer) can copy the whole project:

$ git clone https://github.com/asha/hello-git.git
Cloning into 'hello-git'...
done.

If that copy pushes a new commit, your original does not know yet. Bring it in:

$ git pull
Updating 6a9ba55..cdc1613
Fast-forward
 hello.txt | 1 +
 1 file changed, 1 insertion(+)

This is the same fast-forward as before: the remote had commits yours lacked, so Git moved your main forward.

Step 4: The team workflow

Putting the parts together, this is how nearly every professional change travels:

The everyday loop: branch from main, make small commits, open a pull request, merge when reviewed and green.

Update main (git switch main, git pull).
Make a branch for one task (git switch -c add-search).
Make small commits as you go.
Push the branch (git push -u origin add-search). GitHub then offers a "Compare and pull request" button.
Open a pull request (PR): a page that shows your changes, runs automatic checks and lets teammates comment.
Fix anything they raise with more commits on the same branch.
When it is approved and the checks pass, merge it. Then delete the branch.

Pull request (PR)

A request on a hosting service (GitHub, GitLab) to merge one branch into another. It shows the diff, runs automated checks and collects review comments. On GitLab the same thing is called a merge request.

For the curious Going deeper: signing in to GitHub, and fetch versus pull

GitHub no longer accepts your account password for Git commands over HTTPS. Use one of: the Git Credential Manager that comes with Git for Windows (it signs you in through the browser), a personal access token used in place of a password, or an SSH key added to your account with an address of the form [email protected]:asha/hello-git.git. Never paste a token into a file you commit (see Part 9).

git pull is really two steps: git fetch downloads new commits and updates your view of the remote (origin/main) without touching your files, then Git merges (or rebases) them into your branch. Running git fetch first lets you look at what arrived before deciding what to do with it.