Update

We have updated the content of our program. To access the current Software Engineering curriculum visit curriculum.turing.edu.

Git for Pairs

Learning Goals

  • Describe the flow integrating git and github
  • Describe how two people might work off the same repository
  • Describe steps to resolving a merge conflict

Vocabulary

  • Merge Conflict
  • Pull Request (PR)
  • Clone
  • Fork

WarmUp

Review: Git Commands

Create a local repository>

  • git init

Save updates

  • git status
  • git add file_name
  • git commit -m “Add message”

Create and switch to new branch

  • git checkout -b branch_name
    OR
  • git branch branch_name
  • git checkout branch_name

Interact with remote

  • git pull origin branch_name
  • git push origin branch_name
  • git remote -v
  • git remote add origin

Clone vs. Fork and Clone

Cloning is when you copy a remote Github repository to your local computer. You clone a repository with:

git clone <ssh key for repository>

Whenever you clone a repository, you interact with that repository by pushing and pulling branches. Therefore, when you are working with teammates, i.e. in a group project, you all need to clone the same repository so that you are all working in the same code base.

Sometimes, you want to work on a code base that you do not own or don’t have permission to change. For example, Turing often provides starter repositories for your projects. You do not have permission to change these repositories, so in order to work with them in Github, you need to create a Fork. Forking is creating your own copy of a Github repo. This new repo will be associated with your username, so you have permission to change it. After you create a fork, you clone that forked repository the same way you clone a repository that you created from scratch.

Merge Conflicts

When you submit a Pull Request, git merges code from one branch into another. Usually, git is merging a feature branch into the main branch. Git has rules that it uses to determine what the code should look like after the merge. However, there are some instances where git can’t automatically figure this out using its rules, so it needs you to manually tell it what the code should look like after the merge. This is called a Merge Conflict. The easiest way to resolve one is using Github’s Merge Conflict Tool. Git represents a merge conflict by inserting some text into the file where the conflict happened. It will look something like this:

<<<<<<<< branch_name
 # Code from the branch_name Branch
========
# Code from the main Branch
>>>>>>>> main

In order to fix it, you need to change the text of the file to include only the desired code.

Git Flow for Pairs

Person A

  • Make a new directory and cd into it
  • Check that repo is not already inited (git status)
  • Initialize repo locally (git init)
  • Create a repo on GitHub (repositories/new)
  • Add remote to local (git remote add origin <ssh key to remote>)
  • Check successful addition (git remote -v)
  • Check git status (git status)
  • Make a file (create a class) (touch filename.rb)
  • Add some code to the file (Add an initialize method, some attributes, and attr_readers.)
  • Commit
  • and push
    • git status
    • git add filename.rb
    • git status
    • git commit -m "initial commit"
    • git push origin main
  • Add collaborator on github

  • Check out new branch (git checkout -b new_feature)
  • Changes the existing file (the name of the class and some of the attributes - don’t change the filename)
  • Commits and pushes to branch
    • git status
    • git add filename.rb
    • git status
    • git commit -m "change to first line"
    • git push origin new_feature
    • Do NOT do anything on GitHub, switch to Person B

Person B

  • accepts invitation
  • clones repo (git clone <ssh key to repo>)
  • cds into cloned repo
  • checks out a new branch (git checkout -b add_content)
  • changes the existing file (change class name and the attributes to something different than person A did)
  • commits and pushes to branch
    • git status
    • git add filename.rb
    • git status
    • git commit -m "changes first line"
    • git push origin add_content
  • Creates a Pull Request on Github

-Stop Here until your next break out room session-

Person A

  • Review and comment on Person B’s Pull Request
  • Merge Person B’s Pull Request

Remote main is now updated.

From new_feature branch (should already be on this):

  • pulls origin main into new_feature
    • git pull origin main
  • fixes merge conflict
  • commits and pushes to remote new_feature
  • creates pull request on Github

Person B

  • Review and comment on Person A’s Pull Request
  • Merge Person A’s Pull Request

Both

  • Checkout local main and pull from main
    • git checkout main
    • git pull origin main

Checks for Understanding

  • What is the git workflow when working with a partner on a separate computer?
  • What is a merge conflict? How might you resolve a merge conflict?

Additional Resources

Git - the Simple Guide Pro Git

Lesson Search Results

Showing top 10 results