The Weekend Out Git Exercise

---

If you enjoy our interactive Weekend-Out repository, please share it with others! Show your support by giving it a 🌟 using the ⭐-button at the top right of the page.

By starring the repository, you help increase its visibility, making it easier for others to 🔍 discover and learn 👩‍🎓 how to handle merge conflicts and other scary 👻 Git topics with confidence!

---

Imagine this: A group of friends, tired from their busy university schedules, decides to take a much-needed break. They plan a weekend getaway to the mountains, where they can relax, hike, and enjoy nature. To make sure they don’t forget anything important, they create a shared packing list in a Git repository called “Weekend Out.”

Each friend has their own ideas about what to bring. Bob thinks they need extra blankets for the chilly nights, while Alice insists on packing a portable grill for a barbecue. Carol, the group’s tech enthusiast, wants to bring a drone to capture stunning aerial shots of their adventure.

To keep things organized, they decide to use Git to manage their packing list. They create branches for different categories of items: feature/blankets, feature/grill, and feature/drone. Each friend adds their items to the list and commits their changes.

However, as they merge their branches into the main list, they encounter a problem: merge conflicts! Bob and Alice both added items to the same line in the packing_list.md file. Now, they need to resolve these conflicts to ensure everyone’s items are included.

Thanks god they have learned about Git and how to resolve conflicts through the following exercises:

1. Set up the repository and add items

First, create a new repository using the Weekend Out repository as a template, aka forking. You can easily do this via the Use this template green drop-down list located on the top-right of this page or simply click here.

Note: For the rest of this exercise it is assumed that you also named your repository Weekend-Out!

Clone the repository to your local machine and navigate to the project directory. Don't forget to add your username in the directory path!

git clone git@github.com:<username>/Weekend-Out.git
cd Weekend-Out

Create a new feature/blankets branch and add the items Bob wants to bring.

git checkout -b feature/blankets

open the packing_list.md file, add some items and save the file.

Commit your changes and look at the log to see the commit history.

git add packing_list.md
git commit -m "Add blankets to the packing list"
git log --oneline

Get a feeling for the repository and its commit history.

• Q.1. What is the status of the repository after the commit? On which branch are you now?

Play around with the log command to see the commit history in different formats. Check the man page for an overview of the available options. Some examples are:

git log --oneline --graph
git log --oneline --author="Alice"
git log --oneline --since="2 days ago"

• Q.2. What information is displayed for each commit?
• Q.3. What is the commit hash and what is its purpose?
• Q.4. What's the difference between git log and git reflog?

Push the branch to the remote repository.

git push origin feature/blankets

• Q.5. What does the origin refer to in the git push command? Hint: git remote -v.
• Q.6. What would be the result of the git push command if you didn't specify the branch name? Think of a situation where you need to explicitly state the name of the remote and why this situation might be useful.
• Q.7. In which cases would it be useful to have multiple remote repositories?

2. Locally merge the feature branch into the main branch

You want to include the additional items from the main branch in your feature branch. To do this, you need to merge the feature/blankets branch into the main branch.

On your local machine, switch to the main branch and pull the latest changes from the remote repository.

git checkout main
git pull origin main # or simply `git pull`

Before you continue, think about the following questions:

• Q.8. What is the purpose of the git pull command?
• Q.9. What is the difference between git pull and git fetch?
• Q.10. What would happen if you tried to push changes to a branch that has new commits on the remote repository? Try it out!
• Q.11. What is the difference between git pull origin main and git pull?

Merge the feature/blankets branch into the main branch.

git merge feature/blankets

• Q.12. How could you prevent a merge commit from being created when merging branches? Why would you want to do that?
• Q.13. What would have been the result if you had merged the main branch into the feature/blankets branch instead?

3. Resolve the merge conflict

Oops! It seems Carol beat you to it and has already added some blankets to the list.

Open the packing_list.md file and resolve the merge conflict.

1. The file will contain conflict markers <<<<<<<, =======, and >>>>>>> to indicate the conflicting changes. For example when Bob and Alice both added items to the same line in the packing_list.md file. Bob added "Extra blankets" directly on the main branch, and Alice added "Sleeping bags" on the feature/blankets branch, the file might look like this:

   Blankets
   <<<<<<< HEAD
   - Extra blankets
   =======
   - Sleeping bags
   >>>>>>> feature/blankets
   

2. Edit the file to keep the changes you want to include. In this case, you can keep both items.

   Blankets
   - Extra blankets
   - Sleeping bags
   

3. Save the file and commit the changes.

   git add packing_list.md
   git commit -m "Resolve merge conflict"

