1345 lines
61 KiB
Plaintext
1345 lines
61 KiB
Plaintext
{
|
||
"cells": [
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# The Typical Pull Request Workflow on GitHub\n",
|
||
"\n",
|
||
"This reading contains the code used in the instructional videos from [**The Typical Pull Request Workflow on GitHub**](https://www.coursera.org/learn/introduction-git-github/lecture/8mpDb/the-typical-pull-request-workflow-on-github)\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"This follow-along reading is organized to match the content in the video that follows. It contains the same code shown in the next video. These code blocks will provide you with the opportunity to see how the code is written and can be used as a reference as you work through the course. \n",
|
||
"\n",
|
||
"You can follow along in the reading as the instructor discusses the code or review the code after watching the video.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git clone https://github.com/redquinoa/rearrange.git\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"Cloning into 'rearrange'...\n",
|
||
"\n",
|
||
"remote: Enumerating objects: 9, done.\n",
|
||
"\n",
|
||
"remote: Counting objects: 100% (9/9), done.\n",
|
||
"\n",
|
||
"remote: Compressing objects: 100% (7/7), done.\n",
|
||
"\n",
|
||
"remote: Total 9 (delta 1), reused 9 (delta 1), pack-reused 0\n",
|
||
"\n",
|
||
"Unpacking objects: 100% (9/9), done.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"cd rearrange\n",
|
||
"\n",
|
||
"ls \\-l\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"total 20\n",
|
||
"\n",
|
||
"\\-rw-rw-r-- 1 user user 11357 Jan 7 09:42 LICENSE\n",
|
||
"\n",
|
||
"\\-rw-rw-r-- 1 user user 211 Jan 7 09:42 rearrange.py\n",
|
||
"\n",
|
||
"\\-rw-rw-r-- 1 user user 762 Jan 7 09:42 rearrange\\_test.py\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git log\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"commit 367a127672c40a163a6f05ad930f2b0b857dc961 (HEAD -> master, origin/master, origin/HEAD)\n",
|
||
"\n",
|
||
"Author: Blue Kale <bluekale@example.com>\n",
|
||
"\n",
|
||
"Date: Mon Jul 29 21:21:53 2019 +0200\n",
|
||
"\n",
|
||
" Add tests for the rearrange module\n",
|
||
"\n",
|
||
"commit c89805e52a1afa143c503f946cc5ead0fdd20255\n",
|
||
"\n",
|
||
"Author: Blue Kale <bluekale@example.com>\n",
|
||
"\n",
|
||
"Date: Mon Jul 29 21:20:57 2019 +0200\n",
|
||
"\n",
|
||
" Add the rearrange module\n",
|
||
"\n",
|
||
"commit f4ddbc7a0ca3ac83a7e9ce7030e774b58e5dda42\n",
|
||
"\n",
|
||
"Author: Blue Kale <53440916+blue-kale@users.noreply.github.com>\n",
|
||
"\n",
|
||
"Date: Mon Jul 29 16:07:42 2019 -0300\n",
|
||
"\n",
|
||
" Initial commit\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git checkout \\-b add\\-readme\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"Switched to a new branch 'add-readme'\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git atom README.md \n",
|
||
"\n",
|
||
"Rearrange\n",
|
||
"\n",
|
||
"\\=========\n",
|
||
"\n",
|
||
"This module is used for rearranging names. \n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git add README.md\n",
|
||
"\n",
|
||
"git commit \\-m 'Add a simple README.md file'\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"\\[master 736d754\\] Add a simple README.md file\n",
|
||
"\n",
|
||
" 1 file changed, 4 insertions(+)\n",
|
||
"\n",
|
||
" create mode 100644 README.md\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push \\-u origin add\\-readme\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"Username for 'https://github.com': redquinoa\n",
|
||
"\n",
|
||
"Password for 'https://redquinoa@github.com': \n",
|
||
"\n",
|
||
"Enumerating objects: 4, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (4/4), done.\n",
|
||
"\n",
|
||
"Delta compression using up to 4 threads\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (3/3), 400 bytes | 400.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 3 (delta 0), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"remote: \n",
|
||
"\n",
|
||
"remote: Create a pull request for 'add-readme' on GitHub by visiting:\n",
|
||
"\n",
|
||
"remote: https://github.com/redquinoa/rearrange/pull/new/add-readme\n",
|
||
"\n",
|
||
"remote: \n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/rearrange.git\n",
|
||
"\n",
|
||
" \\* \\[new branch\\] add-readme -> add-readme\n",
|
||
"\n",
|
||
"Branch 'add-readme' set up to track remote branch 'add-readme' from 'origin'."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Updating an Existing Pull Request\n",
|
||
"\n",
|
||
"This reading contains the code used in the instructional videos from [**Updating an Existing Pull Request**](https://www.coursera.org/learn/introduction-git-github/lecture/aRZ95/updating-an-existing-pull-request)\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"This follow-along reading is organized to match the content in the video that follows. It contains the same code shown in the next video. These code blocks will provide you with the opportunity to see how the code is written and can be used as a reference as you work through the course. \n",
|
||
"\n",
|
||
"You can follow along in the reading as the instructor discusses the code or review the code after watching the video.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"atom README.md\n",
|
||
"\n",
|
||
"Rearrange\n",
|
||
"\n",
|
||
"\\=========\n",
|
||
"\n",
|
||
"This module is used for rearranging names. \n",
|
||
"\n",
|
||
"Turns \"LastName,FirstName\" into \"Firstname LastName\"\n",
|
||
"\n",
|
||
"# Example\n",
|
||
"\n",
|
||
"Calling \\`rearrange\\_name(\"Turing, Alan\")\\` will return \\`\"Alan Turing\"\\`\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git commit \\-a \\-m 'Add more information to the README'\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"\\[add-readme 01231b0\\] Add more information to the README\n",
|
||
"\n",
|
||
" 1 file changed, 5 insertions(+)\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"Username for 'https://github.com': redquinoa\n",
|
||
"\n",
|
||
"Password for 'https://redquinoa@github.com': redquinoa\n",
|
||
"\n",
|
||
"Enumerating objects: 5, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (5/5), done.\n",
|
||
"\n",
|
||
"Delta compression using up to 4 threads\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (3/3), 407 bytes | 407.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 3 (delta 1), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"remote: Resolving deltas: 100% (1/1), completed with 1 local object.\n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/rearrange.git\n",
|
||
"\n",
|
||
" 736d754..01231b0 add-readme -> add-readme"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Squashing Changes\n",
|
||
"\n",
|
||
"This reading contains the code used in the instructional videos from [**Squashing Changes**](https://www.coursera.org/learn/introduction-git-github/lecture/6ODVl/squashing-changes)\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"This follow-along reading is organized to match the content in the video that follows. It contains the same code shown in the next video. These code blocks will provide you with the opportunity to see how the code is written and can be used as a reference as you work through the course. \n",
|
||
"\n",
|
||
"You can follow along in the reading as the instructor discusses the code or review the code after watching the video.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git rebase \\-i master\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"pick 736d754 Add a simple README file\n",
|
||
"\n",
|
||
"pick 01231b0 Add more information to the README\n",
|
||
"\n",
|
||
"(...)\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"pick 736d754 Add a simple README file\n",
|
||
"\n",
|
||
"squash 01231b0 Add more information to the README\n",
|
||
"\n",
|
||
"(...)\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"# This is a combination of 2 commits. \n",
|
||
"\n",
|
||
"# This is the 1st commit message:\n",
|
||
"\n",
|
||
"Add a simple README file\n",
|
||
"\n",
|
||
"# This is the commit message #2:\n",
|
||
"\n",
|
||
"Add more information to the README\n",
|
||
"\n",
|
||
"(...)\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"# This is a combination of 2 commits. \n",
|
||
"\n",
|
||
"# This is the 1st commit message:\n",
|
||
"\n",
|
||
"Add a simple README file including an example use case\n",
|
||
"\n",
|
||
"# This is the commit message #2:\n",
|
||
"\n",
|
||
"Add more information to the README\n",
|
||
"\n",
|
||
"(...)\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"git rebase -i master\n",
|
||
"\n",
|
||
"\\[detached HEAD ae779e4\\] Add a simple README.md file including an example use case\n",
|
||
"\n",
|
||
" Date: Tue Jan 7 09:47:17 2020 -0800\n",
|
||
"\n",
|
||
" 1 file changed, 9 insertions(+)\n",
|
||
"\n",
|
||
" create mode 100644 README.md\n",
|
||
"\n",
|
||
"Successfully rebased and updated refs/heads/add-readme.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git show\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"commit ae779e430288b082a19062ed087c547e1051a981 (HEAD -> add-readme)\n",
|
||
"\n",
|
||
"Author: My name <me@example.com>\n",
|
||
"\n",
|
||
"Date: Tue Jan 7 09:47:17 2020 -0800\n",
|
||
"\n",
|
||
" Add a simple README file including an example use case\n",
|
||
"\n",
|
||
"diff --git a/README.md b/README.md\n",
|
||
"\n",
|
||
"new file mode 100644\n",
|
||
"\n",
|
||
"index 0000000..5761a46\n",
|
||
"\n",
|
||
"\\--- /dev/null\n",
|
||
"\n",
|
||
"+++ b/README.md\n",
|
||
"\n",
|
||
"@@ -0,0 +1,9 @@\n",
|
||
"\n",
|
||
"+Rearrange\n",
|
||
"\n",
|
||
"+=========\n",
|
||
"\n",
|
||
"+\n",
|
||
"\n",
|
||
"+This module is used for rearranging names.\n",
|
||
"\n",
|
||
"+Turns \"LastName, FirstName\" into \"FirstName LastName\"\n",
|
||
"\n",
|
||
"+\n",
|
||
"\n",
|
||
"+# Example\n",
|
||
"\n",
|
||
"+\n",
|
||
"\n",
|
||
"+Calling \\`rearrange\\_name(\"Turing, Alan\")\\` will return \\`\"Alan Turing\"\\`\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git status\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"On branch add-readme\n",
|
||
"\n",
|
||
"Your branch and 'origin/add-readme' have diverged,\n",
|
||
"\n",
|
||
"and have 1 and 2 different commits each, respectively.\n",
|
||
"\n",
|
||
" (use \"git pull\" to merge the remote branch into yours)\n",
|
||
"\n",
|
||
"nothing to commit, working tree clean\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git log \\--graph \\--oneline \\--all \\-4\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"\\* ae779e4 (HEAD -> add-readme) Add a simple README.md file including an example use case\n",
|
||
"\n",
|
||
"| \\* 01231b0 (origin/add-readme) Add more information to the README\n",
|
||
"\n",
|
||
"| \\* 736d754 Add a simple README.md file\n",
|
||
"\n",
|
||
"|/ \n",
|
||
"\n",
|
||
"\\* 367a127 (origin/master, origin/HEAD, master) Add tests for the rearrange module\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"Username for 'https://github.com': redquinoa\n",
|
||
"\n",
|
||
"Password for 'https://redquinoa@github.com': redquinoa\n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/rearrange.git\n",
|
||
"\n",
|
||
" ! \\[rejected\\] add-readme -> add-readme (non-fast-forward)\n",
|
||
"\n",
|
||
"error: failed to push some refs to 'https://github.com/redquinoa/rearrange.git'\n",
|
||
"\n",
|
||
"hint: Updates were rejected because the tip of your current branch is behind\n",
|
||
"\n",
|
||
"hint: its remote counterpart. Integrate the remote changes (e.g.\n",
|
||
"\n",
|
||
"hint: 'git pull ...') before pushing again.\n",
|
||
"\n",
|
||
"hint: See the 'Note about fast-forwards' in 'git push --help' for details.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push \\-f\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"Enumerating objects: 4, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (4/4), done.\n",
|
||
"\n",
|
||
"Delta compression using up to 4 threads\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (3/3), 510 bytes | 510.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 3 (delta 0), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/rearrange.git\n",
|
||
"\n",
|
||
" + 01231b0...ae779e4 add-readme -> add-readme (forced update)\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git log \\--graph \\--oneline \\--all \\-4\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"\\* ae779e4 (HEAD -> add-readme, origin/add-readme) Add a simple README.md file including an example use case\n",
|
||
"\n",
|
||
"\\* 367a127 (origin/master, origin/HEAD, master) Add tests for the rearrange module\n",
|
||
"\n",
|
||
"\\* c89805e Add the rearrange module\n",
|
||
"\n",
|
||
"\\* f4ddbc7 Initial commit"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Study guide: Git forks and pull requests\n",
|
||
"\n",
|
||
"GitHub is an open-source platform for collaboration and knowledge sharing, allowing users to explore code created by others. This study guide will provide you with pointers on effectively using the platform to make pull requests in the Git environment.\n",
|
||
"\n",
|
||
"## Pull requests\n",
|
||
"\n",
|
||
"Pull requests allow you to inform fellow contributors about changes that have been made to a branch in Git. When pulling requests, you can discuss and evaluate proposed changes before implementing changes to the primary branch.\n",
|
||
"\n",
|
||
"You can eventually merge changes back into the main repository (or repo) by creating a pull request. However, it is important to note that before any changes are made to the original code, GitHub creates a fork (or a copy of the project), which allows changes to be committed to the fork copy even if changes cannot be pushed to the other repo. Anyone can suggest changes through the inline comment in pull requests, but the owner only has rights to review and approve changes before merging them. To create a pull request:\n",
|
||
"\n",
|
||
"- Make changes to the file.\n",
|
||
"- Change the proposal and complete a description of the change.\n",
|
||
"- Click the Proposed File Change button to create a commit in the forked repo to send the change to the owner.\n",
|
||
"- Enter comments about the change. If more context is needed about the change, use the text box.\n",
|
||
"- Click Pull Request.\n",
|
||
"\n",
|
||
"When creating multiple commits, a number next to the pull request serves as the identifier for accessing the pull requests in the future. This is important because it allows project maintainers to follow up with questions or comments. \n",
|
||
"\n",
|
||
"For more information on creating pull requests, click the following link: [Creating a pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)\n",
|
||
"\n",
|
||
"## Pull request merges\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"You can merge pull requests by retaining the commits. Below is a list of pull request merge options that you can use when merging pull requests.\n",
|
||
"\n",
|
||
"**Merge commits.** All commits from the feature branch are added to the base branch in a merge commit using the -- no–ff option. \n",
|
||
"\n",
|
||
"**Squash and merge commits.** Multiple commits of a pull request are squashed, or combined into a single commit, using the fast-forward option. It is recommended that when merging two branches, pull requests are squashed and merged to prevent the likelihood of conflicts due to redundancy.\n",
|
||
"\n",
|
||
"**Merge message for a squash merge.** GitHub generates a default commit message, which you can edit. This message may include the pull request title, pull request description, or information about the commits.\n",
|
||
"\n",
|
||
"**Rebase and merge commits.** All commits from the topic branch are added onto the base branch individually without a merge commit. \n",
|
||
"\n",
|
||
"**Indirect merges.** GitHub can merge a pull request automatically if the head branch is directly or indirectly merged into the base branch externally.\n",
|
||
"\n",
|
||
"## Key takeaways\n",
|
||
"\n",
|
||
"Pull requests are a crucial tool you can use for efficiently capturing, implementing, and receiving approvals for changes. These capabilities are made possible through collaboration. Practicing pull requests can help you hone your skills and contribute to a project."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# How to Use Code Reviews in GitHub\n",
|
||
"\n",
|
||
"This reading contains the code used in the instructional videos from [**How to use Code Reviews in GitHub**](https://www.coursera.org/learn/introduction-git-github/lecture/QH52K/how-to-use-code-reviews-in-github)\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"This follow-along reading is organized to match the content in the video that follows. It contains the same code shown in the next video. These code blocks will provide you with the opportunity to see how the code is written and can be used as a reference as you work through the course. \n",
|
||
"\n",
|
||
"You can follow along in the reading as the instructor discusses the code or review the code after watching the video.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"atom README.md\n",
|
||
"\n",
|
||
"Rearrange\n",
|
||
"\n",
|
||
"\\=========\n",
|
||
"\n",
|
||
"This module is used for rearranging names.\n",
|
||
"\n",
|
||
"Turns \"LastName, FirstName\" into \"FirstName LastName\".\n",
|
||
"\n",
|
||
"## Examples\n",
|
||
"\n",
|
||
" \\* Calling \\`rearrange\\_name(\"Turing, Alan\")\\` will return \\`\"Alan Turing\"\\`\n",
|
||
"\n",
|
||
" \\* Calling \\`rearrange\\_name(\"Hopper, Grace M.\")\\` will return \\`\"Grace M. Hopper\"\\`\n",
|
||
"\n",
|
||
" \\* Calling \\`rearrange\\_name(\"Voltaire\")\\` will return \\`\"Voltaire\"\\`\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git commit \\-a \\--amend\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"\\[add-readme 55e32ed\\] Add a simple README.md file including an example use case\n",
|
||
"\n",
|
||
" Date: Tue Jan 7 09:47:17 2020 -0800\n",
|
||
"\n",
|
||
" 1 file changed, 11 insertions(+)\n",
|
||
"\n",
|
||
" Create mode 100644 README.md\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git status\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"On branch add-readme\n",
|
||
"\n",
|
||
"Your branch and ‘origin/add-readme’ have diverged,\n",
|
||
"\n",
|
||
"And have 1 and 1 different commits, respectively\n",
|
||
"\n",
|
||
" (use “git pull” to merge the remote branch into yours)\n",
|
||
"\n",
|
||
"Nothing to commit, working tree clean\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push \\-f\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"Username for 'https://github.com': redquinoa\n",
|
||
"\n",
|
||
"Password for 'https://redquinoa@github.com': redquinoa\n",
|
||
"\n",
|
||
"numerating objects: 4, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (4/4), done.\n",
|
||
"\n",
|
||
"Delta compression using up to 4 threads\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (3/3), 553 bytes | 553.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 3 (delta 0), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/rearrange.git\n",
|
||
"\n",
|
||
" + ae779e4...55e32ed master -> master (forced update)"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# More Information on Code Reviews\n",
|
||
"\n",
|
||
"Consistent coding standards are essential for large-scale projects, ensuring readability and maintainability. Google's style guides stand as prominent examples of how such norms can be established and adhered to across diverse teams. Code reviews are also essential in order to produce quality code. This reading delves into the principles of code review strategies and the significance of style guides, shedding light on their impact on software development practices and outcomes. You'll explore Google's style guides, learn about diverse code review strategies, and gain insights into the significance of pull request reviews. \n",
|
||
"\n",
|
||
"## Google style guides\n",
|
||
"\n",
|
||
"Every major open-source project includes a style guide, which is a set of norms for writing code for that project. When all of the code in a huge codebase is written in the same manner, it is considerably simpler to understand. \n",
|
||
"\n",
|
||
"You can find the project and style guide for Google code [here.](https://github.com/google/styleguide)\n",
|
||
"\n",
|
||
"## Code review\n",
|
||
"\n",
|
||
"Code review, also referred to as peer code review, is the deliberate and methodical gathering of other programmers to examine each other's code for errors. Code review can speed up and simplify the software development process, unlike other techniques. Peer reviews also save time and money, especially by catching the kinds of defects that could sneak through testing, production, and into the laptops of end users.\n",
|
||
"\n",
|
||
"## Common code review strategies\n",
|
||
"\n",
|
||
"### Pair programming\n",
|
||
"\n",
|
||
"This method of building software places engineers side-by-side, working on the same code together. Pair programming is one of the defining characteristics of Extreme Programming (XP). It seems to integrate code review directly into the programming process and is a fantastic technique for senior engineers to mentor junior team members. However, different approaches to code review might offer greater objectivity because writers and even co-authors often become too familiar with their own work. Compared to other approaches, pair programming can require more staff and time resources.\n",
|
||
"\n",
|
||
"### The email thread\n",
|
||
"\n",
|
||
"With the email thread strategy, a file is sent to the appropriate coworkers through email as soon as a particular piece of code is prepared for review, so they can individually review it. Although this method can be more adaptable and flexible than more conventional approaches, an email thread of suggestions and divergent opinions can become confusing very quickly, leaving the original coder to sort through it all.\n",
|
||
"\n",
|
||
"### Over the shoulder\n",
|
||
"\n",
|
||
"One of the oldest, simplest, and most natural ways to participate in peer code review is the over-the-shoulder technique, which is more comfortable for most engineers than XP's pair programming. When your code is complete, ask a coworker to evaluate it while you explain why you created it that way. \n",
|
||
"\n",
|
||
"### Tool assisted\n",
|
||
"\n",
|
||
"Software-based code review tools, some of which are browser-based or seamlessly integrate into a range of common IDE and SCM development frameworks, are the final form of code review. Software tools enable reviews to happen asynchronously and non-locally, issuing notifications to the original coder when new reviews come in. The tools keep the review process moving efficiently with no meetings and no one having to leave their desks to contribute. Some technologies can also produce vital usage statistics that provide the audit trials and review metrics required for process improvement and compliance reporting.\n",
|
||
"\n",
|
||
"## Pull request reviews\n",
|
||
"\n",
|
||
"A pull request (PR) is a procedure where new code is examined before it is merged to create a branch or master branch in GitHub. Before a pull request is merged, reviews give contributors the opportunity to comment on the modifications suggested in the request, accept the changes, or ask for additional changes. Administrators of the repository can mandate that each pull request be accepted before it is merged.\n",
|
||
"\n",
|
||
"Anyone with read access can review and comment on the changes proposed in a pull request once it has been opened. Additionally, you can make precise changes to code lines that the author can implement right from the pull request. If you are interested in learning more about reviewing proposed changes in a pull request, click [here.](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/reviewing-proposed-changes-in-a-pull-request)\n",
|
||
"\n",
|
||
"### Five tips for pull request reviews \n",
|
||
"\n",
|
||
"Some of the considerations you should have with pull request reviews are:\n",
|
||
"\n",
|
||
"1. **Be selective with reviewers:** It's important to select a reasonable number of reviewers for a pull request. Adding too many reviewers can lead to inefficient use of resources, as too many people reviewing the same code may not be productive.\n",
|
||
"2. **Timely reviews:** Ideally, reviews should be completed within two hours of the pull request being submitted. Delays in reviews can lead to context switching and hinder overall productivity.\n",
|
||
"3. **Constructive feedback:** Feedback should be constructive and explain what needs to be changed and, more importantly, why those changes are suggested. Friendly and non-accusatory language fosters a positive and collaborative atmosphere.\n",
|
||
"4. **Detailed pull request description:** The pull request should include a detailed description that covers the changes made in the feature branch compared to the development branch, prerequisites, usage instructions, design changes with comparisons to mockups, and any additional notes that reviewers should be aware of. This information ensures that reviewers have a comprehensive understanding of the changes.\n",
|
||
"5. **Interactive rebasings:** Interactive Rebasings allow developers to modify individual commits without cluttering the commit history with redundant or unrelated changes. Keeping commits clean and relevant contributes to a more organized and maintainable codebase.\n",
|
||
"\n",
|
||
"## Key takeaways:\n",
|
||
"\n",
|
||
"- **Importance of consistent coding standards:** Maintaining uniform coding standards ensures readability and ease of maintenance. Google's style guides serve as prime examples of establishing and adhering to such norms across diverse teams.\n",
|
||
"- **Role of code reviews:** Code reviews, or peer code reviews, involve organized examination by fellow programmers, speeding up development and catching defects that might bypass testing, saving time and resources.\n",
|
||
"- **Diverse code review strategies:** Pair programming, email threads, over-the-shoulder evaluations, and tool-assisted review strategies offer different levels of collaboration and objectivity, catering to different project needs.\n",
|
||
"- **Pull request reviews:** Pull request reviews provide an opportunity for collaborative examination of new code before integration. Accessible to those with read access, PR reviews enable inclusive feedback and ensure code quality through timely and constructive comments."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Tracking Issues\n",
|
||
"\n",
|
||
"This reading contains the code used in the instructional videos from [**Tracking Issues**](https://www.coursera.org/learn/introduction-git-github/lecture/s59zR/tracking-issues)\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"This follow-along reading is organized to match the content in the video that follows. It contains the same code shown in the next video. These code blocks will provide you with the opportunity to see how the code is written and can be used as a reference as you work through the course. \n",
|
||
"\n",
|
||
"You can follow along in the reading as the instructor discusses the code or review the code after watching the video.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"cd health\\-checks/\n",
|
||
"\n",
|
||
"atom README.md\n",
|
||
"\n",
|
||
"# health-checks\n",
|
||
"\n",
|
||
"This repo will be populated with lots of fancy checks. \n",
|
||
"\n",
|
||
"Currently the main script is health\\_checks.py\n",
|
||
"\n",
|
||
"This script will print \"Everything ok\" if all checks pass, \n",
|
||
"\n",
|
||
"or the corresponding error messages if some checks fail.\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git commit \\-a\n",
|
||
"\n",
|
||
"Update README to use the new name of the script\n",
|
||
"\n",
|
||
"Also add more information about how this works. \n",
|
||
"\n",
|
||
"Closes #1\n",
|
||
"\n",
|
||
"(...)\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:** \n",
|
||
"\n",
|
||
"\\[master 8981efe\\] Update README to use the new name of the script\n",
|
||
"\n",
|
||
" 1 file changed, 4 insertions(+), 1 deletion(-)\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Code output:**\n",
|
||
"\n",
|
||
"Username for 'https://github.com': redquinoa\n",
|
||
"\n",
|
||
"Password for 'https://redquinoa@github.com': \n",
|
||
"\n",
|
||
"Enumerating objects: 5, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (5/5), done.\n",
|
||
"\n",
|
||
"Delta compression using up to 2 threads\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (3/3), 564 bytes | 564.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 3 (delta 0), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"To https://github.com/redquinoa/health-checks.git\n",
|
||
"\n",
|
||
" 160b5f3..8981efe master -> master"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Integrating git and GitHub\n",
|
||
"\n",
|
||
"Git is a disconnected client/server application. This means that repositories are kept on a server and copied to your local machine. Some Git operations, like git push or git pull, will synchronize your copy with the remote repository.\n",
|
||
"\n",
|
||
"While some organizations run their own private Git servers, most rely on a hosted solution. By far, the most popular is GitHub, but GitLab and Bitbucket are also in use. The Git command line can work with any of these.\n",
|
||
"\n",
|
||
"## Integrating Git and GitHub\n",
|
||
"\n",
|
||
"You can use either HTTPS or SSH with the command-line Git client to interact with GitHub. If you are pushing a commit, or working with a private repository, you will need to authenticate. Authentication methods differ depending on whether you’re using HTTPS or SSH.\n",
|
||
"\n",
|
||
"We’ll demonstrate several ways of using Git with your GitHub account.\n",
|
||
"\n",
|
||
"## HTTPS authentication\n",
|
||
"\n",
|
||
"### Command-line with HTTPS\n",
|
||
"\n",
|
||
"Install the Git CLI according to your operating system. When you push to a GitHub repository over HTTPS, or clone a private repository, Git will prompt you for your GitHub username and password.\n",
|
||
"\n",
|
||
"If you don’t want to enter your username and password every time, you can store them in a file called .netrc in your home directory, like this:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"machine GitHub.com\n",
|
||
"\n",
|
||
" login my-username\n",
|
||
"\n",
|
||
" password my-password\n",
|
||
"\n",
|
||
"machine api.GitHub.com\n",
|
||
"\n",
|
||
" login my-username\n",
|
||
"\n",
|
||
" password my-password\n",
|
||
"```\n",
|
||
"\n",
|
||
"Make sure the file is not readable by anyone else, or Git may ignore it.\n",
|
||
"\n",
|
||
"### Command-line HTTPS with token\n",
|
||
"\n",
|
||
"Instead of storing your password in plaintext in the .netrc file, you can generate a personal access token and use that in place of your password. See [Managing your personal access tokens](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n",
|
||
"\n",
|
||
"### Git Credential Manager\n",
|
||
"\n",
|
||
"Git Credential Manager (GCM) is a tool that securely stores your passwords and supplies them to Git without your intervention. It works on Linux, macOS, and Windows, and it supports multi-factor authentication too. You can read more about it [here](https://github.com/git-ecosystem/git-credential-manager).\n",
|
||
"\n",
|
||
"## SSH authentication\n",
|
||
"\n",
|
||
"In the previous module, you learned how to generate an SSH key pair and use it for logging in to remote hosts. You can use the same SSH key to authenticate with GitHub. \n",
|
||
"\n",
|
||
"To add your SSH key for use with GitHub:\n",
|
||
"\n",
|
||
"1. Find the public key you generated in the previous module. It will have a filename like id\\_rsa.pub.\n",
|
||
"2. Open [GitHub.com](https://github.com/) in your browser.\n",
|
||
"3. Click on your profile icon in the top right corner and select **Settings**.\n",
|
||
"4. Go to **SSH and GPG keys**.\n",
|
||
"5. Click **New SSH key**.\n",
|
||
"6. Paste the contents of your public key into the text box and click **Add SSH key**.\n",
|
||
"\n",
|
||
"## Key takeaways\n",
|
||
"\n",
|
||
"Integrating Git and GitHub is necessary for storing, sharing, and publishing your code. Git is responsible for everything GitHub-related that happens locally on your computer. GitHub is a cloud-based service that can store, share, and publish your code. Git and GitHub need to be able to communicate with each other."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# GitHub Project Management Tools\n",
|
||
"\n",
|
||
"Besides serving as a repository for your code and tracking changes to your code over time, GitHub also includes tools to help manage your software project.\n",
|
||
"\n",
|
||
"## GitHub Projects\n",
|
||
"\n",
|
||
"GitHub offers multiple tools to manage and plan your work. For example, GitHub Projects is a flexible tool for tracking and managing work on GitHub. You can use Projects to create an adaptable spreadsheet, task-board, and road map which integrates with your issues and pull requests. With GitHub projects, you can filter, sort, and group your issues and pull requests and customize to fit your team’s workflow. Projects can be created in a repository, and then issues can be added to them.\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"## GitHub Issues\n",
|
||
"\n",
|
||
"GitHub Issues is a part of GitHub Projects, and it provides a way to track tasks that you need to complete. An issue can be a bug, a feature request, or a housekeeping task (like upgrading a library to the latest version). Issues can have extensive text and descriptions attached to them, including screenshots and snippets of code. Issues can be discussed, commented on, assigned to people, and tagged.\n",
|
||
"\n",
|
||
"Here’s a screenshot of the top open issues for a very active Python application on GitHub:\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"As issues are worked, and pull requests linked to those issues are completed, Issues will automatically move into the next column, and then the next, until they’re closed. You can also drag issues to another column, and GitHub will update the status (and possibly assignee and other fields) to match.\n",
|
||
"\n",
|
||
"## Traditional project management\n",
|
||
"\n",
|
||
"You can also view open issues in a more traditional project management format, with status, assignees, estimates, and more:\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"GitHub also supports extensive automation. You can define workflows that update issues or projects automatically as issues change or comments are added. \n",
|
||
"\n",
|
||
"## Resources for more information\n",
|
||
"\n",
|
||
"- [A Quick Guide to Using GitHub for Project Management](https://www.jobsity.com/blog/a-quick-guide-to-using-github-for-project-management)\n",
|
||
"\n",
|
||
"- This article provides a brief overview of project management tools on GitHub.\n",
|
||
"- [GitHub for project management](https://openscapes.github.io/series/core-lessons/github/github-issues.html)\n",
|
||
"\n",
|
||
"- This lesson offers detailed descriptions of GitHub’s project management tools.\n",
|
||
"- [Using GitHub as your Project Management Tool](https://www.youtube.com/watch?v=qgQAFP6oSKw) \n",
|
||
"\n",
|
||
"- This video provides examples on GitHub project management tools.\n",
|
||
"- [GitHub Issues: Project Planning for Developers](https://github.com/features/issues) \n",
|
||
"\n",
|
||
"- This GitHub page shows the many project management tools available for developers."
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Additional Tools\n",
|
||
"\n",
|
||
"Check out the following links for more information:\n",
|
||
"\n",
|
||
"- [Open source DIY ethics](https://arp242.net/diy.html)\n",
|
||
"- [Linking a pull request to an issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)\n",
|
||
"- [Setting guidelines for repository contributors](https://help.github.com/en/articles/setting-guidelines-for-repository-contributors)\n",
|
||
"- [What is CI/CD? Continuous integration and continuous delivery explained ](https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and-continuous-delivery-explained.html)\n",
|
||
"- [What Is CICD? What’s Important and How to Get It Right](https://stackify.com/what-is-cicd-whats-important-and-how-to-get-it-right/)\n",
|
||
"- [Travis CI Tutorial](https://docs.travis-ci.com/user/tutorial/)\n",
|
||
"- [Build Stages](https://docs.travis-ci.com/user/build-stages/)"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Glossary terms from module 4\n",
|
||
"\n",
|
||
"## **Terms and definitions from Module 4**\n",
|
||
"\n",
|
||
"**CI/CD:** The name for the entire continuous integration and continuous deployment system\n",
|
||
"\n",
|
||
"**Code reviews:** The deliberate and methodical gathering of other programmers to examine each other's code for errors to increase the code quality and reduces the amount of bugs\n",
|
||
"\n",
|
||
"**Continuous deployment (CD):** New code is deployed often after it has been automatically built and tested\n",
|
||
"\n",
|
||
"**Continuous integration (CI):** A system that will automatically build and test our code every time there's a change\n",
|
||
"\n",
|
||
"**Fix up:** The decision to discard commit messages for that commit \n",
|
||
"\n",
|
||
"**Forking:** A way of creating a copy of the given repository so that it belongs to our user\n",
|
||
"\n",
|
||
"**Indirect merges:** GitHub can merge a pull request automatically if the head branch is directly or indirectly merged into the base branch externally\n",
|
||
"\n",
|
||
"**Issue tracker (bug tracker):** A tracker that shows tasks that need to be done, the state they're in and who's working on them\n",
|
||
"\n",
|
||
"**Merge commits:** All commits from the feature branch are added to the base branch\n",
|
||
"\n",
|
||
"**Pipelines:** The specific steps that need to run to obtain the desired result\n",
|
||
"\n",
|
||
"**Pull request:** A procedure where new code is examined before it is merged to create a branch or master branch \n",
|
||
"\n",
|
||
"**Squash commits:** The decision add commit messages together and an editor opens to make any necessary changes"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Exemplar: Push local commits to GitHub\n",
|
||
"\n",
|
||
"## Introduction\n",
|
||
"\n",
|
||
"For the previous lab, you needed to fork an existing repository, fix a bug in a script, push your commit to GitHub, and create a pull request with your commit.\n",
|
||
"\n",
|
||
"This exemplar is a walkthrough of the previous Qwiklab activity, including detailed instructions and solutions. You may use this exemplar if you were unable to complete the lab and/or you need extra guidance in competing lab tasks. You may also refer to this exemplar to prepare for the graded quiz in this module.\n",
|
||
"\n",
|
||
"## Forking and detect function behavior\n",
|
||
"\n",
|
||
"For this exercise, you need to fork an existing repository: google/it-cert-automation-practice.\n",
|
||
"\n",
|
||
"- Open [Github](https://github.com/join). If you don't already have a Github account, create one by entering a username, email, and password. If you already have a Github account proceed to the next step.\n",
|
||
"- Log in to your account from the [Github](https://github.com/) login page.\n",
|
||
"\n",
|
||
"A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.\n",
|
||
"\n",
|
||
"Forking a repository is a simple two-step process. We've created a repository for you to practice with!\n",
|
||
"\n",
|
||
"- On GitHub, navigate to the [google/it-cert-automation-practice](https://github.com/google/it-cert-automation-practice) repository.\n",
|
||
"- In the **top-right corner** of the page, click **Fork**.\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"This will open the **Create a new fork** window. Next, click on **Create fork**. It should look like this:\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"That's it! Now, you have a fork of the original google/it-cert-automation-practice repository.\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"First, **clone the repository** using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git clone https://github.com/\\[git\\-username\\]/it\\-cert-automation-practice.git\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"Cloning into 'it-cert-automation-practice'...\n",
|
||
"\n",
|
||
"remote: Enumerating objects: 55, done.\n",
|
||
"\n",
|
||
"remote: Total 55 (delta 0), reused 0 (delta 0), pack\\-reused 55\n",
|
||
"\n",
|
||
"Unpacking objects: 100% (55/55), done.\n",
|
||
"```\n",
|
||
"\n",
|
||
"Go to the it-cert-automation-practice directory using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"cd ~/it\\-cert-automation-practice\n",
|
||
"```\n",
|
||
"\n",
|
||
"First, verify that you have already setup a remote for the **upstream** repository, and an **origin**.Type the following command and press **Enter**. You'll see the current configured remote repository for your fork.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git remote \\-v\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"origin https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (fetch)\n",
|
||
"\n",
|
||
"origin https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (push)\n",
|
||
"```\n",
|
||
"\n",
|
||
"In terms of source control, you're **downstream** when you copy (clone, checkout, etc) from a repository. Information is flowed **downstream** to you.\n",
|
||
"\n",
|
||
"When you make changes, you usually want to send them back **upstream** so they make it into that repository so that everyone pulling from the same source is working with all the same changes. This is mostly a social issue of how everyone can coordinate their work rather than a technical requirement of source control. You want to get your changes into the **main** project so you're not tracking divergent lines of development.\n",
|
||
"\n",
|
||
"Setting the **upstream** for a fork you have created using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git remote add upstream https://github.com/\\[git\\-username\\]/it\\-cert-automation-practice.git\n",
|
||
"```\n",
|
||
"\n",
|
||
"To verify the new **upstream** repository you've specified for your fork, type git remote -v again. You should see the **URL** for your fork as **origin**, and the **URL** for the original repository as **upstream**.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git remote \\-v\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"origin https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (fetch)\n",
|
||
"\n",
|
||
"origin https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (push)\n",
|
||
"\n",
|
||
"upstream https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (fetch)\n",
|
||
"\n",
|
||
"upstream https://github.com/XXXXXXXX/it\\-cert-automation-practice.git (push)\n",
|
||
"```\n",
|
||
"\n",
|
||
"## Configure Git\n",
|
||
"\n",
|
||
"Git uses a **username** to associate commits with an identity. It does this by using the **git config** command. Set the Git **username** with the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git config \\--global user.name \"Name\"\n",
|
||
"```\n",
|
||
"\n",
|
||
"Replace **Name** with your name. Any future commits you push to GitHub from the command line will now be represented by this name. You can even use **git config** to change the name associated with your Git commits. This will only affect future commits and won't change the name used for past commits.\n",
|
||
"\n",
|
||
"Let's set your **email address** to associate them with your Git commits.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git config \\--global user.email \"user@example.com\"\n",
|
||
"```\n",
|
||
"\n",
|
||
"Replace **user@example.com** with your email-id. Any future commits you now push to GitHub will be associated with this **email address**. You can also use **git config** to change the user email associated with your Git commits.\n",
|
||
"\n",
|
||
"## Fix the script\n",
|
||
"\n",
|
||
"In this section we are going to fix an issue that has been filed. Navigate to the [issue](https://github.com/google/it-cert-automation-practice/issues/1), and have a look at it.\n",
|
||
"\n",
|
||
"Branches allow you to add new features or test out ideas without putting your main project at risk. In order to add new changes into the repo directory it-cert-automation-practice/Course3/Lab4/, create a new **branch** named improve-username-behavior in your forked repository using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git branch improve\\-username-behavior\n",
|
||
"```\n",
|
||
"\n",
|
||
"Go to the improve-username-behavior branch from the master branch.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git checkout improve\\-username-behavior\n",
|
||
"```\n",
|
||
"\n",
|
||
"Now, navigate to the working directory Lab4/.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"cd ~/it\\-cert-automation-practice/Course3/Lab4\n",
|
||
"```\n",
|
||
"\n",
|
||
"List the files in directory Lab4.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"ls\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"cat validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"#!/usr/bin/env python3\n",
|
||
"\n",
|
||
"import re\n",
|
||
"\n",
|
||
"def validate\\_user(username, minlen):\n",
|
||
"\n",
|
||
" \"\"\"Checks if the received username matches the required conditions.\"\"\"\n",
|
||
"\n",
|
||
" if type(username) != str:\n",
|
||
"\n",
|
||
" raise TypeError(\"username must be a string\")\n",
|
||
"\n",
|
||
" if minlen < 1:\n",
|
||
"\n",
|
||
" raise ValueError(\"minlen must be at least 1\")\n",
|
||
"\n",
|
||
" # Usernames can't be shorter than minlen\n",
|
||
"\n",
|
||
" if len(username) < minlen:\n",
|
||
"\n",
|
||
" return False\n",
|
||
"\n",
|
||
" # Usernames can only use letters, numbers, dots and underscores\n",
|
||
"\n",
|
||
" if not re.match('^\\[a-z0-9.\\_\\]\\*$', username):\n",
|
||
"\n",
|
||
" return False\n",
|
||
"\n",
|
||
" # Usernames can't begin with a number\n",
|
||
"\n",
|
||
" if username\\[0\\].isnumeric():\n",
|
||
"\n",
|
||
" return False\n",
|
||
"\n",
|
||
" return True\n",
|
||
"```\n",
|
||
"\n",
|
||
"This script should validate usernames if they start with an letter only.\n",
|
||
"\n",
|
||
"Here, you can check the validate\\_user function's behavior by calling the function. To edit the **validations.py** Python script, open it in a **nano editor** using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"nano validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"Now, add the following lines of code at the end of the script:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"print(validate\\_user(\"blue.kale\", 3)) # True\n",
|
||
"\n",
|
||
"print(validate\\_user(\".blue.kale\", 3)) # Currently True, should be False\n",
|
||
"\n",
|
||
"print(validate\\_user(\"red\\_quinoa\", 4)) # True\n",
|
||
"\n",
|
||
"print(validate\\_user(\"\\_red\\_quinoa\", 4)) # Currently True, should be False\n",
|
||
"```\n",
|
||
"\n",
|
||
"Once you've finished writing this script, save the file by pressing **Ctrl-o**, the **Enter** key, and **Ctrl-x**.\n",
|
||
"\n",
|
||
"Now, run the **validations.py** on the **python3** interpreter.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"python3 validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"True\n",
|
||
"\n",
|
||
"True\n",
|
||
"\n",
|
||
"True\n",
|
||
"\n",
|
||
"True\n",
|
||
"```\n",
|
||
"\n",
|
||
"Here, as we see the output, it function returns true even if the username doesnot start with an letter. Here we need to change the check of the first character as only letters are allowed in the first character of the username.\n",
|
||
"\n",
|
||
"Continue by opening **validations.py** in the **nano editor** using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"nano validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"There are lots of ways to fix the code; ultimately, you'll want to add additional conditional checks to validate the first character doesn't start with either of the forbidden characters. You can choose whichever way you'd like to implement this.\n",
|
||
"\n",
|
||
"Once you've finished writing this script, save the file by pressing **Ctrl-o**, the **Enter** key, and **Ctrl-x**.\n",
|
||
"\n",
|
||
"Now, run the **validations.py**.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"python3 validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"True\n",
|
||
"\n",
|
||
"False\n",
|
||
"\n",
|
||
"True\n",
|
||
"\n",
|
||
"False\n",
|
||
"```\n",
|
||
"\n",
|
||
"Now, you've fixed the function behavior!\n",
|
||
"\n",
|
||
"## Commit the changes\n",
|
||
"\n",
|
||
"Once the issue is fixed and verified, create a new commit by adding the file to the staging area. You can check the status using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git status\n",
|
||
"```\n",
|
||
"\n",
|
||
"The **git status** command shows the different states of the files in your working directory and staging area, like files that are modified but unstaged and files that are staged but not yet committed.\n",
|
||
"\n",
|
||
"You can now see that the **validations.py** has been modified.\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"On branch improve\\-username-behavior\n",
|
||
"\n",
|
||
"Changes not staged for commit:\n",
|
||
"\n",
|
||
" (use \"git add <file>...\" to update what will be committed)\n",
|
||
"\n",
|
||
" (use \"git checkout -- <file>...\" to discard changes in working directory)\n",
|
||
"\n",
|
||
" modified: validations.py\n",
|
||
"\n",
|
||
"no changes added to commit (use \"git add\" and/or \"git commit -a\")\n",
|
||
"```\n",
|
||
"\n",
|
||
"Now, let's **add** the file to the staging area using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git add validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"Use the **git add** command to **add** content from the working directory into the staging area for the next commit.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git status\n",
|
||
"```\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"On branch improve\\-username-behavior\n",
|
||
"\n",
|
||
"Changes to be committed:\n",
|
||
"\n",
|
||
" (use \"git reset HEAD <file>...\" to unstage)\n",
|
||
"\n",
|
||
" modified: validations.py\n",
|
||
"```\n",
|
||
"\n",
|
||
"Let's now commit the changes. A **git commit** is like saving your work.\n",
|
||
"\n",
|
||
"Commit the changes using the following command:\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git commit\n",
|
||
"```\n",
|
||
"\n",
|
||
"This now opens up an editor that asks you to type a commit message. Every commit has an associated commit message, which is a log message from the user describing the changes.\n",
|
||
"\n",
|
||
"Enter a commit message of your choice and append a line: \"Closes: #1\" at the beginning to indicate that you're closing the issue. Adding this keyword has an additional effect when using Github to manage your repos, which will automatically close the issue for you (for more information, please see the [documentation here](https://help.github.com/en/github/managing-your-work-on-github/closing-issues-using-keywords#closing-an-issue-in-the-same-repository)).\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"Closes: #1\n",
|
||
"\n",
|
||
"Updated validations.py python script.\n",
|
||
"\n",
|
||
"Fixed the behavior of validate\\_user function in validations.py.\n",
|
||
"```\n",
|
||
"\n",
|
||
"Once you've entered the commit message, save it by pressing **Ctrl-o** and the **Enter** key. To exit, click **Ctrl-x**.\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"\\[improve\\-username-behavior d947d11\\] Closes: #1 Updated validations.py python script. Fixed the behavior of validate\\_user function in validations.py.\n",
|
||
"\n",
|
||
" 1 file changed, 5 insertions(+), 2 deletions(-)\n",
|
||
"```\n",
|
||
"\n",
|
||
"## Push changes\n",
|
||
"\n",
|
||
"You forked a repository and made changes to the fork. Now you can ask that the **upstream** repository accept your changes by creating a **pull request**. Now, let's **push** the changes.\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"git push origin improve\\-username-behavior\n",
|
||
"```\n",
|
||
"\n",
|
||
"\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\n",
|
||
"\n",
|
||
"***Note:*** *While pushing the changes to the branch, you will be prompted to enter your Github* ***username*** *and* ***personal access token*** *to push the changes on repo via HTTPS method as password authentication method is currently not supported by Github. It requires the use of personal access tokens rather than traditional passwords so it is necessary for you to create a personal access token to complete the lab (in case you don’t have one).*\n",
|
||
"\n",
|
||
"***Generating a Personal Access Token***\n",
|
||
"\n",
|
||
"***Personal Access Token*** *can be created by moving the application settings of your Github account. Proceed to the* ***Settings*** *menu and choose* ***Developer settings****, where you will locate the option for* ***Personal Access Token****. By utilizing this token, you will be enabled to clone and push to your remote repository using HTTPS. For more help to generate a personal access token, click* [*here*](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line#creating-a-token)*.*\n",
|
||
"\n",
|
||
"\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\\_\n",
|
||
"\n",
|
||
"**Output:**\n",
|
||
"\n",
|
||
"```bash\n",
|
||
"Username for 'https://github.com': XXXXXXXX\n",
|
||
"\n",
|
||
"Password for 'https://XXXXXXXX@github.com': \n",
|
||
"\n",
|
||
"Enumerating objects: 9, done.\n",
|
||
"\n",
|
||
"Counting objects: 100% (9/9), done.\n",
|
||
"\n",
|
||
"Compressing objects: 100% (3/3), done.\n",
|
||
"\n",
|
||
"Writing objects: 100% (5/5), 553 bytes | 138.00 KiB/s, done.\n",
|
||
"\n",
|
||
"Total 5 (delta 2), reused 0 (delta 0)\n",
|
||
"\n",
|
||
"remote: Resolving deltas: 100% (2/2), completed with 2 local objects.\n",
|
||
"\n",
|
||
"remote: \n",
|
||
"\n",
|
||
"remote: Create a pull request for 'improve-username-behavior' on GitHub by visiting:\n",
|
||
"\n",
|
||
"remote: https://github.com/XXXXXXXX/it\\-cert-automation-practice/pull/new/improve\\-username-behavior\n",
|
||
"\n",
|
||
"remote: \n",
|
||
"\n",
|
||
"To https://github.com/XXXXXXXX/it\\-cert-automation-practice.git\n",
|
||
"\n",
|
||
" \\* \\[new branch\\] improve\\-username-behavior -> improve\\-username-behavior\n",
|
||
"```\n",
|
||
"\n",
|
||
"Then, from GitHub, create a pull request from your forked repository \\[git-username\\]/it-cert-automation-practice that includes a description of your change. Your branch improve-username-behavior is now able to merge into the master branch. It should look like the image below:\n",
|
||
"\n",
|
||
"\n",
|
||
"\n",
|
||
"After initializing a **pull request**, you'll see a review page that shows a high-level overview of the changes between your branch (the compare branch) and the repository's base branch. You can add a summary of the proposed changes, review the changes made by commits, add labels, milestones, and assignees, and **@mention** individual contributors or teams.\n",
|
||
"\n",
|
||
"Once you've created a **pull request**, you can **push** commits from your topic branch to add them to your existing **pull request**. These commits will appear in chronological order within your **pull request** and the changes will be visible in the **Files changed** tab.\n",
|
||
"\n",
|
||
"Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request.\n",
|
||
"\n",
|
||
"You can see information about the branch's current deployment status and past deployment activity on the **Conversation** tab.\n",
|
||
"\n",
|
||
"**Note:** PR won't be merged on the master branch so that other users can also make a similar change to fix the issue.\n",
|
||
"\n",
|
||
"## Congratulations!\n",
|
||
"\n",
|
||
"In this lab, you successfully forked a repository, committed changes to your own fork, and created a **pull request** to the upstream. Well done!"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# IT skills in action"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Tailor your resume"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Create a resume and add your new skills"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Add your job experience to your resume"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Writing a Cover Letter"
|
||
]
|
||
},
|
||
{
|
||
"cell_type": "markdown",
|
||
"metadata": {},
|
||
"source": [
|
||
"# Course 3 glossary"
|
||
]
|
||
}
|
||
],
|
||
"metadata": {
|
||
"kernelspec": {
|
||
"display_name": "Python 3",
|
||
"language": "python",
|
||
"name": "python3"
|
||
},
|
||
"language_info": {
|
||
"name": "python",
|
||
"version": "3.12.3"
|
||
}
|
||
},
|
||
"nbformat": 4,
|
||
"nbformat_minor": 2
|
||
}
|