update module4.ipynb
This commit is contained in:
parent
7219e7202d
commit
b4fef3632c
237
module4.ipynb
237
module4.ipynb
@ -6,7 +6,7 @@
|
||||
"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**<svg aria-labelledby=\"cds-react-aria1005828919-:rjv:-title\" fill=\"none\" focusable=\"false\" height=\"16\" role=\"img\" viewBox=\"0 0 20 20\" width=\"16\" class=\"css-8blerm\" id=\"cds-react-aria1005828919-:rjv:\"><title id=\"cds-react-aria1005828919-:rjv:-title\">Opens in a new tab</title></svg>](https://www.coursera.org/learn/introduction-git-github/lecture/8mpDb/the-typical-pull-request-workflow-on-github)\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",
|
||||
@ -153,7 +153,7 @@
|
||||
"source": [
|
||||
"# Updating an Existing Pull Request\n",
|
||||
"\n",
|
||||
"This reading contains the code used in the instructional videos from [**Updating an Existing Pull Request**<svg aria-labelledby=\"cds-react-aria1005828919-:rt4:-title\" fill=\"none\" focusable=\"false\" height=\"16\" role=\"img\" viewBox=\"0 0 20 20\" width=\"16\" class=\"css-8blerm\" id=\"cds-react-aria1005828919-:rt4:\"><title id=\"cds-react-aria1005828919-:rt4:-title\">Opens in a new tab</title></svg>](https://www.coursera.org/learn/introduction-git-github/lecture/aRZ95/updating-an-existing-pull-request)\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",
|
||||
@ -222,7 +222,7 @@
|
||||
"source": [
|
||||
"# Squashing Changes\n",
|
||||
"\n",
|
||||
"This reading contains the code used in the instructional videos from [**Squashing Changes**<svg aria-labelledby=\"cds-react-aria1005828919-:r15d:-title\" fill=\"none\" focusable=\"false\" height=\"16\" role=\"img\" viewBox=\"0 0 20 20\" width=\"16\" class=\"css-8blerm\" id=\"cds-react-aria1005828919-:r15d:\"><title id=\"cds-react-aria1005828919-:r15d:-title\">Opens in a new tab</title></svg>](https://www.coursera.org/learn/introduction-git-github/lecture/6ODVl/squashing-changes)\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",
|
||||
@ -480,8 +480,6 @@
|
||||
"source": [
|
||||
"# How to Use Code Reviews in GitHub\n",
|
||||
"\n",
|
||||
"Review: How to use code reviews | Coursera\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",
|
||||
@ -571,28 +569,249 @@
|
||||
"cell_type": "markdown",
|
||||
"metadata": {},
|
||||
"source": [
|
||||
"# More Information on Code Reviews"
|
||||
"# 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"
|
||||
"# 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"
|
||||
"# 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"
|
||||
"# 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."
|
||||
]
|
||||
},
|
||||
{
|
||||
|
||||
Loading…
Reference in New Issue
Block a user