Note: You can also use a merge tool to resolve the conflict. E.g.: git mergetool or in IDEs like Visual Studio Code, you can use the built-in merge tool to resolve the conflict. It will show you the changes from both branches side by side, and you can choose which changes to keep.

4. Push the changes to the remote repository

Push the changes to the remote repository.

git push

Now the feature/blankets branch is merged into the main branch, and the conflict are resolved. The packing list is updated with the items from both branches.

• Q.14. Which strategy would you have had to use to merge the feature branch into the main branch without creating a merge conflict?
• Q.15. Is avoiding a merge conflicts generally a good strategy?

---

---

Part 2: Feature Branch Development Cycle and Conflict Resolution Online

Now that you've set up the repository and added items locally, it's time to walk through a feature branch development cycle using the project management tools provided by GitHub. Part 2 will focus on working entirely online in the remote IDE.

1. Creating a Project Board and Tasks

Carol, the tech enthusiast, wants to bring a drone and suggests creating a dedicated packing list since the drone requires specific additional items.

She starts by creating an Issue to explain how she would like to reorganize your packing list.

• Go to the repository on the remote server: Weekend Out

  • Create your own Weekend-Out Repository using this repository as a template OR continue on the repository you used for Part 1.

    Note: For the rest of this exercise, we assume that you've also named your repository Weekend-Out!

• Go to your own Weekend-Out repository and open a new Issue for Carol. Name it Package list restructuring (Please keep the name as is!) and add a brief description of what Carol wants to do.

2. Creating a New Feature Branch Online

Carol has added the items she wants in the list as a comment to the Issue. With that, you're ready to begin:

• Refresh the Issue page to see Carol's comment (actually posted by a GitHub bot) with the items she wants to add.

• Create a new branch directly from the Issue's web view. (You find this option on the right under "Development")

• Keep the suggested branch name as is, and checkout the newly created branch on your device.

• On the webinterface of your repository, create a new markdown file for Carol's drone list (by clicking on the + button next to "Code") and add the items she mentioned in her comment.

• Once you’ve made your changes, commit them to the new branch on your remote repository.

• Q.1. How does the process of creating a new branch and committing changes differ between the local and remote environments? Which step is missing in the online process?

3. Create a Pull Request

Now that you've implemented the requested feature on the remote repository, you can create a pull request to formally propose merging your feature branch into main.

• Refresh your Weekend-Out Repository on GitHub. You should see a notification bar prompting you to open a Pull Request. If you don't see it, click on "Pull requests" and then "New pull request".

• Assign yourself to the Pull Request, and go ahead and create it.

• You will be redirected to your pull request's details. For now, ignore the "Checks", but take a look at the tabs "Commits" and "Files changed".

4. Merging the Feature Branch into Main

If you are satisfied with your edits, you can consider merging your feature branch into the healthy reference main.

• Remember, it's your responsability to ensure the changes you introduce are compatible with the main branch at the time of merging - not based on a prior state!

• If everything looks good, merge your branch by clicking on the green "Merge pull request" button at the bottom of the Pull Request page. Confirm by clicking "Merge".

5. Inspect What Just Happened

You've just completed a Feature Branch cycle! 🥳🎈Congrats!

• Go to the Issues tab of your Weekend-Out repository and check the issue you created earlier. If everything went according to plan, your Issue should now be marked as closed.

  Hint: If you want to close multiple issues with one pull request, you can use the closing keywords closes, fixes, or resolves followed by the issue number in the pull request description. E.g. closes #1 (when you start typing closes #, GitHub will suggest the issue number).

• Now, head to the "Code" tab and have a look at the content of the repository. You should see the new file for Carol's drone list - so far, so good!

  But wait! There is another file named Carols_drone_list.md with the commit message: "Adding Carols drone list". Click on the message, and you will be directed to the detailed view of the commit whith which Alice added that file.

It seems not everyone was informed that you were in charge of the drone list and Alice went ahead and took care of it.

Now, without casting blame around, it would be helpful to understand how the healthy reference branch (main) ended up with two files for the same list.

• Q.2. Who was first to add the list to main?

• Q.3. What did you do wrong, if anything?

• Q.4. What did Alice do wrong, if anything?

• Discussion: How can such a situation be avoided?

Hints:

• The "Insights" tab in your Weekend-Out Repository has a Network view (Note: Only accessible in public Repositories). The Network view depicts a chronologically ordered graph with all commits.

  Alternatively: If you prefer not to make your Weekend-Out repository public, you can view the "Network" in your command line:

  git checkout main
  git pull
  git log --all --decorate --oneline --graph