Author: @PiotrBerebecki
Maintainer: @PiotrBerebecki

Git Workflow Workshop for Two Programmers 💻 💻

Workshop summary

An exercise to practice git workflow skills. The workshop should be undertaken by two programmers, working on two computers. The skills practiced include:

cloning a repository
creating branches
switching branches
adding changes to staging area
committing changes
pulling latest version from the remote master branch
merging master branch into recently created branch
resolving merge conflicts
pushing to remote repository
creating a pull request on GitHub
merging a pull request on GitHub

Initial setup 🚀

You're working in a team of two on a project for a new client.

Step 1 - Create a new GitHub repo and clone it

Go to your cohort's GitHub organisation and create a new repo, initialising it with a README.md.
Clone this new repository using your terminal.

$ git clone 'PASTE THE URL OF YOUR REPOSITORY HERE'

Move into the newly created directory.

$ cd git-workflow-workshop-for-two

This is what your remote and local repositories look like after this. HEAD is a reference to your current location.

Step 2 - Raise your issues on the work to be done

Normally, you would decide on which "features" you were going to build and then break these down into smaller issues before starting the work.

For the sake of this exercise, we're just going to add one issue at the moment. Your client wants a beautifully styled heading for the homepage. It should be simple, bold, black writing with a background shadow that makes it stand out.

Raise a new issue with a descriptive title.
In the body of the issue, provide more detail about how to complete the work.
Assign yourselves to this issue.

Step 3 - Create and move to a new branch

There are many types of workflow. At FAC, we use the GitHub flow, where the master branch is always deployable. In this flow, each branch is used for a separate feature.

Create a branch with a unique and descriptive name. For example, create-heading-with-shadow.

$ git branch create-heading-with-shadow

2. Leave the master branch by switching to the new branch you have just created.

$ git checkout create-heading-with-shadow

Step 4 - Write enough HTML & CSS to satisfy the requirements

Add the following code into a file called index.html.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="style.css">
    <title>Git Workflow Workshop</title>
</head>

<body>

    <h1 class="some-heading">GIT WORKFLOW WORKSHOW</h1>

</body>

</html>

Create a new file called style.css which contains:

* {
  margin: 0;
  padding: 0;
}

.page-heading {
  box-sizing: border-box;
  font-family: "Avant Garde", Avantgarde, "Century Gothic", CenturyGothic, "AppleGothic", sans-serif;
  font-size: 3.5rem;
  padding: 5rem 3rem;
  text-align: center;
  text-rendering: optimizeLegibility;
  color: #131313;
  background-color: #e7e5e4;
  letter-spacing: .15em;
  text-shadow: 1px -1px 0 #767676, -1px 2px 1px #737272, -2px 4px 1px #767474, -3px 6px 1px #787777, -4px 8px 1px #7b7a7a, -5px 10px 1px #7f7d7d, -6px 12px 1px #828181, -7px 14px 1px #868585, -8px 16px 1px #8b8a89, -9px 18px 1px #8f8e8d, -10px 20px 1px #949392, -11px 22px 1px #999897, -12px 24px 1px #9e9c9c, -13px 26px 1px #a3a1a1, -14px 28px 1px #a8a6a6, -15px 30px 1px #adabab, -16px 32px 1px #b2b1b0, -17px 34px 1px #b7b6b5, -18px 36px 1px #bcbbba, -19px 38px 1px #c1bfbf, -20px 40px 1px #c6c4c4, -21px 42px 1px #cbc9c8, -22px 44px 1px #cfcdcd, -23px 46px 1px #d4d2d1, -24px 48px 1px #d8d6d5, -25px 50px 1px #dbdad9, -26px 52px 1px #dfdddc, -27px 54px 1px #e2e0df, -28px 56px 1px #e4e3e2;
}

Step 5 - Add the new files to the staging area

Add index.html and style.css to the staging area.

$ git add index.html style.css

Step 6 - Commit your changes

The history of a project is made up of "commits". Each commit is a snapshot of your whole repository at one particular time.

Commit the files that are in the staging area.

Before closing the commit message with a quote symbol you can press enter on your keyboard to continue typing in the new terminal line. The text in the second line can be used as an additional message.

It is a good practice to link your commit to an existing issue by typing Relates #1. Thanks to using the hash symbol followed by the relevant issue number your commit will be automatically linked to an existing issue.

$ git commit -m 'add git workshop heading & shadow styling
> Relates #1'

Step 7 - Push your local version up to GitHub

At this point, your remote repo looks exactly the same as at the beginning. You need to push your changes.

Push the create-heading-with-shadow branch up to the "origin" i.e. the GitHub repo that you cloned from.

$ git push origin create-heading-with-shadow

Step 8 - Create a pull request

