Git and GitHub, Part 2

Homework

  1. GitHub Tools
  2. Git

Morning reflection

Housekeeping

  1. Marks returned
    • CPNT 262 Assignment 1
    • CPNT 201 Assignment 3
  2. CPNT 201 Assignment 4
  3. CPNT 201 Assignment 5

1. Ignoring files in Git

Learning Objectives

  • Ignore files in a Git repo using a project .gitignore file.
  • Ignore files in all Git repos using a global .gitignore file.

Materials

Key Takeaways

  • It’s considered bad practice to include system level files to your project .gitignore files. These should go into a global .gitignore file. Examples:

      # Mac
      .DS_Store
      .Spotlight-V100
      .Trashes
    
      # Windows
      Thumbs.db
      desktop.ini
    
      # vi
      *~
    
      # General
      log/
      *.log
    
  • For the purposes of CPNT 262, it’s important that we ignore the following project files and directories (in addition to the system files above):

      # dotenv environment variables file
      .env
      .env.test
    
      # Dependency directories
      node_modules
    

2. Merge conflicts

Learning Objectives

  • Recognize when a merge conflict occurs.
  • Understand what causes a merge conflict.
  • Create a merge conflict in a new repo using the GitHub web interface.
  • Resolve a merge conflict using VS Code.
  • Recognize the difference between a normal commit and a merge commit on GitHub, based on the number of parent branches listed.

Terminology

Merge
When two branches in Git are merged into one. This will often happen if two developers are submitted code to a project or one developer is submitting code from two machines.
Merge conflict
When two branches edit the same line of code. Git doesn’t know which change to keep so it leaves it to the developer to decide when remote code is pulled.
Current Change
The change (relevant to the conflict) that was made on the local repo.
Incoming Change
The change that is incoming from the remote repo.

Materials

Key Takeaways

  • Push code often. When two developers edit the same line of code, the dev that pushed their code last is the one that has to resolve the conflict.
  • It’s sometimes not obvious: after you accept the current/incoming change, you still need to add and commit the changes.

3. Pull requests

Learning Objectives

  • Understand the difference between forking and cloning a repository.
  • Create a new Issue in a public repo.
  • Fork a repo to your GH account.
  • Clone a forked repo to your local machine.
  • Create a branch of a forked repo.
    • Commit changes to a branch.
    • Push commits to remote branch.
  • Create a Pull Request based on a branch of a forked repo.

Terminology

Fork a repository
A GitHub feature - when a 3rd party repo is copied to your GitHub account, including the entire commit history.
Pull request
A Github feature - when a person requests to contribute code to a repo they do not have write privileges for.

Materials

Key Takeaways

  • clone is a Git feature, whereas forking a repo is a GitHub only feature that facilitates contributions from users that don’t have write access on a repo.
  • Submitting a Pull Request still needs to be accepted, which is out of your control.

Open lab-time

  1. Git collaboration practice: Nominate a repo owner from your breakout group and:
    1. Have the owner create a public repo with a default README;
    2. Have the owner add the group members as collaborators;
    3. Each collaborator clones the repo to their local machines;
    4. Pick a single line that each group member will try to edit;
    5. Race: who can add, commit and push their changes to that line of code before anyone else? Everyone else will have to deal with the merge conflicts.

Tony’s goals for Lab-Time

  • Gist for “git collaboration practice”

Dailies

  • Submit today’s Codepen/repo/gist to the Dailies section (in Assessments) in Brightspace.