So far, all the work on the game happened on one laptop. In the lab, your partner works on the same game from another laptop. That is not only a lab arrangement. Almost every codebase you will work on has several people on it, each on their own computer. In this video we see how git keeps their copies in sync, through a remote repository on a server such as GitHub. Then we share committed work on our game, and combine the changes when both of you have something new.
In real projects, several people work on one codebase. Each one has a full copy of the repository on their own computer, and commits their own work there. As they commit, the copies drift apart. Each computer has work the others have not seen.
To bring the copies together, git uses a remote. It is one more copy of the repository, on a server everyone can reach, usually GitHub. Each computer exchanges commits with the remote, and never directly with another computer.
So working with others is a routine. Share your commits through the remote, and download what the others shared. In this video we do it with one partner, on our game. The same routine scales to a whole team.
The game is already on GitHub, with pause, dark mode, and restart merged into main. Your partner's agent runs git clone with the repository's address. Clone copies the whole repository, every file and all the history, onto their laptop. The repository on GitHub, the one both laptops exchange work with, is called a remote. Each laptop talks to the remote, never directly to the other laptop.
Your partner asks their agent for a sound when the score goes up. The agent builds it on a feature branch, they review it, and it is merged into their main. That commit exists only on their laptop. Making a commit sends nothing to GitHub, and changes nothing on your laptop.
Their agent now runs git push, which sends the new commits to the remote. GitHub now has the sound commit. Your laptop still has the earlier version. Push makes work available on the remote. It does not change any files, on either laptop.
Meanwhile, you ask your agent to save the best score and show it beside the current one. It is reviewed and merged into your main, the same way. Your commit and your partner's commit both started from the same earlier version. Each one contains work the other does not have.
Your agent now runs git push, and git refuses. The message says the remote contains work you do not have. Your main leaves out your partner's sound commit, and git will not drop it. The two histories have to be combined before the result can be shared.
You ask the agent to bring in your partner's work with a merge, keeping both features. The command for this is git pull, with the no-rebase option, which tells git to combine the work with a merge. Pull does two things in a row, and we'll watch them one at a time.
The agent now runs git pull. Step one is the download. Your repository receives the sound commit, and the history it needs. Your main still points at the high-score commit, and your files have not changed yet. Having a commit in the repository is not the same as having its changes in your files.
Step two is the merge. Git merges the downloaded work into your branch, exactly as it merged the two local features earlier. The merge combines the high-score change and the sound change. Its new commit has both earlier commits as parents. If the two changes conflict, git stops the same way as before. Tell the agent what the result should do, and read its resolution before the merge is completed.
Check the combined game before sharing it. Scoring should still produce the sound, and the high score should survive a reload. The agent runs node dash dash test as well. A merge can finish with no conflict and still leave a program that needs fixing.
Your agent now runs git push again, and this time it succeeds, because your main contains everything the remote has. GitHub receives the combined history, with your high score and your partner's sound. Your partner's laptop has not changed yet.
Your partner's agent now runs git pull, and their laptop receives the combined version. Their main fast-forwards. Your merge commit already contains their sound commit, so their main simply moves to it, with no second merge commit.
The same commit is now in all three repositories. They agree because each of you pushed and pulled, not because git keeps the laptops in step by itself. Work that is not committed and pushed is on one laptop only.
There is another way to bring a feature up to date with main, called rebase. Many teams prefer it, and you may too. Let's go back to before we combined the features and consider a different way to do it. Suppose the high-score change were still on its own branch while main already had the sound commit. Running git rebase main on that branch replays your change on top of main's newer commit. The branch gets a new commit that replaces the old one. If the two changes conflict, you resolve that here, in your own branch, before anything reaches main.
Once the branch sits on top of main, moving main forward is a fast-forward. There is no merge commit, and the history reads as one line. That is the point of this workflow. Reconcile in your own branch first, so every merge into main is simple. The merge we did before, shown here at the bottom of the slide, keeps both original commits and shows where the two lines joined, and the conflict is resolved in the merge itself. Both workflows are fine, and the choice is a matter of taste. Try each of them in the lab and see which one you prefer. One rule holds in both. Because a rebase replaces commits, never rebase commits that other people already have, or their history and yours will disagree.
This is the routine for the lab. Each agent's feature gets its own branch and folder. Review and commit the work, merge it into main, and check the combined game. Then share it. Push your work, and pull your partner's. Our game now has five features, from two laptops, and one history. Exchange completed work often, so there is less to combine each time. And when a push is refused, read the reason, and ask the agent to explain what has to happen before it tries again.