Assignment #5: Communication Log

Coding together allows you to work as a team so you can build bigger projects faster. In this assignment, you will practice the common Git commands used when two or more people work on the same project.

You and a partner will take turns modifying some shared code. The two of you will work on your own devices, and you will push and pull your commits to a GitHub repository.

In the Git chapter exercises and project, you worked with both a local and a remote repository. This assignment extends those ideas.

You will practice:

  1. Forking and cloning a repository from GitHub.

  2. Adding partners to a shared GitHub Project.

  3. Quickly trading code in push and pull cycles.

  4. Merging two branches in GitHub.

  5. Resolving merge conflicts (which are not as scary as they sound).

The Story

You are going to carry out a conversation between a pilot and their base. Between the two of you, choose who will be the Pilot and who will be the Base. If you have three people in your group, add another pilot role.

Even when it is not your turn to actively code something, watch what your partner is doing. The steps in this activity mimic a real-world Git workflow for a shared project.


You will be working with branches. It’s very likely your team will accidentally add code to the wrong branch. When this happens, refer to the git stash notes to move your changes to the correct place.

Part A: Project Setup

This part needs to happen on ONE person’s computer. Whoever plays the role of Base will git things rolling. However, the Pilot should definitely be looking over Base’s shoulder.

  1. Base: In a web browser, click the link to this GitHub repository. It contains the starter code needed for the assignment.

  2. Base: In the upper right corner of the page, click the Fork button. This adds a copy of the repository to your own GitHub account.

    The GitHub Fork button.
  3. Base: Return to your GitHub home page and check for the communication-log repo. Click on its name to view it. The URL will look something like The your-username part of the address will show your GitHub name.

Pilot: Thanks for sitting by patiently!

Clone the Project from GitHub

Base now has a copy of the repository in their GitHub account. The next step is for each team member to clone that repo onto their personal device.

  1. Pilot and Base: Open Visual Studio code. Use terminal commands to navigate into your local_practice directory. Use pwd to confirm your location.

    $ pwd
  2. Pilot and Base: In a browser, navigate to Base’s copy of the repo (see step 3 above). Click on the green Code button. Select the HTTPS option, then click the Copy button.

    The GitHub Clone button.

    Clone a repository from GitHub.

  3. Pilot and Base: In the terminal pane of VS Code, enter the git clone URL command. Replace URL with the address you copied from GitHub.

Add a Partner to the Repository

All team members should now have a local copy of the repository. However, only Base can make changes to what is stored on GitHub. To fix this, one more setup action is necessary.

  1. Base: In your web browser, go to your communication-log repo. Click the Settings button then select the Manage Access option.

    Click "Settings" and "Manage Access" to let other users modify the repo.

    Manage access to your repo.

  2. Base: Click on the green Invite teams or people button. Enter your partner’s GitHub username and grant them the proper level of access. Admin gives them the ability to delete the repo from your account at any time. The Write and Maintain roles allow them to edit the repo but not delete it.

    When ready, click Add to repository.

    Enter a GitHub username, then click the Add button.

    Choose who else can modify your GitHub repo.

  3. Pilot: You should receive an email invitation to join this repository. View and accept the invitation.


Pilot: If you don’t see the email, check your Spam folder. If you still don’t have the email, login to your GitHub account. Visit the URL for Base’s copy of the repo. You should see an invite notification at the top of the page.

Whew! That was quite the setup experience. Now you’re ready to dive into the main part of the assignment.

Part B: First Message Exchange

In this part, you and your partner will take turns adding commits to the shared code. Follow the steps carefully, and try not to get ahead of each other.

  1. Base: In Visual Studio Code, open the index.html file from the repository. Replace Enter the first communication line here with a short greeting to your Pilot.

  2. Base: Save and commit your change with the usual status/add/commit process. Next, send your commit up to GitHub with the command:

    $ git push origin main


Remember that you can open a local HTML file in your browser. If you do this with index.html, then you can track your progress by refreshing the page after each change.

Pull Base’s Line and Add Another Line

  1. Pilot: In Visual Studio Code, open your local version of index.html. Notice you don’t have the new line of code that Base just added.

  2. Pilot: In the terminal, enter this command to pull down the new code from GitHub:

    $ git pull origin main
  3. Pilot: In VS Code, you should now see Base’s greeting! Respond to this by adding a new HTML element and some text. Save, commit, and push your changes up to GitHub.

Pull Pilot’s Line and Add Another

  1. Base: Notice that you can’t see what Pilot added yet. Fix this by entering git pull origin main in the terminal.

  2. Base: Now add a third line to the log. Save, commit, and push your change up to GitHub.

Part C: Rinse and Repeat

Pilot and Base: You can both play with this for a while! Repeat the cycle a few more times to add to your story.


The story can go anywhere! Be creative, and try to make each other laugh. If possible, keep your new lines secret from your partner. That way, the pull result will be a surprise.

Part D: Create a New Branch

