Git for Pairs

Learning Goals

Outline a workflow for collaborating on a single repository
Identify and resolve merge conflicts

Review

Let’s go over the following Git terms you reviewed in preparation for today’s lesson:

Git
Github
Local Repository
Remote Repository
Commit
Push
Branch

Part 1: Paired Process

In this scenario, a developer (we’ll call them Player 1) is creating a repository about the 50 U.S. states. Player 1 recruits another developer (let’s call them Player 2) to assist.

P1: Create new local repo

P1: Add collaborator in Github

P1: Create new branch and Pull Request

Player 1	Player 2
Create new local repo: `US_States` Add `all_states.txt` file Add title to `all_states.txt` file Add, Commit, Push to GitHub
Add collaborator in GitHub
Checkout new branch: `north_carolina` Add `north_carolina.txt` file Add “North Carolina” to `all_states.txt` file Add, Commit, Push to GitHub

Part 2: Adding collaborators

We’ve added a new step to the process: adding a collaborator. Player 1 has invited Player 2 to contribute to the repo. There are several options when adding a collaborator; in this case, we want both developers to have equal access and rights to the repository.

P2: Accept GitHub invitation

Player 1	Player 2
	Accept invitation on GitHub Clone `US_States` repo to local
	Checkout new branch: `colorado` Add `colorado.txt` file Add “Colorado” to `all_states.txt` file Add, Commit, Push to GitHub

Cloning a repository

Player 2 has performed two important tasks.

First, they have cloned the repo created by Player 1. To clone a repository means to copy a remote Github repository to your local computer. 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.

Second, Player 2 has created content in a separate branch, but it not yet merged with the main branch. We’ve discussed how to merge branches, but we want one additional step to ensure that both developers agree on the content.

Part 3: Pull Requests

Player 1 and Player 2 now each have their work on separate branches. The way they get their code to be part of main is through a pull request. A Pull Request informs all collaborators of the changes made to a branch and the desire to merge this branch with another branch (usually the main branch).

Player 1	Player 2
Create a pull request to merge your `north_carolina` branch into `main`
	Review and comment on Player 1’s PR Merge Pull Request

Player 2 can review, comment, and merge the Pull Request. Player 1 can also add commits to the PR. There can be several rounds of reviews, comments, and additional commits before it is merged.

P1: Review Pull Request and Resolve Merge Conflict

Player 1	Player 2
	Create Pull Request on GitHub to merge `colorado` into `main` Fix the merge conflicts in Github

There’s Good News and Bad News. The Good News is that Player 1’s North Carolina content has been successfully merged into the shared repo. The Bad News is that when we integrate those changes into our current branch, we encounter a pesky Merge Conflict. But there’s more Good News: fixing a Merge Conflict when working with a collaborator is no more difficult than working solo.

Part 4: Merge and Update Main Branch

P1: Fetch and Pull main branch

Player 1	Player 2
Review and comment on Player 2’s PR Merge Pull Request

Let’s answer a question before it’s asked: YES, even though Player 1 owns this repo, they also make pull requests so that their changes are reviewed by the other collaborators. And YES, the process for Player 2 is the same.

P1 & P2: Sync local repo

Player 1	Player 2
Checkout `main` branch Pull `main` branch
	Checkout `main` branch Pull `main` branch

The changes from both Player 1 and Player 2 have been merged. However, neither developer have ALL of the changes on their own local machine. Let’s fix that.

Player 1 will check out their main branch, then pull down the main branch from GitHub. Then Player 2 will do the same thing. Or maybe Player 2 does it first, then Player 1. Maybe they do it at the same time.

The Reality

For the sake of education, this process was presented as a linear process: Player 1 does something while Player 2 waits. Then Player 2 does something while Player 1 waits. It’s like a relay race.

However, that’s not usually the case.

Player 1	Player 2
Create new local repo: `US_States` Add `all_states.txt` file Add title to `all_states.txt` file Add, Commit, Push to GitHub
Add collaborator in GitHub	Accept invitation on GitHub Clone `US_States` repo to local
Checkout new branch: `colorado` Add `colorado.txt` file Add “Colorado” to `all_states.txt` file Add, Commit, Push to GitHub	Checkout new branch: `north_carolina` Add `north_carolina.txt` file Add “North Carolina” to `all_states.txt` file Add, Commit, Push Create PR on GitHub
Review and comment on Player 2’s PR Merge Pull Request Pull `main` branch Fix Merge Conflict Add, Commit, Push to GitHub Create PR on GitHub
	Review and comment on P1’s PR Merge Pull Request
Checkout `main` branch Pull `main` branch	Checkout `main` branch Pull `main` branch

Once Player 1 invites Player 2 as a collaborator, much of the process happens simultaneously. There’s little reason to “wait” for other developers to finish before working on a new task. In fact, either developer could move onto a new branch (perhaps virginia or new_york) while the other continues working. Making pull requests and fixing conflicts along the way is par for the course.

Rules of Engagement

Git Pairing Tips

You will practice this often when working in pairs and groups throughout your time at Turing and in your new career. There are a few basic rules you should follow:

NEVER work directly on the main branch. NEVER EVER EVER EVER.
Always checkout a new or existing branch. If there is an open Pull Request and you need to add or change something related to that content, checkout the existing branch. Otherwise, create/checkout a new branch.
A good habit is to prefix the branch you’re working on with your initials: e.g. rt-north-carolina , zf-colorado. This easily informs all collaborators of the branch’s author.
Another good habit: if you are working with collaborators, try to avoid approving and merging your own Pull Requests. Another developer should perform those tasks. In a team of two, the non-author of the PR should approve and merge it. With a team of three or more, it’s not uncommon that another developer will approve the PR, and a third developer will merge it.
Did we mention to never work on the main branch?