NiiL

Week 4 · Collaborate with a change history

English translation

Before practice

Review the learning material's example: Recall reviewing an external user's proposed changes before applying them to the original. Here, examine each stage's role in your own repository.

01 Why record changes?

Example scenario If a problem arises after editing setup instructions, how can you check what changed?

Description
  • Recording changes in the history with a description is called a Commit.
  • Comparing the content before and after editing shows where the missing preparation step was added and whether other explanations changed too.

02 How multiple people collaborate

What process is needed to accept improvements from others without granting direct edit permission?

Description
  • A contributor makes changes in their own copy and sends a Pull Request (PR) asking that they be applied to the original. The maintainer can review the changes and their rationale first.
  • Edit in a Fork or Branch → Commit → PR and review → Merge. This separates the opportunity to propose changes from permission to apply them to the original. Skip the Fork when practicing in your own repository.

Practice

First examine change history, then practice collaboration. In Colab, examine the relationship between file edits, Commits, and Branches without GitHub login or permission settings. Then create your own repository on the GitHub website, review changes through a PR, and Merge. These are separate exercises for learning Git history and GitHub review and integration, respectively.

1. Practice Git in your own workspace

  1. Practice change history in Colab
    In a temporary Repository, compare files before and after edits and inspect Commit history. Edit one sentence in the example and repeat git diff → add → commit → log yourself.

  2. Create a practice Repository on GitHub
    Create a new GitHub repository for practicing PRs and Merges. Create a personal practice Repository with a README. This step does not upload the temporary Colab repository.

  3. Edit and Commit on a Branch
    Create a new Branch practice, add what you learned this week to the README, and Commit.

  4. Review the PR and Merge
    Open the Pull Request for practice → main, review the changes under Files changed, and Merge.

  5. Explain the changes
    Explain the roles of the two Branches and the differences before and after Merge to a teaching assistant or peer.

  6. Record results
    Record the Repository URL, Commit history, PR changes, and completed Merge screen in the Notebook.

Submission and saving

Include the edited content, Commit, Pull Request, and Merge history, and notes explaining what you did at each step. Submit through KLAS; check the semester schedule and latest announcements for deadlines.

Capture your GitHub collaboration results in screenshots showing changes in the repository, Branches, and PRs, and the Merge history. Exclude credentials. The Notebook is for practice and notes.

Restart the runtime, run all code from the top, then save.

Optional practice

Proceed when a peer has a public Repository for practicing together.

  1. Fork your peer's Repository and create a Branch in your Fork.
  2. Edit one explanatory sentence in README.md, then Commit and Push.
  3. Open a Pull Request to the original Repository and explain the reason for the change in one sentence.
  4. In a Text Cell in the notebook, record the Pull Request URL and the sentence you changed. Explain why you can propose changes without permission to Push directly to the original Repository.