This back-and-forth workflow is nice, but it can get in the way. After all, professional developers don’t sit around waiting for their teammates to commit and push a change before starting their own work. Fortunately, Git branches allow partners to work on a project at the same time and at their own pace.

  1. Pilot: While Base is working on the next part of the story, use the terminal to create a new branch called open-mic.

    $ git checkout -b open-mic
    Switched to a new branch 'open-mic'
    $ git branch
    * open-mic
  2. Pilot: In VS Code, open style.css and add the following rule:

    body {
       color: white;
       background-color: black;
  3. Pilot: Save and commit your changes. Next, push the new branch up to GitHub with the command:

    $ git push origin open-mic
  4. Base: To pull down the new open-mic branch, enter the command:

    $ git pull origin open-mic


    If you don’t know the name of the new branch, then just enter git pull. This will pull down all new branches and show you a list of the options.

  5. Pilot and Base: If you haven’t already done so, open index.html in a browser to see what it looks like.

Great progress! Now let’s figure out how to merge two branches in GitHub.

Part E: Create a Pull Request In GitHub

  1. Pilot and Base: In a browser, navigate to the shared GitHub project page. Click on the dropdown menu just above the list of files to show a list of the branches. Select open-mic.

    GitHub dropdown menu showing available branches.
  2. Pilot: After selecting the open-mic branch, click the Pull request button.

    GitHub pull request button.

    This sets up a request to merge the changes from open-mic into the main branch. Add some text in the description box to let Base know what you did and why.

  3. Pilot: The branch selected in the base dropdown is the one you want to merge into, while the branch in the compare dropdown is the one you want to merge from.

    GitHub pull request window.

    Open a PR in GitHub.

  4. Pilot: Once everything looks good, click the Create pull request button.

Merge the Pull Request

Pilot opened a new Pull Request. Now, Base will take care of it!

  1. Base: In your browser, return to your repo in GitHub. Click on the Pull Requests button. Next, click on the title for the one and only PR.

    Review the PR details.

    Click to review the details of the pull request.

  2. Base: The page that opens shows the history of all the commits made to the open-mic branch. When ready, click the green Merge Pull Request button, followed by Confirm Merge.

    Confirm the merge request.

    Finally! Merge the pull request.

    Upon a successful merge, you should see feedback similar to:

    Feedback given for a successful merge.

    Nice! Another successful merge of remote branches.

  3. Pilot and Base: The changes from open-mic are now in the main branch, but only on GitHub. You need to pull the updates to your main branch.

    $ git checkout main
    $ git pull origin main

Bonus: Merge Conflicts!

When teaming up on a project, things won’t always go smoothly. It’s common for two people to change the same line(s) of code on their separate machines. This prevents Git from being able to automatically finish a merge.

An animated GIF file showing two opposing armies colliding in a mess.

Merge conflicts!

Merge conflicts often occur, and they are not a big deal. You learned how to deal with them locally in the Git chapter. Now, you will set up a conflict with the remote repository.

  1. Pilot: In VS Code, switch back to the main branch.

  2. Pilot: Change the style.css file. The HTML is looking pretty plain, so spice up the body style rule to look like this:

    body {
       color: white;
       background-color: #333;
       font-size: 150%;
       font-family: 'Satisfy', cursive;
       margin: 5em 25%;

    The result:

    Our HTML page with a fancy font


  3. Save and commit the changes, then push them up to GitHub.

    $ git push origin main


  1. Base: In VS Code, switch back to the main branch.

  2. Base: In your local style.css file, change the body rule to look like this:

    body {
       color: white;
       background-color: black;
       font-family: 'Sacramento', cursive;
       font-size: 32px;
       margin-top: 5%;
       margin-left: 20%;
       margin-right: 20%;
  3. Base: Save and commit your changes to main.

Fix the Merge Conflicts

Base: Try to push your changes up to GitHub. You should get an error message. How exciting!

$ git push origin main

To [email protected]:username/communication-log.git
! [rejected]        main -> main (fetch first)
error: failed to push some refs to '[email protected]:username/communication-log.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.

There’s a lot of text in the message. However, the main idea is clear: Updates were rejected because the remote contains work that you do not have locally.

Somebody (Pilot, in this case), pushed changes to main, and you don’t have those commits on your computer. To fix this, begin by pulling those changes down from GitHub:

$ git pull

   7d7e42e..0c21659  main     -> origin/main
Auto-merging style.css
CONFLICT (content): Merge conflict in style.css
Automatic merge failed; fix conflicts and then commit the result.

Since Pilot and Base both made changes to the same lines of code, Git cannot automatically merge the changes.

Base: Review how to resolve merge conflicts in VS Code. Follow the same steps to fix the problems in style.css. Once done, save, commit, and push the final results up to GitHub.

Pilot: Once your partner finishes resolving the merge conflict, be sure to pull down the new main branch.

More Merge Conflicts!

Turn the tables so Pilot can practice resolving a merge conflict.

  1. Base and Pilot: Decide which file and lines of code you will both change. Make different changes in those places.

  2. Base: Save, commit, and push your changes up to GitHub.

  3. Pilot: Try to pull down the changes, and notice that there are merge conflicts. Resolve them, then save, commit, and push the result.

  4. Base: Pull down the final, resolved code.