Programmer 1 navigates to the repository on GitHub.com and creates a pull request.
- Add a descriptive title (e.g. Fix the spelling mistake in page heading) and leave a comment linking the pull request to the issue.
- Select Programmer 2 as an assignee.

Step 9 - Programmer 2 merges the pull request 👍

You should never merge your own pull requests. A PR gives the rest of your team the chance to review before your changes are merged into master. In your projects, you will be asking the other pair to do this.

Programmer 2 reviews the changes and merges the pull request on GitHub.com.

Now your remote repo looks like this:

Splitting the work

Your client has just called you and asked to improve heading on their company website.

There are two issues that when resolved will make the heading look really nice:

Spelling mistake in the heading (the word 'WORKSHOW' should be replaced with 'WORKSHOP')
The name of the css class in the heading needs to be updated so that existing styles in the style.css file can take effect (class="some-heading" should be replaced with class="page-heading").

Current heading:

When you apply the two changes above the heading will look like this:

You decide that one of you (Programmer 1) will resolve issue number 1 while the other person (Programmer 2) will resolve issue number 2. When you begin working on your weekly projects, you will always be pairing. So programmer 1 represents "pair 1" and programmer 2 represents "pair 2".

Note: Only one line in the index.html file needs to be modified.

Step 1 - Programmer 2 clones the repo

Make sure both teammates have a cloned, so you each have a local version on your own computer
```
$ git clone 'PASTE THE URL OF YOUR REPOSITORY HERE'
```

Step 2 - Raise these 2 new issues

Create the following two issues and assign each one to a different person
- Fix spelling typo in <h1> heading (Programmer 1)
- Correct the class name of <h1> heading to match the existing class name in the css file (Programmer 2)

Step 3 - Both programmers create one branch each and switch to them

Both programmers create one branch each: fix-typo-heading (Programmer 1) and update-class-heading (Programmer 2).

# Programmer 1:
$ git branch fix-typo-heading

# Programmer 2:
$ git branch update-class-heading

Both programmers leave the master branch by switching to the new branches.

# Programmer 1:
$ git checkout fix-typo-heading

# Programmer 2:
$ git checkout update-class-heading

Note: You can achieve both steps at once with git checkout -b <new-branch-name>.

Step 4 - Both programmers open their `index.html` files and make one requested change each

Programmer 1 fixes only the spelling typo in the heading (WORKSHOW -> WORKSHOP). Please do not update the class name. This is dealt with by Programmer 2.

<h1 class="some-heading">GIT WORKFLOW WORKSHOP</h1>

Programmer 2 updates only the class name of the heading (class="some-heading" -> class="page-heading"). Please do not fix the spelling mistake. This is dealt with by Programmer 1.

<h1 class="page-heading">GIT WORKFLOW WORKSHOW</h1>

Step 5 - Both programmers save their `index.html` files and check status

Both programmers save their index.html files.
Both programmers check the status of their files, to confirm that index.html has been modified.

$ git status

Step 6 - Both programmers add the modified `index.html` file to the staging area

Both programmers add their modified index.html files to the staging area.

$ git add index.html

Step 7 - Both programmers commit their changes

Both programmers commit the changes. Don't forget the multi-line commit message with the referenced issue.

# Programmer 1:
$ git commit -m 'Fix typo in page heading
> Relates #<issue number>'

# Programmer 2:
$ git commit -m 'Update class name in heading
> Relates #<issue number>'

Step 8 - Programmer 1 switches to `master` branch and pulls down the remote `master` branch

We have so many programmers working on this project now, who knows what changes may have happened to the master branch since the last time we looked at the remote version that's on GitHub?

Programmer 1 switches to master branch.

$ git checkout master

Programmer 1 pulls the master branch from the remote (GitHub repo) to make sure that the local version of master is up to date with the remote (GitHub) version of master. (There should be no changes since neither of you has pushed any changes to the remote yet.) It is a good practice to regularly check for changes on the remote before pushing your local changes.

$ git pull origin master

Programmer 1 switches back to the fix-typo-heading branch.

$ git checkout fix-typo-heading

Step 9 - Programmer 1 pushes `fix-typo-heading` branch to remote

Programmer 1 pushes fix-typo-heading branch to remote

$ git push origin fix-typo-heading

Step 10 - Programmer 1 creates a pull request

Programmer 1 navigates to the repository on GitHub.com and creates a pull request.
- Add a descriptive title (e.g. Fix the spelling mistake in page heading) and leave a comment linking the pull request to the issue.
- Select Programmer 2 as an assignee.

Step 11 - Programmer 2 reviews the pull request

Programmer 2 reviews the pull request

Step through each commit (in this case one)
Check the "Files changed" tab for a line-by-line breakdown.
Click "Review changes" and choose:
- "Comment"
- "Approve"
- "Request changes"

