Last updated on

Git III: Collaboration

Here are a few questions, exercises, and resources to guide your exploration of version control systems. Feel free to ask on Ed or in exercise sessions if anything is unclear!

If you ask a complex Git question on Ed, it will often be much easier for us to help you debug if you include a copy of your repo. For this, post your repo as a git bundle in a private Ed post (look up the documentation of git bundle to know what it does).

Make sure you have good backups before experimenting with your computer on the command line!

These exercises are written with just enough information to specify what to do, but they don’t specify how to do it. We expect you to look things up in the manual pages, online, or to discuss it among yourselves. But whichever source you use, make sure that you understand what you are doing! Don’t just blindly copy-paste commands.

To be able to work together with other colleagues without exchanging patches by email, you need to have a copy of the repository that all collaborators can access. Let’s see how to use Gitlab for that.

Please do not upload CS-214 exercises or labs to a public repository. Whether if you use Github or Gitlab, make sure to use private repositories.

As usual, ⭐️ indicates the most important exercises and questions and 🔥 indicates the most challenging ones. Exercises or questions marked 🧪 are intended to build up to concepts used in this week’s lab.

You do not need to complete all exercises to succeed in this class, and you do not need to do all exercises in the order they are written.

Configuration ⭐️

  1. Create a private repository on https://gitlab.epfl.ch. Do not initialize the repository with a Readme.

  2. You’ll quickly get tired of typing a password every time, so let’s configure SSH key authentication instead:

    1. Confirm that you already have a key, or generate a new one.
    2. Add your key to your Gitlab account.
    3. Verify that you can connect using your key

Pushing ⭐️

  1. Create a new folder and initialize a new Git repository in it.

  2. Add a file to the repository and commit it.

  3. Add a remote to your repository that points to the repository you created in the previous exercise.

  4. Push your changes to the remote repository.

Fetching ⭐️

  1. Clone a second copy of your repository.

  2. In your first clone, make changes to various branches and push them.

  3. In your second clone, run fetch. What do you see?

  4. Use git merge or git reset --hard or git pull --rebase (when does the difference matter?) to update your second clone’s local branch pointers.

Recovering from upstream rebases 🔥

  1. In your first clone, from main, create a branch, add multiple commits to it and push them.

  2. In your second clone, pull these changes (fetch + merge or pull or fetch + reset).

  3. Back in the first clone, use git rebase to modify the contents or messages of your commits.

  4. Push the modified commits to Gitlab.

  5. In your second repository, use fetch to retrieve this new commits. What situation are you in?

  6. Read the Recovering from upstream rebase section of the Git book and follow its guidance to recover.

Code review

Branch-based workflow

  1. Invite a classmate to your repository using the Gitlab UI.

  2. Create a “merge request” (called a “pull request” on Github) from one of your exercise branches to main.

  3. Ask your classmate to perform a code review on your merge request, using the Gitlab UI.

  4. Implement suggested changes as additional commits. Have your classmate review the changes and approve them before merging the branch.

Patch-based workflow 🔥

  1. Use git bundle to send a copy of your main branch to a classmate.

  2. Set up git send-email on your machine, and use it to send a patch to your classmate.

  3. Have your classmate apply the patch, and perform a review by commenting on the patch directly inline, in an email.

  4. Apply the changes and send a new set of patches to your classmate. Have them compare the changes using git range-diff.