A Git Pair Programming Workflow WalkThrough
Tags: git, github, beginners
Published: 2022-03-01 01:51:32

Git and Github exists to help us keep track of who is making a change in the remote versus local spaces especially when we're working collaboratively.

Collaborative Git workflows are usually determined based on the team that we're working in. Since there are all sorts of team types that exists in the world, then there are also different workflows that exist. We'll be covering a workflow walkthrough for working in the same workstation (also known as pair programming).

The following workflows are written with the assumption that we're working in a relatively small team (2-30 people).


### Data Movement
To review, our data moves from local locations to remote locations and vise versa.
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/32lofjnx33f3n56ek44l.jpeg)

### One Workstation Workflow: for Pair Programming Team Members
Person A Driving:
Step 1. the first step to working with Git and Github is to clone the remote's repository with `git clone`. Once Person A runs `git clone` they're able to `cd` into their local copy of the remote repository and start working locally.

Then they can move on to steps 2-11. To view the more detailed walkthrough of these steps, feel free to read the previous blog post in this series on [Git Individual Workflow](https://dev.to/adelinealmanzar/a-git-individual-workflow-walkthrough-po7).
Step 2. `git branch`: view current branch & view all branches in our local repository
Step 3. `git pull origin master`: pull remote master branch data to our local master branch
Step 4. `git checkout -b personA-branch`: create a new local branch and move to that branch
Step 5. `git branch`: sanity check that we're in proper new branch
Step 6. Make code changes
Step 7. `git status`: shows what files have had changes made & shows whether our files have been staged or not (green for yes, red for no)
Step 8. `git add filePath/wanting/toStage.txt`: add files, via their file paths, to the staging/index area
Step 9. `git status`: sanity check that only preferred files are staged/added to index
Step 10. `git commit -m "any commit message"`: snapshot currently staged changes via a singular commit & write concise message
Step 11. `git log`: view our commit history to sanity check that our most recent commit is at the top of the history list

Step 12. Person A can keep making local code changes and looping through steps 6-11 before moving on to step 13.

Step 13. Once Person A's local repository is at a ready-enough state for their team's review and/or collaboration, they can push their changes to the remote repository with `git push origin personA-branch`.
`git push` will send all of Person A's local repository's commits and branches to the remote repository (in Github).

Step 14. When Person A signs into Github and visits the remote repository, they should be able to create a new pull request(PR). Pull requests are akin to a form requesting to officially merge Person A's changes to the remote branch they originally branched-off of. PRs enable team members to share the purpose of their code changes in layman's terms. PRs also enable team members access to review changes and view diffs from making changes collaboratively.

At this point, Person A can take a backseat for the moment while Person B drives.

Person B Driving:
Step 15. Person B will need to `git clone` the remote repository to have a local copy of the repository on their machine, same as Person A had.

The fun part is that now that Person A's work is available remotely (because Person A `git push`-ed), Person B can fetch and checkout a local copy of the remote branch that Person A just pushed.

Step 16. `git fetch --all` fetches all remote branches and makes those branches available locally to Person B.
Fetch _will not_ move any code changes; fetch will only move _meta data_ (such as branches) from the remote space to Person B's local machine. So, Person B can fetch in any branch and as often as they like.

Step 17. After fetching, Person B is able to checkout Person A's branch.
```
user@ repo-name % git checkout personA-branch     
Branch 'personA-branch' set up to track remote branch 'personA-branch' from 'origin'.
Switched to a new branch 'personA-branch'
```
Running `git checkout` will 1. create a new local branch, called `personA-branch` in Person B's workspace, 2. set up this newly created local branch to track its remote counterpart with the same name, and 3. place Person B in their newly created local `personA-branch` copy branch.

Step 18. Running `git branch` again to sanity check that Person B is in the proper branch should yield something like this:
```
userB@ repo-name % git branch
master
*personA-branch
```

Step 19. Now, when Person B runs `git pull`, they are pulling the updated commit history from Person A's remote branch (called `personA-branch`) to Person B's local copy of Person A's branch (also called `personA-branch`). If the remote repository has no changes, then `git pull` will show an 'Already up to date' message.
```
user@ repo-name % git pull origin personA-branch
From github.com:PersonA/repo-name
 * branch         personA-branch     -> FETCH_HEAD
Already up to date.
```
Reminder: everyone should `git pull` _only_ the remote branch name that matches the local branch they are currently in.

Step 20. Person B's local copy of PersonA's branch will end up tracking the version history of Person B's local changes via commits.
So, Person B can go ahead and complete steps 6 - 11 while making code changes and adding those to their commit history.
`git log` within the 11th step will show Person B's local commit history that Person B made to their local copy of Person A's branch.

Step 21. In order to update Person A's remote branch, Person B would run `git push origin personA-branch`.
On Github, Person A and Person B should both see the remote branch was updated with Person B's commit history.

To switch drivers, Person A and Person B can each take turns with steps 17-21 until the PR is ready to be reviewed and merged to the branch PersonA's branch had originally branched off from.


##TLDR: One Workstation Workflow (for Pair Programming)
1. `git clone repo-link && cd PersonA-repo`: make a clone/local copy of PersonA’s remote repository and move into it
2. `git branch`: view current branch & view all branches in our local repository
3. `git pull origin master`: pull remote master branch data to our local master branch
4. `git checkout -b personA-branch`: create a new local branch and move to that branch
5. `git branch`: sanity check that we're in proper new branch
6. Make code changes
7. `git status`: shows what files have had changes made & shows whether our files have been staged or not (green for yes, red for no)
8. `git add filePath/wanting/toStage.txt`: add files, via their file paths, to the staging/index area
9. `git status`: sanity check that only preferred files are staged/added to index
10. `git commit -m "any commit message"`: snapshot currently staged changes via a singular commit & write concise message
11. `git log`: to view commit history to sanity check that most recent commit is at the top of the history list
12. Driver can keep making local code changes and looping through steps 6-11 before moving on to step 13
13.  `git push origin personA-branch` push driver’s commit history to remote repository
14. Driver creates pull request(PR) in Github & drivers switch (so from this point forward, actions should be of new driver)
15. `git clone repo-link && cd repo-name` clone the remote repository to the new driver’s local machine
16. `git fetch --all` fetches all remote branches and makes those branches available locally to the new driver
17. `git checkout personA-branch` in the new driver’s workspace: creates a new branch that matches the remote branch name (personA-branch), tracks the remote counterpart, and places the new driver in their local `personA-branch` branch
18. `git branch` to sanity check that new driver is in the proper `personA-branch` branch.
19. `git pull origin personA-branch` pulls the updated commit history from Person A's remote branch (called `personA-branch`) to Person B's local copy of Person A's branch (also called `personA-branch`)
20. New driver can keep making code changes and adding those to the commit history by repeating steps 6 - 11
21. `git push origin personA-branch` update remote `personA-branch` with new driver’s local commit history
22. Switch drivers and new driver will repeat steps 17-21 until PR is ready for to be reviewed and merged

#### Resources
1. [A git commands cheat sheet](https://education.github.com/git-cheat-sheet-education.pdf)
2. [Git Guides](https://github.com/git-guides/)
3. [Git fetch documentation](https://git-scm.com/docs/git-fetch)