Step 12 - Programmer 2 merges the pull request 👍

Programmer 2 merges the pull request on GitHub.com.

Programmer 2 opens the live website on GitHub pages to double check that the spelling mistake has been corrected. Go to the repository settings on Github and scroll down until you find Github Pages title. Select the master branch as the source and save, and you'll then see the URL where the live website is.

Step 13 - Programmer 2 switches to `master` branch, pulls the remote `master` branch, tries to merge it into `update-class-heading` branch and 💥 resolves merge conflicts 💥

Programmer 2 switches to master branch.

$ git checkout master

Programmer 2 pulls the remote master branch to make sure that the latest version of the project is available locally.

$ git pull origin master

Programmer 2 switches back to the update-class-heading branch.

$ git checkout update-class-heading

Programmer 2 tries to merge master branch into update-class-heading branch.

$ git merge master

There should be a 💥 merge conflict 💥 since the line with the <h1> heading is different. Merge conflict should be highlighted with HEAD and master markers as follows:

<body>

<<<<<<< HEAD
    <h1 class="page-heading">GIT WORKFLOW WORKSHOW</h1>
=======
    <h1 class="some-heading">GIT WORKFLOW WORKSHOP</h1>
>>>>>>> master

</body>

Programmer 2 removes HEAD and master markers and leaves only one line with <h1> heading so that both issues are addressed.

<body>

    <h1 class="page-heading">GIT WORKFLOW WORKSHOP</h1>

</body>

Programmer 2 adds the index.html file to staging area and commits the changes occurred during the merge conflict.

# First add to staging area
$ git add index.html

# Then commit changes
$ git commit -m 'Fix merge conflict
> Relates #<issue number> and #<issue number>'

Step 14 - Programmer 2 pushes `update-class-heading` branch to remote

Programmer 2 pushes update-class-heading branch to remote.

  $ git push origin update-class-heading

Step 15 - Programmer 2 creates a pull request

Programmer 2 navigates to the repository on GitHub.com and creates a pull request selecting master as a base branch and update-class-heading as a head branch. Please add a descriptive title (e.g. Update class name in page heading) and leave a comment linking the pull request with the issue #<number>. Please also select Programmer 1 as an assignee.

Step 16 - Programmer 1 merges the pull request 👍

Programmer 1 reviews and merges the pull request on GitHub.com.

Programmer 1 opens the live website on GitHub pages to double check the new heading style.

That's it 😄 Thank you for checking out the 'Git Workflow Workshop for Two Programmers' 👏

A summary of the above commands and what they do can be found here in a neat little table.

Note: This workshop introduces you to the idea of forking a repository. This is very useful when wanting to contribute to existing open source projects 💯

However, forking is not required when starting a new repository under foundersandcoders or FAC-X organisations. All your fellow students will be automatically added as contributors.

kostasx / git-workflow-workshop-for-two Goto Github PK

git-workflow-workshop-for-two's Introduction

Git Workflow Workshop for Two Programmers 💻 💻

Workshop summary

Initial setup 🚀

Step 1 - Create a new GitHub repo and clone it

Step 2 - Raise your issues on the work to be done

Step 3 - Create and move to a new branch

Step 4 - Write enough HTML & CSS to satisfy the requirements

Step 5 - Add the new files to the staging area

Step 6 - Commit your changes

Step 7 - Push your local version up to GitHub

Step 8 - Create a pull request

Step 9 - Programmer 2 merges the pull request 👍

Splitting the work

Step 1 - Programmer 2 clones the repo

Step 2 - Raise these 2 new issues

Step 3 - Both programmers create one branch each and switch to them

Step 4 - Both programmers open their index.html files and make one requested change each

Step 5 - Both programmers save their index.html files and check status

Step 6 - Both programmers add the modified index.html file to the staging area

Step 7 - Both programmers commit their changes

Step 8 - Programmer 1 switches to master branch and pulls down the remote master branch

Step 9 - Programmer 1 pushes fix-typo-heading branch to remote

Step 10 - Programmer 1 creates a pull request

Step 11 - Programmer 2 reviews the pull request

Step 12 - Programmer 2 merges the pull request 👍

Step 13 - Programmer 2 switches to master branch, pulls the remote master branch, tries to merge it into update-class-heading branch and 💥 resolves merge conflicts 💥

Step 14 - Programmer 2 pushes update-class-heading branch to remote

Step 15 - Programmer 2 creates a pull request

Step 16 - Programmer 1 merges the pull request 👍

That's it 😄 Thank you for checking out the 'Git Workflow Workshop for Two Programmers' 👏

git-workflow-workshop-for-two's People

Contributors

Watchers

Recommend Projects

Recommend Topics

Recommend Org