From df1c226cc608cbc69eb730b7a2a8fad186957f7f Mon Sep 17 00:00:00 2001 From: Tom <20648924+moT01@users.noreply.github.com> Date: Mon, 15 Sep 2025 21:04:15 -0500 Subject: [PATCH] feat(curriculum): add git and GitHub lectures (#62116) Co-authored-by: Zaira <33151350+zairahira@users.noreply.github.com> Co-authored-by: Ilenia <26656284+ilenia-magoni@users.noreply.github.com> --- client/i18n/locales/english/intro.json | 11 +- .../index.md | 9 + .../index.md | 9 + .../68828e965f70137025ec5031.md | 136 +++++++++ .../688290189fecfe7206d22833.md | 136 +++++++++ .../6882902bc844b1723da7eb13.md | 194 +++++++++++++ .../6882904fd7063f7258c0aef3.md | 190 +++++++++++++ .../68829061f03543726ea6f318.md | 180 ++++++++++++ .../68829079ab2abe728a822cc1.md | 248 ++++++++++++++++ .../688290b7f7f46f72d3d4e73d.md | 166 +++++++++++ .../688290c998562972e953d34d.md | 232 +++++++++++++++ .../688290da3736c273009129d0.md | 178 ++++++++++++ .../688290ef85c79973321a23af.md | 158 +++++++++++ .../68829101d909657350cd80af.md | 158 +++++++++++ .../68829116a80ecd73681261b1.md | 174 ++++++++++++ .../6882913b2b58c2738eaaa2d1.md | 264 ++++++++++++++++++ .../6882915386c73273ac489f38.md | 148 ++++++++++ .../68829162a7f96d73c8505d3d.md | 212 ++++++++++++++ .../688291b65db00473e1136725.md | 238 ++++++++++++++++ ...ecture-introduction-to-git-and-github.json | 46 +++ ...eviews-branching-deployment-and-ci-cd.json | 38 +++ .../superblocks/full-stack-developer.json | 2 + 22 files changed, 3126 insertions(+), 1 deletion(-) create mode 100644 client/src/pages/learn/full-stack-developer/lecture-introduction-to-git-and-github/index.md create mode 100644 client/src/pages/learn/full-stack-developer/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/index.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68828e965f70137025ec5031.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290189fecfe7206d22833.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882902bc844b1723da7eb13.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882904fd7063f7258c0aef3.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829061f03543726ea6f318.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829079ab2abe728a822cc1.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290b7f7f46f72d3d4e73d.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290c998562972e953d34d.md create mode 100644 curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688290ef85c79973321a23af.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829101d909657350cd80af.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829116a80ecd73681261b1.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882913b2b58c2738eaaa2d1.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882915386c73273ac489f38.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829162a7f96d73c8505d3d.md create mode 100644 curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688291b65db00473e1136725.md create mode 100644 curriculum/structure/blocks/lecture-introduction-to-git-and-github.json create mode 100644 curriculum/structure/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd.json diff --git a/client/i18n/locales/english/intro.json b/client/i18n/locales/english/intro.json index e58a0ef330e..664d83f63a5 100644 --- a/client/i18n/locales/english/intro.json +++ b/client/i18n/locales/english/intro.json @@ -4805,7 +4805,16 @@ "In this 40-lesson workshop, you will learn how to edit files in the terminal with Nano while building a castle." ] }, - "rhhl": { "title": "328", "intro": [] }, + "lecture-introduction-to-git-and-github": { + "title": "Introduction to Git and GitHub", + "intro": ["Learn how to work with Git and GitHub in these lectures."] + }, + "lecture-working-with-code-reviews-branching-deployment-and-ci-cd": { + "title": "Working With Code Reviews, Branching, Deployment, and CI/CD", + "intro": [ + "Learn about code reviews, branching, deployment, and CI/CD in these lectures." + ] + }, "workshop-sql-reference-object": { "title": "Build an SQL Reference Object", "intro": [ diff --git a/client/src/pages/learn/full-stack-developer/lecture-introduction-to-git-and-github/index.md b/client/src/pages/learn/full-stack-developer/lecture-introduction-to-git-and-github/index.md new file mode 100644 index 00000000000..f23ff01bc16 --- /dev/null +++ b/client/src/pages/learn/full-stack-developer/lecture-introduction-to-git-and-github/index.md @@ -0,0 +1,9 @@ +--- +title: Introduction to Git and GitHub +block: lecture-introduction-to-git-and-github +superBlock: full-stack-developer +--- + +## Introduction to Git and GitHub + +Learn about working with Git and GitHub in these lectures. diff --git a/client/src/pages/learn/full-stack-developer/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/index.md b/client/src/pages/learn/full-stack-developer/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/index.md new file mode 100644 index 00000000000..c2d601480a5 --- /dev/null +++ b/client/src/pages/learn/full-stack-developer/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/index.md @@ -0,0 +1,9 @@ +--- +title: Introduction to Working With Code Reviews, Branching, Deployment, and CI/CD +block: lecture-working-with-code-reviews-branching-deployment-and-ci-cd +superBlock: full-stack-developer +--- + +## Introduction to Working With Code Reviews, Branching, Deployment, and CI/CD + +Learn about working with code reviews, branching, deployment, and CI/CD in these lectures. diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68828e965f70137025ec5031.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68828e965f70137025ec5031.md new file mode 100644 index 00000000000..09364577919 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68828e965f70137025ec5031.md @@ -0,0 +1,136 @@ +--- +id: 68828e965f70137025ec5031 +title: What Is Version Control, and Why Are These Systems Necessary? +challengeType: 19 +dashedName: what-is-version-control-and-why-are-these-systems-necessary +--- + +# --description-- + +If you've worked on something, like a thesis paper, where you've saved copies after making significant changes and named the files something like `Thesis-Draft`, `Thesis-Final`, `Thesis-Final-For-Real`, and `Thesis-Absolute-Final-DO-NOT-CHANGE`, you've used a very rudimentary approach to version control. But what if I told you there is a better way? + +You may have heard of tools like Git, SVN, or Mercurial before. These are version control systems, and they are a key component to every developer's workflow. A version control system allows you to track and manage changes in your project. For the purposes of these lectures, we will be focusing on Git. + +Git offers powerful tools that allow you to manage the edit history of a project. You will learn more about how to use Git and the features it offers in upcoming lectures. For now, here's what you really need to know: + +Git allows you to do things like create commits, which are a snapshot of a specific state of your codebase. You can then compare commits to see what changes you have made, revert a commit that has improper changes, and more. + +You can also create "branches", which you can think of as different pathways in your code. While a branch might be the road you walk down, commits are the landmarks along the way. Branches allow you to do things like work on a new feature in isolation, such that if your work goes sideways you can delete the branch without impacting the core codebase. + +These features make version control an essential component of collaboration with other developers. When you have multiple people working in the same project, branches allow each of them to work on their own code without running over each other's changes. + +You will often pair a version control system like Git with a version control provider like GitHub or Gitlab, which offers you additional collaboration tools and the ability to back up your projects to the cloud. + +But even without a cloud-based storage solution, version control systems can be a game changer for your workflows. No more `THIS-IS-THE-FINAL-COPY-FOREVER` files. + +There's a lot of cool information to cover about using these systems, so let's do a deep dive in the next few lectures! + +# --questions-- + +## --text-- + +What is a commit in Git? + +## --answers-- + +A development branch. + +### --feedback-- + +Think about what Git saves when you make changes to your project. + +--- + +A snapshot of a specific state of your codebase. + +--- + +A cloud backup service. + +### --feedback-- + +Think about what Git saves when you make changes to your project. + +--- + +A collaboration tool for developers. + +### --feedback-- + +Think about what Git saves when you make changes to your project. + +## --video-solution-- + +2 + +## --text-- + +Why are branches useful in version control systems like Git? + +## --answers-- + +They automatically fix bugs in your code. + +### --feedback-- + +Consider how branches help when multiple developers work on the same project. + +--- + +They increase the speed of your application. + +### --feedback-- + +Consider how branches help when multiple developers work on the same project. + +--- + +They allow you to work on features in isolation. + +--- + +They provide better encryption for your project files. + +### --feedback-- + +Consider how branches help when multiple developers work on the same project. + +## --video-solution-- + +3 + +## --text-- + +Which of the following is NOT mentioned as a version control system in the lecture? + +## --answers-- + +Git + +### --feedback-- + +Review the version control systems mentioned at the beginning of the lecture. + +--- + +SVN + +### --feedback-- + +Review the version control systems mentioned at the beginning of the lecture. + +--- + +Mercurial + +### --feedback-- + +Review the version control systems mentioned at the beginning of the lecture. + +--- + +Docker + +## --video-solution-- + +4 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290189fecfe7206d22833.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290189fecfe7206d22833.md new file mode 100644 index 00000000000..15c4a78317b --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290189fecfe7206d22833.md @@ -0,0 +1,136 @@ +--- +id: 688290189fecfe7206d22833 +title: What Is the Purpose of Sites Like GitHub and GitLab, and What Are Some Benefits of Using Them? +challengeType: 19 +dashedName: what-is-the-purpose-of-sites-like-github-and-gitlab +--- + +# --description-- + +In a previous lecture, we briefly mentioned GitHub. Both GitHub and Gitlab are version control providers. This means they are cloud-based solutions that offer storage of version-controlled projects in something called "repositories", and enable collaboration features to use with those projects. + +Before we dive in to the features these platforms offer, we need to discuss the different types of projects. Many projects are considered "open-source", which means people can see the code you publish, propose changes, report issues, and even run a modified version. + +But sometimes you may only want your teammates to see and work on the code. You can also publish a project as "closed-source", meaning the only people who can see and interact with the project are the people you explicitly authorize. + +Regardless of which approach your project takes, sites like GitHub and Gitlab can massively level up your team's collaboration. + +For example, a teammate working on a feature might be stuck and have questions. Rather than having to copy-paste the code into Discord for you to read, or hop on a call to screen share their work, they can upload the changes directly to GitHub. From there, you can view the changes in your browser or even download the changes to run and debug locally. + +When a teammate has completed a feature, they can propose the changes through these websites. You are then able to review the changes, leaving comments on specific files or lines if you have thoughts and questions. You can even propose suggested edits which they can apply to the changes right there in the browser! + +If you are happy with the changes, you can accept them and merge them into your primary branch. This means the entire team can then download the latest changes locally so they have the most up-to-date code when they start on their next task. + +Speaking of tasks, these sites also offer powerful issue trackers. You can use these to track and assign tickets to your team members, accept bug reports from the public, and even plan full sprints through things like the project boards. + +There are many more features offered by these sites. In the next few lectures, we'll cover the key aspects so you can dive right in and start collaborating! + +# --questions-- + +## --text-- + +What is the main purpose of GitHub and GitLab as discussed in the lecture? + +## --answers-- + +Primarily for storing backups of code. + +### --feedback-- + +Consider what these platforms allow teams to do with their projects. + +--- + +Version control providers with collaboration features. + +--- + +Platforms exclusively for open-source projects. + +### --feedback-- + +Consider what these platforms allow teams to do with their projects. + +--- + +Tools for writing and editing code online. + +### --feedback-- + +Consider what these platforms allow teams to do with their projects. + +## --video-solution-- + +2 + +## --text-- + +What is an advantage of using GitHub or GitLab for team collaboration? + +## --answers-- + +They automatically fix bugs in your code. + +### --feedback-- + +Think about how these platforms improve the workflow between teammates. + +--- + +They eliminate the need for code reviews. + +### --feedback-- + +Think about how these platforms improve the workflow between teammates. + +--- + +Team members can propose changes that others can review online. + +--- + +They provide free web hosting for all projects. + +### --feedback-- + +Think about how these platforms improve the workflow between teammates. + +## --video-solution-- + +3 + +## --text-- + +Which of the following project management features do GitHub and GitLab offer? + +## --answers-- + +Automatic code generation. + +### --feedback-- + +Think about how these platforms help organize work within a team. + +--- + +Issue trackers and project boards. + +--- + +Direct integration with Discord. + +### --feedback-- + +Think about how these platforms help organize work within a team. + +--- + +Free domain name registration. + +### --feedback-- + +Think about how these platforms help organize work within a team. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882902bc844b1723da7eb13.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882902bc844b1723da7eb13.md new file mode 100644 index 00000000000..5a98671975f --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882902bc844b1723da7eb13.md @@ -0,0 +1,194 @@ +--- +id: 6882902bc844b1723da7eb13 +title: How Do You Install and Set Up Git? +challengeType: 19 +dashedName: how-do-you-install-and-set-up-git +--- + +# --description-- + +Before you can really start to make use of version control, and sites like GitHub, you need to have Git installed and ready to use. + +To check if Git is already installed on your machine you can run the following command in the terminal: + +```sh +git --version +``` + +If you see a version number, that means Git is installed. If not, then you will need to install it. + +For Linux systems, Git often comes preinstalled with most distros. If you do not have Git pre-installed, you should be able to install it with your package manager commands such as `sudo apt-get install git` or `sudo pacman -S git`. + +For Mac users, you can install Git via Homebrew with `brew install git`, or you can download the executable installer from Git's website. + +For Windows, you can download the executable installer from Git's website. Or, if you have set up Chocolatey, you can run `choco install git.install` in PowerShell. Note that on Windows, you may also want to download GitBash so you have a Unix-like shell environment available. + +To make sure the installation worked, run the `git --version` command again in the terminal. + +Once you have Git installed, you will need to make a few changes to the configuration. You should only need to make these changes once on your computer and you won't need to continually make changes when you make upgrades. + +`git config` is used to set configuration variables that are responsible for how Git operates on your machine. To view your current setting variables and where they are stored on your system, you can run the following command: + +```sh +git config --list --show-origin +``` + +Right now you should be seeing only system-level configuration settings if you just installed Git for the first time. If you have already installed Git prior to this lecture, then you might be seeing user configurations for a user name and email. + +To set your user name, you can run the following command: + +```sh +git config --global user.name "Jane Doe" +``` + +The `--global` flag is used here to set the user name for all projects on your system that use Git. If you need to override the user name for a particular project, then you can run the command in that particular project directory without the `--global` flag. + +To set the user email address, you can run the following command: + +```sh +git config --global user.email janedoe@example.com +``` + +Configuring your user name and email is important because Git will use this information for every commit you make in a project. You will learn more about commits in a future lecture. + +Another configuration you can set is the preferred editor you want Git to use. Here is an example of how to set your preferred editor to Emacs: + +```sh +git config --global core.editor emacs +``` + +Other options include Vim, Nano, VS Code, and more. For example, if you use VS Code for your editor, then you can configure Git settings like this: + +```sh +git config --global core.editor "code --wait" +``` + +If you choose not to set a preferred editor, then Git will default to your system's default editor. + +If you are using a Windows machine and want to change your editor, you will need to provide the complete path to the executable file like this: + +```sh +git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" +``` + +To see your list of configurations, you can run the following command: + +```sh +git config --list +``` + +Now that you have Git installed and set up, you are now ready to start adding version control to your projects. + +# --questions-- + +## --text-- + +What does the following command do? + +```sh +git config --list --show-origin +``` + +## --answers-- + +Shows a list of only editors available to use with Git and where they are stored on your system. + +### --feedback-- + +Refer back to the section discussing Git configuration for the answer. + +--- + +Shows a list of only color options in your Git configuration. + +### --feedback-- + +Refer back to the section discussing Git configuration for the answer. + +--- + +Shows your current setting variables and where they are stored on your system. + +--- + +Shows a list of all projects on your system that use Git. + +### --feedback-- + +Refer back to the section discussing Git configuration for the answer. + +## --video-solution-- + +3 + +## --text-- + +What is the purpose of using the `--global` flag when configuring your user name? + +## --answers-- + +The `--global` flag is used to set the user name for some projects on your system that use Git. + +### --feedback-- + +Think about how this flag can effect all projects that use Git. + +--- + +The `--global` flag is used to set the user name for all projects on your system that use Git. + +--- + +The `--global` flag is used to set the user name for none of the projects on your system that use Git. + +### --feedback-- + +Think about how this flag can effect all projects that use Git. + +--- + +The `--global` flag is used to set the user name for only projects on your system that are more than 5 years old and use Git. + +### --feedback-- + +Think about how this flag can effect all projects that use Git. + +## --video-solution-- + +2 + +## --text-- + +Which of the following is NOT a valid option mentioned for setting your preferred editor in Git? + +## --answers-- + +Vim + +### --feedback-- + +Refer to the end of the script where Git configurations and editors were set. + +--- + +Emacs + +### --feedback-- + +Refer to the end of the script where Git configurations and editors were set. + +--- + +Nano + +### --feedback-- + +Refer to the end of the script where Git configurations and editors were set. + +--- + +ESLint + +## --video-solution-- + +4 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882904fd7063f7258c0aef3.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882904fd7063f7258c0aef3.md new file mode 100644 index 00000000000..d8254d70f8a --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/6882904fd7063f7258c0aef3.md @@ -0,0 +1,190 @@ +--- +id: 6882904fd7063f7258c0aef3 +title: How Do You Handle Security Requirements Like SSH and GPG Keys? +challengeType: 19 +dashedName: how-do-you-handle-security-requirements-like-ssh-and-gpg-keys +--- + +# --description-- + +Before you can push your repository to GitHub, you will need to be authenticated. Both SSH and GPG keys use a public-private pair. This means that you keep a private key on your local machine, which you use to authenticate yourself. You share a public key with the people or services that need to validate your auth. In other words, the private key is required to perform an action, and the public key is used to verify the action. + +GPG, or Gnu Privacy Guard, keys are typically used to sign files or commits. Someone can then use your public GPG key to verify that the file signature is from your key and that the contents of the file have not been modified or tampered with. SSH, or Secure SHell, keys are typically used to authenticate a remote connection to a server - via the `ssh` utility. However, as you'll learn in this lecture, you can also use an SSH key to sign commits. + +To generate a GPG key, you'll need to run: + +```sh +gpg --full-generate-key +``` + +For an SSH key, you'll run: + +```sh +ssh-keygen -t ed25519 -C "your_email@example.com" +``` + +Make sure to provide your actual email. + +Both of these commands should request a passphrase to secure the key. These are optional, but strongly recommended. + +For SSH keys, you'll get two files - one for your private key, and one for your public. Public key filenames will end in `.pub`, so you do not accidentally share your private key. These files will be in `~/.ssh`. + +GPG keys, however, will be in a hidden and encrypted directory. Instead, to list your public keys, you'll run: + +```sh +gpg --list-secret-keys --keyid-format=long +``` + +Then, to get the public key, use: + +```sh +gpg --armor --export "" +``` + +But what can you do with these new keys? Well, we've talked about signing your commits, and that's something you can use either of these keys for. + +In order to sign your commits with your GPG key, you'll need to upload your public key, not the private key, to your GitHub account. Then, take the short ID you got from listing the keys earlier, and run this command to set it as your git signing key: + +```sh +git config --global user.signingkey +``` + +Then, you can pass the `-S` flag to your `git commit` command to sign a specific commit - you'll need to provide your passphrase. Alternatively, if you want to sign every commit automatically, you can set the autosign config to `true`: + +```sh +git config --global commit.gpgsign true +``` + +To sign with an SSH key, which is a relatively new feature on GitHub, you'll need to start by uploading the key to your GitHub account. Then you'll need to set the signing mode for git to use SSH: + +```sh +git config --global gpg.format ssh +``` + +Then, to set the signing key, you'll pass the file path instead of an ID: + +```sh +git config --global user.signingkey +``` + +Finally, you can enable auto signing as you would for a GPG key. + +With either of these approaches set up, you're now set to have verified commits which will get a special badge on GitHub. + +# --questions-- + +## --text-- + +What is the fundamental difference between private and public keys in SSH and GPG key pairs? + +## --answers-- + +The private key is longer than the public key. + +### --feedback-- + +Think about who has access to each key and where they're stored. + +--- + +The private key stays on your local machine while the public key is shared. + +--- + +The public key is used to encrypt data while the private key decrypts it. + +### --feedback-- + +Think about who has access to each key and where they're stored. + +--- + +The private key expires after a certain time period. + +### --feedback-- + +Think about who has access to each key and where they're stored. + +## --video-solution-- + +2 + +## --text-- + +Which command would you use to enable automatic signing of all commits with your GPG key? + +## --answers-- + +```sh +git config --global gpg.autosign true +``` + +### --feedback-- + +Look at the configuration command mentioned in the lecture for automatically signing all commits. + +--- + +```sh +git config --global commit.sign always +``` + +### --feedback-- + +Look at the configuration command mentioned in the lecture for automatically signing all commits. + +--- + +```sh +git config --global commit.gpgsign true +``` + +--- + +```sh +git --enable-auto-signing +``` + +### --feedback-- + +Look at the configuration command mentioned in the lecture for automatically signing all commits. + +## --video-solution-- + +3 + +## --text-- + +What's required to set up SSH key signing for Git commits on GitHub? + +## --answers-- + +Only upload your public SSH key to GitHub. + +### --feedback-- + +Think about the configuration steps mentioned for SSH signing. + +--- + +Set the signing format to SSH and configure your signing key path. + +--- + +Generate a special SSH signing key separate from your regular SSH key. + +### --feedback-- + +Think about the configuration steps mentioned for SSH signing. + +--- + +Enable a special GitHub feature in your account settings. + +### --feedback-- + +Think about the configuration steps mentioned for SSH signing. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829061f03543726ea6f318.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829061f03543726ea6f318.md new file mode 100644 index 00000000000..0811173cf12 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829061f03543726ea6f318.md @@ -0,0 +1,180 @@ +--- +id: 68829061f03543726ea6f318 +title: What Is a Repository, and How Do You Create One? +challengeType: 19 +dashedName: what-is-a-repository-and-how-do-you-create-one +--- + +# --description-- + +We've talked a bit about Git and GitHub, so now we can start to put it all together. In order to do this, you need a repository. But what is a repository? You can think of a repository as a container for a project - if you are working on an app, you would keep the files for that app together in a repository. + +Repositories can be local on your computer, or remote on a service like GitHub. To create a repository, you can start with either local or remote - the result will be the same, so take whatever approach fits your workflow best. For a workflow where you start with a remote repository, you can create one directly through GitHub's website by following these instructions: + +Visit GitHub's website, make sure you are logged in, and then click the plus icon in the top right of the navigation bar. You'll see quite a few options, but the one you care about is "New Repository". Select that to open the UI for creating a new repository. + +The first option you'll see there is the ability to choose a template. You likely do not have one of these set up yet, but a template is a special kind of repository that you can use as a springboard for your new repositories. These are helpful for including documentation or issue templates in all of your projects. + +Your next option is to select on owner, you can choose your user account or any organizations you own or have access to. Then you can name the repository - in general, you'll want to use a name that succinctly describes the project you are building. As a general best practice, you want to avoid spaces in your repo name. GitHub will automatically replace them with hyphens. + +Next, you can optionally add a description which will appear on the repository's home page. + +You can also choose whether the repository will be public or private. A public repository can be viewed and downloaded by anyone. A private repository can only be accessed by you, and anyone you grant explicit access to. + +Finally, if you do not select a template, you will see options to generate files in the repository automatically. A README file will appear on the repository's homepage, and is a great way to provide documentation and descriptions of your project. A `.gitignore` file allows you to specify files that Git will "ignore" - this is great for things like package dependencies, environment files, and other things you don't want to be saved. GitHub will offer templates for this file, which exclude the common items for the specified language or runtime. And a license is a legal document which outlines who may use your software, and what they may do with it. + +When you have your settings all configured as you like, you can click the "Create Repository" button to finish the process. You'll automatically be redirected to the landing page for your new repository! + +From here, you can click the "Code" button to get options to clone your repository to your computer. + +You can ignore the "Codespaces" and "Copilot" tabs for this lecture. Instead, we are going to focus on the three options in the "Local" tab. The first two, HTTPS and SSH, are used in the same way. You use the `git clone` command with the URL provided in the box to clone the remote repository to your computer. The difference between these two is the connection and authentication methods. + +For cloning a public repository, you won't actually need to authenticate. But to clone a private repository, or to push to either public or private repositories, you will have to be authenticated. An HTTPS remote URL used to authenticate you via your GitHub username and password. However, due to security concerns this is no longer supported, and you are instead required to use a username and access token. Even then, it's a much less secure method than SSH, which uses your private and public keys. This has an added benefit of automatically signing you in, rather than having to provide a token every time. There will be a separate lecture diving deeper into SSH and how it works but you can also read through the GitHub documentation on how to setup SSH. + +To clone the repository, you can run this in the terminal: + +```sh +git clone git@github.com:your-username/your-repository-name +``` + +It will create a folder on your computer with your repository name and contain all the files from your repository within it. From there you can `cd` (change directory) to your cloned repository with: + +```sh +cd name-of-cloned-repo +``` + +Additionally, the local copy of your repo will have a remote pointing to the copy on GitHub. To check your remotes you can run the following command: + +```sh +git remote -v +``` + +Another option for cloning your repository is to use the GitHub CLI. This tool is used to do GitHub-specific tasks without leaving the command line. If you do not have it installed, you can get instructions to do so from GitHub's documentation - but you should have it available in your system's package manager. + +To clone a repository with the CLI tool, I would use: + +```sh +gh repo clone your-username/your-repository-name +``` + +The end result of these commands is the same: you'll have a copy of your repository locally. + +You can also use the GitHub CLI to create a repository: + +```sh +gh repo create +``` + +If you don't pass any arguments, the CLI will give you an interactive wizard to set up your repository. This wizard will give you all of the same options as the web UI. With this tool, you will also get the option to clone the new repository immediately, so you won't have to go through the manual steps outlined earlier. + +You now have a basic understanding of how repositories work, and how you can create one to start properly versioning your work. In future lectures, you will learn how to push an existing local repository to GitHub and how to push changes to remote repositories. + +# --questions-- + +## --text-- + +What does a repository primarily function as in Git? + +## --answers-- + +A tool for automatically formatting code. + +### --feedback-- + +Think about the fundamental purpose of repositories in version control. + +--- + +A container for a project and its files. + +--- + +A backup system for your computer. + +### --feedback-- + +Think about the fundamental purpose of repositories in version control. + +--- + +A collaboration platform for team meetings. + +### --feedback-- + +Think about the fundamental purpose of repositories in version control. + +## --video-solution-- + +2 + +## --text-- + +When creating a repository on GitHub, which of the following is NOT an automatic file generation option? + +## --answers-- + +A README file. + +### --feedback-- + +Review the automatic file generation options mentioned in the lecture. + +--- + +A `.gitignore` file. + +### --feedback-- + +Review the automatic file generation options mentioned in the lecture. + +--- + +A license file. + +### --feedback-- + +Review the automatic file generation options mentioned in the lecture. + +--- + +A `package.json` file. + +## --video-solution-- + +4 + +## --text-- + +Which of the following Git commands is used to clone a remote repository to your local computer? + +## --answers-- + +`git cloned` + +### --feedback-- + +Review the last part of the lecture. + +--- + +`git clones` + +### --feedback-- + +Review the last part of the lecture. + +--- + +`git clone` + +--- + +`git cloning` + +### --feedback-- + +Review the last part of the lecture. + +## --video-solution-- + +3 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829079ab2abe728a822cc1.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829079ab2abe728a822cc1.md new file mode 100644 index 00000000000..2f5eac6ecbe --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/68829079ab2abe728a822cc1.md @@ -0,0 +1,248 @@ +--- +id: 68829079ab2abe728a822cc1 +title: How Do You Push a Local Repository to GitHub? +challengeType: 19 +dashedName: how-do-you-push-a-local-repository-to-github +--- + +# --description-- + +In a previous lecture, you learned how to create a new repository on GitHub. But what if you had an existing project locally that you want to add to GitHub? In this lecture, you will learn how to push existing local repositories to GitHub and pull changes down from remote repositories. + +Start by creating a new repository on GitHub without any files. When done correctly, you should be redirected a page that includes the URL needed to clone your repository. + +Now navigate to your terminal and select an existing project you wish to add to GitHub. In this lecture, I am choosing a local project called `super-awesome-game` with the following files inside: + +```sh +jessicawilkins super-awesome-game >> ls +README.md index.html script.js styles.css +``` + +To setup version control for this project using Git, you will need to run the `git init` command in the project directory. This will initialize an empty Git repository so Git can be begin tracking changes for this project. When done correctly you should see a similar output in the terminal: + +```sh +jessicawilkins super-awesome-game >> git init +Initialized empty Git repository in /Users/jessicawilkins/workspace/freeCodeCamp/super-awesome-game/.git/ +``` + +When you initialize an empty Git repository to a project, a new `.git` hidden directory will be added. To view the addition of the directory you can run the `ls -a` command which lists all files and directories, including hidden ones: + +```sh +jessicawilkins super-awesome-game >> ls -a +. .. .git README.md index.html script.js styles.css +``` + +It is important not to delete that `.git` directory, otherwise all of your Git history will be lost. + +Now that the empty Git repository has been initialized, you can run the `git status` command. This command is used to show the current state of your working directory - you will be using this command a lot in your workflow. You should see an output similar to this: + +```sh +jessicawilkins super-awesome-game >> git status +On branch main + +No commits yet + +Untracked files: + (use "git add ..." to include in what will be committed) + README.md + index.html + script.js + styles.css + +nothing added to commit but untracked files present (use "git add" to track) +``` + +`On branch main` means that you are on the `main` branch. A branch in Git is a separate workspace where you can make changes. The `main` branch will often represent the primary or production branch in a real world application. Developer teams will create multiple branches for new features and bug fixes and then merge those changes back into the `main` branch. You will learn more about that process in a future lecture. + +`Untracked files` means that Git has detected files that it is currently not tracking. + +There are five states that a file can be in: + +1. "Untracked": This means that the file is new to the repository, and Git has not "seen" it before. +2. "Modified": This file existed in the previous commit, and has changes that have not been committed. +3. "Ignored": You likely won't see ignored files in Git, but your IDE might have an indicator for them. Ignored files are excluded from Git operations, typically because they are included in the `.gitignore` file. +4. "Deleted": A deleted file is the opposite of an untracked file - it's a file that previously existed, and has been removed. +5. "Renamed": A renamed file is a file where the contents are unchanged, but the name or location of the file was modified. In some cases, a file can be considered renamed even if it has a small amount of changes. + +When you have uncommitted changes in your repo, you will need to first "stage" them. A "staging area" is a special file in your `.git` directory that contains information that will go into your next commit. A commit is effectively a snapshot of the current state of your repository. + +If you want to stage one file at a time, then you can use the following command: + +```sh +git add name-of-file +``` + +If you want to stage all unstaged changes, then you can use `git add .` The period (`.`) is an alias for the current directory you are in. Some developers will warn against using `git add .` because you might end up staging files that you didn't intend to. If that happens, you can "unstage" them using the following command: + +```sh +git reset name-of-file +``` + +In general though, as long as you are monitoring which files are being added using `git status` before you stage them, then you should be fine. + +Once you stage your files, then you will need to commit them. You can commit your changes by running the `git commit` command. This will open up your preferred editor of choice you set in the Git configuration. Once the editor is open, you can provide a detailed message of your changes. You can also choose to provide a shorter message by using the `git commit -m` command like this: + +```sh +git commit -m "short message goes here" +``` + +If you are going to use the `-m` flag, you will still want to provide a descriptive message to provide context for the changes. Here are some examples of good messages you might use: + +```sh +git commit -m "feat(api): implement JWT-based authentication" +git commit -m "fix(auth): correct token expiration time" +git commit -m "refactor: simplify login flow logic" +``` + +The `feat(api)` and `fix(auth)` follows the Conventional Commits style which is used to provide context on the types of changes in that commit. + +After you have committed your work, and run `git status` again, you should see the following output in the terminal: + +```sh +On branch main +nothing to commit, working tree clean +``` + +To view all of your prior commits for this project you can run the `git log` command. This will list all prior commits with helpful information like the author, date of commit, commit message and commit hash. The commit hash is a long string which serves as a unique identifier for a commit. + +Once you are done committing your work, you can now push your changes to GitHub. You will first need to setup the remote connection to your remote repo. You learned about this in the previous lecture, but here is a reminder using SSH: + +```sh +git remote add origin git@github.com:your-github-username/name-of-repo.git +``` + +The last step is to push your changes to GitHub using this command: + +```sh +git push -u origin main +``` + +The `-u` flag is shorthand for `--set-upstream`. It connects your local `main` branch to the remote `main` branch on `origin`. You only need to use it once per new branch. After that, you can simply run `git push` without specifying the branch name. + +When done correctly, you should see a similar result in the terminal: + +```sh +Enumerating objects: 3, done. +Counting objects: 100% (3/3), done. +Delta compression using up to 8 threads +Compressing objects: 100% (2/2), done. +Writing objects: 100% (3/3), 253 bytes | 253.00 KiB/s, done. +Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) +To https://github.com/jdwilkin4/super-awesome-game.git + * [new branch] main -> main +branch 'main' set up to track 'origin/main'. +``` + +You should also see the new changes on your GitHub repo page when you refresh the page. + +If you are collaborating with others on a project and need to pull down new changes from the repository, you can use the `git pull` command. You will learn more about working on a team and collaboration in a future lecture. + +# --questions-- + +## --text-- + +What command would you use to initialize a Git repository in an existing local directory? + +## --answers-- + +`git create` + +### --feedback-- + +This is the basic command that transforms a regular directory into a Git repository. + +--- + +`git start` + +### --feedback-- + +This is the basic command that transforms a regular directory into a Git repository. + +--- + +`git init` + +--- + +`git repository --new` + +### --feedback-- + +This is the basic command that transforms a regular directory into a Git repository. + +## --video-solution-- + +3 + +## --text-- + +What does the `git commit -m` command do? + +## --answers-- + +It commits your changes and shows a log of all commit messages you have written so far. + +### --feedback-- + +Refer back to the section discussing commits. + +--- + +It commits your changes and opens an editor for you to write an elaborate message. + +### --feedback-- + +Refer back to the section discussing commits. + +--- + +It commits your changes and omits the message your provides. + +### --feedback-- + +Refer back to the section discussing commits. + +--- + +It commits your changes with a short message you provide. + +## --video-solution-- + +4 + +## --text-- + +Which of the following commands is used to push up changes to remote repository? + +## --answers-- + +`git pushing` + +### --feedback-- + +Review the last bit of the lecture. + +--- + +`git pushed` + +### --feedback-- + +Review the last bit of the lecture. + +--- + +`git push` + +--- + +`git pushes` + +### --feedback-- + +Review the last bit of the lecture. + +## --video-solution-- + +3 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290b7f7f46f72d3d4e73d.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290b7f7f46f72d3d4e73d.md new file mode 100644 index 00000000000..76be0fa298f --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290b7f7f46f72d3d4e73d.md @@ -0,0 +1,166 @@ +--- +id: 688290b7f7f46f72d3d4e73d +title: How Do You Contribute to Other People's Repositories? +challengeType: 19 +dashedName: how-do-you-contribute-to-other-peoples-repositories +--- + +# --description-- + +You've learned about creating commits and pushing them up to your own repository that you control. You can do the same for other projects that you do not maintain, but there are some extra steps. + +First and foremost, you generally won't have "write access" to someone else's project. This means you cannot push commits directly to them. Instead, you'll need to create a copy of the repository to work from. This process is called "forking". + +To fork a repository, visit the repository you want to contribute to on GitHub. At the top, you'll see a "Fork" button. Click this to be taken to the UI for creating your fork. + +You'll see a similar screen to the one where you created your own repository, but with fewer options. You can choose an owner, either your personal account or an organization you have access to, a new name for the fork, and a new description. + +You also have an option to copy only the `main` branch (or the default configured for the repository). This is generally a good idea, unless you need to contribute to a specific feature branch. You'll learn more about branches in a future lecture. For now, leave that box ticked. + +Click "Create fork" and your new repository will be created, and you'll automatically be taken to it. + +Next, clone it to your local computer just like you would do with your own repository, using SSH or the GitHub CLI. + +Now, let's take a look at the remotes your local clone has configured. Open a terminal in the local repository directory and run `git remote -v` to get a full list, it should look something like this: + +```sh +origin git@github.com:your-username/your-repo-name.git (fetch) +origin git@github.com:your-username/your-repo-name.git (pull) +``` + +By cloning a repository from GitHub, Git has automatically configured your fork as the `origin` remote. However, when you're working from a fork, you will often need to update your copy to bring in the changes from the original repository. + +To do this, let's add the original repository as another remote. Return to the page where you forked the repository from, click the "Code" button, and grab the SSH URL. Then run the command to create a new upstream remote: + +```sh +git remote add upstream git@github.com:original-repo-username/repo-name.git +``` + +`upstream` is the name of the remote - you can name it something else, but `upstream` tends to be the convention. If you look at your remotes again, you will see your new upstream remote: + +```sh +origin git@github.com:your-username/your-repo-name.git (fetch) +origin git@github.com:your-username/your-repo-name.git (pull) +upstream git@github.com:original-repo-username/your-repo-name.git (fetch) +upstream git@github.com:original-repo-username/your-repo-name.git (pull) +``` + +With the `upstream` remote you'll be able to do things like `git fetch upstream` and `git merge upstream/main` to get the latest changes from the original project into your local fork. + +A fork is still a repository, and you create commits and push changes in the same way. However, before diving into that, you should understand that there are certain strategies that you should follow when making changes to someone else's project. You'll learn more about these strategies in upcoming lectures. + +Projects which make their source code available to the public, allow you to modify the code, and accept code contributions are called "open source" projects. There are a lot of benefits to open source, such as allowing the community to help you identify and fix bugs, learning from the contributions people make to your work, and fostering a community of developers that you can turn in to a network. + +When you make changes to someone's project, you are considered an "open source contributor". Contributing to open source projects can be an excellent preview of what working on a professional developer team is like. And some of the strategies here will help you do just that, and carry over into your first paid role. + +And if you ever have questions about how to contribute, most open source projects will have contributing guidelines that contain an overview of everything you need to know. But if you still aren't sure, it never hurts to open an issue on the repository to ask your questions - or, if they have a community space on a platform like Discord, join and ask your questions there. + +# --questions-- + +## --text-- + +Why do you need to fork a repository when contributing to someone else's project? + +## --answers-- + +To make the code run faster. + +### --feedback-- + +Think about the permissions model for repositories you don't own. + +--- + +Because you generally don't have write access to someone else's repository. + +--- + +To rename the repository. + +### --feedback-- + +Think about the permissions model for repositories you don't own. + +--- + +To completely replace the original repository. + +### --feedback-- + +Think about the permissions model for repositories you don't own. + +## --video-solution-- + +2 + +## --text-- + +After forking and cloning a repository, what command would you use to add the original repository as a remote? + +## --answers-- + +`git add upstream [URL]` + +### --feedback-- + +Consider which Git command is used to manage remote repositories. + +--- + +`git clone upstream [URL]` + +### --feedback-- + +Consider which Git command is used to manage remote repositories. + +--- + +`git remote add upstream [URL]` + +--- + +`git push upstream [URL]` + +### --feedback-- + +Consider which Git command is used to manage remote repositories. + +## --video-solution-- + +3 + +## --text-- + +What is the conventional name for the remote that points to the original repository you forked from? + +## --answers-- + +`origin` + +### --feedback-- + +Remember the term mentioned in the lecture that is typically used for this purpose. + +--- + +`main` + +### --feedback-- + +Remember the term mentioned in the lecture that is typically used for this purpose. + +--- + +`source` + +### --feedback-- + +Remember the term mentioned in the lecture that is typically used for this purpose. + +--- + +`upstream` + +## --video-solution-- + +4 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290c998562972e953d34d.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290c998562972e953d34d.md new file mode 100644 index 00000000000..47e4c13b898 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290c998562972e953d34d.md @@ -0,0 +1,232 @@ +--- +id: 688290c998562972e953d34d +title: How Do You Create a New Branch for Your Repository? +challengeType: 19 +dashedName: how-do-you-create-a-new-branch-for-your-repository +--- + +# --description-- + +You've previously learned how to commit changes and push them up to your remote repository, but all of that has been on your default `main` branch. That can work for a smaller project, but as you contribute to other open source projects, or as your project grows, branches are essential. + +For example, if you fork a repository and make commits to the `main` branch of your fork, you may end up with changes in your fork that the original repository did not accept. This can make it incredibly difficult to update your branch with the changes from the fork that were accepted. Or, when working on your own project, switching between different tasks becomes much more difficult if you are not using branches. Instead, you have to manually keep track of which changes relate to which feature or fix. + +But what exactly is a branch? Consider your `main` branch as a highway, with each commit being a car that enters the highway. You may decide you want to go take a look at something, like creating a new feature, so you need to get off of the highway for a bit to go see. + +A branch is essentially a deviation from your main history, where you can freely play around with changes for a new feature or a bug fix. If you are happy with your changes, you can get back on the highway by merging the branch into `main`. If you aren't happy with your changes, you can delete the branch and switch back to `main` without accepting the changes. + +Before creating a new branch, you view your branches with the `git branch` command. The output might look like this: + +```sh +* main +``` + +Right now we only have the one branch, our default `main` branch. The asterisk (`*`) means that is the branch that you currently have "checked out". You'll learn more about that in a bit. + +You can create a new branch with the `git branch` command, with an argument to specify the new branch's name: + +```sh +git branch feature +``` + +This creates a new branch named `feature`. Let's take a look at our branches again with `git branch`: + +```sh + feature +* main +``` + +We can now see our new branch, but we are still on the `main` branch. We need to switch to our new branch by "checking it out". When you check out a new branch, you're telling Git to load the files in the exact state they were in at that point. + +Let's check out our new branch with: + +```sh +git checkout feature +``` + +or + +```sh +git switch feature +``` + +And run `git branch` again to see: + +```sh +* feature + main +``` + +Notice that the asterisk has now moved to the branch you currently have "checked out". + +Often times when you create a new branch, you will want to check it out immediately. Instead of creating the branch and then checking it out using two commands, you can create and switch to a branch in one command with: + +```sh +git checkout -b feature +``` + +or + +```sh +git switch -c feature +``` + +So now we've created and checked out a new branch. This branch is a clone of the `main` branch, it has all the same code that `main` did at the time you created the branch. Now, we can add any code to this branch without affecting the `main` branch. We've essentially gotten off the highway to create a feature. If you check your `git status`, you would see something like this: + +```sh +On branch feature +nothing to commit, working tree clean +``` + +Create a new `feature.md` file by running this: + +```sh +echo "This is our new feature" > feature.md +``` + +And now the status will look like this: + +```sh +On branch feature +Untracked files: + (use "git add ..." to include in what will be committed) + feature.md + +nothing added to commit but untracked files present (use "git add" to track) +``` + +Next, it's time to commit your new feature. First, add the file to staging: + +```sh +git add feature.md +``` + +Then, commit the changes: + +```sh +git commit -m "my new feature" +``` + +Finally, push your `feature` branch to your repository: + +```sh +git push -u origin feature +``` + +The `-u` flag connects your local `feature` branch to the remote one, so future pushes can be done with just `git push`. + +Next, we will learn how to make a pull request for our new feature! + +# --questions-- + +## --text-- + +What does creating a new branch in Git allow you to do? + +## --answers-- + +Permanently delete the `main` branch. + +### --feedback-- + +You don't want to delete your `main` branch. + +--- + +Make changes without affecting the `main` branch. + +--- + +Share your code directly with GitHub users. + +### --feedback-- + +Sharing code involves pushing branches and possibly making pull requests. + +--- + +Change the Git version on your local machine. + +### --feedback-- + +Branches don't change the Git software version. + +## --video-solution-- + +2 + +## --text-- + +What does the `*` symbol next to a branch name in `git branch` output indicate? + +## --answers-- + +The branch is about to be deleted. + +### --feedback-- + +The asterisk indicates that the branch is "checked out". + +--- + +The branch is the oldest one in the repo. + +### --feedback-- + +The asterisk indicates that the branch is "checked out". + +--- + +The branch is being pushed to GitHub. + +### --feedback-- + +The asterisk indicates that the branch is "checked out". + +--- + +The branch is currently "checked out". + +## --video-solution-- + +4 + +## --text-- + +What does the following command do? + +```sh +git push -u origin feature +``` + +## --answers-- + +Deletes the `feature` branch from the remote repository. + +### --feedback-- + +This command doesn't remove anything. + +--- + +Pushes the `feature` branch and sets it to track the remote branch. + +--- + +Merges the feature branch into `main`. + +### --feedback-- + +Merging is a separate action not done with this command. + +--- + +Pushes all branches to the remote repository. + +### --feedback-- + +This command pushes only one specific branch. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md new file mode 100644 index 00000000000..aa791f4bd0e --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-introduction-to-git-and-github/688290da3736c273009129d0.md @@ -0,0 +1,178 @@ +--- +id: 688290da3736c273009129d0 +title: What Is a Pull Request, and How Do You Create One? +challengeType: 19 +dashedName: what-is-a-pull-request-and-how-do-you-create-one +--- + +# --description-- + +In the previous lecture, we created a feature branch, committed a new file to that branch, and pushed it up to our remote repository. But what are our next steps? We need to create a pull request on GitHub. + +A pull request is, effectively, a request to pull changes in from your branch into the target branch. Pull requests are the flow you use when you want to contribute code changes to an open source project. This approach allows the maintainers of the project to review your changes. They can leave comments, ask questions, suggest tweaks, and (hopefully) approve your changes and merge them in! + +Let's head over to our repository on GitHub again. + +Now, after you pushed your new branch, you should see a fancy banner that says you've pushed to a branch, and a button you can click to create a pull request. This button skips a couple of steps and streamlines the process, so we're going to ignore it for now. That way you are prepared for cases where the banner does not appear. + +Click on the pull requests tab at the top the repository page, then ignore the banner again and click "New Pull Request". You'll be taken to a UI to prepare your request. + +Now, there are some terms we need to go over here. First, we have the "base" and "compare" drop downs. The "base" is your target for the merge. Since we want to merge into `main`, we can leave this alone. + +The "compare" is what you want to merge. We want to merge our `feature` branch, so we should change this to `feature`. This is also known as the head branch, which is a term you will want to remember. + +Once you do this, the UI will refresh. It should now show the commits on `feature` that are not on `main`, indicating what you are requesting to merge in. You'll also see what's called a "diff", which is a visual representation of the actual changes you've made. + +Because all we've done is add a file, the diff is pretty clean. For more complex changes, GitHub will highlight things like line modifications, additions, deletions, and more. Understanding how to read a diff can be challenging, but with some practice you will become quite proficient at it. + +For now, let's go back to our pull request. There is a small link at the top that reads "compare across forks". If we were working from our fork of the freeCodeCamp repository, this would give us the ability to change our PR to target the original freeCodeCamp repo, instead of just the `main` branch within our fork. + +Since we are not working with a fork, we can ignore this. However, it is very important to understand that what we are doing here is primarily for learning and exploration. You shouldn't open a PR to someone's project that just contains practice changes - this creates extra noise for the maintainers. + +Now, since we are happy with our changes and everything is configured, we can click the "Create Pull Request" button. This takes us to a new UI. + +Toward the bottom and out of view are the same commit list and diff view we saw earlier. It never hurts to double check one last time before creating your PR, but for this exploration you are good to move forward. + +You'll also see a couple of new inputs. The first input is the title for your pull request. GitHub will automatically generate this based on the commit you are merging, if there is only one in the PR, or the branch name, if you have multiple commits. + +The second input is for your description. In most cases, this will not be empty. Instead, maintainers of a project can define a template which gets pre-populated. If they provide one, you should respect their workflow and complete the template. + +In both cases, you'll want to read the contributing documentation for the project to ensure you understand and follow their guidelines for how to title and fill out your PR. + +Since you own this repository, you'll see on the right that you can set reviewers, assigness, labels, projects, and milestones. You won't be able to edit these, except to request a review, when you contribute to someone else's project. But if you'd like to explore those features, you can set them however you like now since this is your repository. + +Once everything is filled out and configured, click "Create pull request". Finally, you'll see the actual result! + +When you make a pull request to someone else's project, it needs to go through a "code review". This is a process where the maintainers can evaluate your pull request, request changes, ask questions, and so on. Once the maintainers have approved it, they can merge it. + +Since this is your own project, you don't need to wait for a review. Instead, you can double check the commit history under the Commits tab, the changes under the Files changed, and if you are satisfied you can merge it. + +After it's merged, you will want to pull these changes to your local repo. + +Head back to your terminal, and make sure you are still in the repo's folder. Then switch to the `main` branch with `git checkout main`. + +Next, pull down the latest changes with `git pull`. + +Now, if you look at the commit history with `git log`, you will see your commit. But you will also see a `Merge pull request #1` message. What is that? + +Well, when you merge a pull request on GitHub there are three strategies you can use: + +The default is "Merge", which brings all of the commits from the head branch, then creates another commit to process and log the merge. + +Another option is "Squash and Merge", which takes ALL of the commits from the head branch, smashes them into a single commit, and merges that new commit directly into the base branch without creating a merge commit. + +Finally, there is "Rebase and Merge", which takes all of the commits, resets them to "come after" the latest commit on the base branch, then merges the head in without a merge commit. Rebasing is a complicated topic that you will learn about in depth later, so it's okay if you do not quite understand it today. + +Each open source project will choose whatever merge strategy works best. But because of these differences in behaviour, you should ALWAYS create a new branch to commit your contributions on. Never commit directly to the default `main` branch, or things will get messy when you need to bring the changes down from the original repo. + +With all of that, you have successfully created and merged your first pull request! + +# --questions-- + +## --text-- + +What is a pull request in GitHub? + +## --answers-- + +A way to force push code to the `main` branch. + +### --feedback-- + +Think about what you're asking project maintainers to do with your code changes. + +--- + +A request to pull changes from one branch into another branch. + +--- + +A way to directly edit files in the main repository. + +### --feedback-- + +Think about what you're asking project maintainers to do with your code changes. + +--- + +A tool for downloading repositories to your local machine. + +### --feedback-- + +Think about what you're asking project maintainers to do with your code changes. + +## --video-solution-- + +2 + +## --text-- + +In a pull request, what do the terms "base" and "compare" (or "head") refer to? + +## --answers-- + +"Base" is the source branch; "compare" is the target branch. + +### --feedback-- + +Consider which branch will receive changes and which branch contains the changes. + +--- + +"Base" is the target branch; "compare" is the source branch. + +--- + +"Base" is the fork; "compare" is the original repository. + +### --feedback-- + +Consider which branch will receive changes and which branch contains the changes. + +--- + +"Base" is the original repository; "compare" is the fork. + +### --feedback-- + +Consider which branch will receive changes and which branch contains the changes. + +## --video-solution-- + +2 + +## --text-- + +Which of the following is NOT a merge strategy mentioned when merging a pull request on GitHub? + +## --answers-- + +Merge + +### --feedback-- + +The lecture mentioned three specific strategies for handling commits during a merge. + +--- + +Squash and Merge + +### --feedback-- + +The lecture mentioned three specific strategies for handling commits during a merge. + +--- + +Rebase and Merge + +### --feedback-- + +The lecture mentioned three specific strategies for handling commits during a merge. + +--- + +Fork and Merge + +## --video-solution-- + +4 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688290ef85c79973321a23af.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688290ef85c79973321a23af.md new file mode 100644 index 00000000000..41214fcecd5 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688290ef85c79973321a23af.md @@ -0,0 +1,158 @@ +--- +id: 688290ef85c79973321a23af +title: What Does a Typical Code Review Process Look Like for Projects? +challengeType: 19 +dashedName: what-does-a-typical-code-review-process-look-like-for-projects +--- + +# --description-- + +In a previous lecture, you learned how to make a pull request to your own repository. You also learned how to merge that pull request. But you could only do that because the repository belongs to you - you have maintainer access to your own repositories, which means you have permission to merge pull requests. + +When you contribute to someone else's open source project, however, you typically won't have those permissions. Instead, you'll need to wait for the maintainers to go through the code review process and accept your contribution. They will then handle merging it. + +But what does the code review process look like? + +The process that maintainers take will vary from person to person, and there may be project-specific approaches. But in general, there are typically three steps to a code review. + +The first is to confirm that the CI, or continuous integrations, passes. You'll learn more about this in a future lecture, so for now you can think of them as checks to validate that the code meets style guidelines and passes a test suite. + +If the CI fails, maintainers will typically request that you update the pull request to address the failures. These failures should include some sort of report you can look at to see what went wrong, but maintainers may also provide you more specific guidance to resolve the issue. + +Once the checks pass, the maintainers will look at your actual code changes. They can analyze the diff view to see what you've modified, added, or deleted. They may ask questions about why you took specific approaches, so it's good to be deliberate and thoughtful when you are preparing conversations. + +They may also request you make additional modifications. We'll talk about what that looks like in a bit. + +The last step is usually to pull down your changes locally. The maintainers can then run the application with your modifications, test the functionality, and verify nothing is broken or behaving in unexpected ways. + +If everything looks good, a maintainer will approve your pull request - sometimes with a "LGTM" comment, which stands for "looks good to me". After your pull request has been approved, it should be merged whenever the maintainers are ready to pull the changes in. Some projects may require more than one approval - freeCodeCamp, for example, requires two. + +But what if something is not correct with your pull request? Maintainers can perform a review in which they request changes. These requests can come in a couple of forms. + +Sometimes, a maintainer may just leave a "comment" with their request, maybe indicating something you should change or update, but with more freedom of how you implement it. + +Or, maintainers may also leave an official "request changes" comment. Typically, a comment like this blocks the pull request from being merged. You'll need to make the desired changes, and then the same maintainer who requested the changes will need to re-review and request more changes or approve your work. + +When maintainers have specific changes in mind, they can actually propose changes through GitHub's UI. When they use a direct suggestion like this, GitHub will give you a button to commit the suggestion to your branch directly. However, if there are multiple suggestions like this, you'll want to switch to the files view. + +From this view, you can add all of the suggestions (one by one) into a "batch", and commit them all in one go. This is incredibly useful when there are many suggestions, as doing them individually would result in many commits. All of the CI checks would have to run on each and every commit, and this can slow down the process for accepting your PR. + +If the requested changes are significant, you will likely want to make the changes locally, commit them to the same branch that you used for the PR, and push them up. GitHub will automatically update your pull request to reflect the new commits. + +There are a couple of other notes that we want to cover. + +First, remember that maintainers are people too. Open source projects rarely generate enough revenue for maintainers to work on them full time, which means they have to keep a job. It is important to be patient with the review process - don't do things like ping maintainers repeatedly for a re-review, or try to rush them in their review process. + +Making contributions can be exciting! But don't rush through the process. Instead, take your time. Make sure to test your changes locally - run any test suites the project may have, run the development server and manually confirm that your changes work, etc. And always follow the contribution guidelines for the specific project you are working on. + +If you keep all of that in mind, and put your best effort forward, your contributions should go smoothly and your code review should be a solid approval! + +# --questions-- + +## --text-- + +What is typically the first step in a code review process? + +## --answers-- + +Looking at the actual code changes. + +### --feedback-- + +Think about what maintainers check before they even look at your code. + +--- + +Confirming that CI (continuous integration) passes. + +--- + +Pulling down the changes locally. + +### --feedback-- + +Think about what maintainers check before they even look at your code. + +--- + +Approving the pull request. + +### --feedback-- + +Think about what maintainers check before they even look at your code. + +## --video-solution-- + +2 + +## --text-- + +What does the acronym "LGTM" stand for in code reviews? + +## --answers-- + +Let's Get This Merged. + +### --feedback-- + +This is a common approval phrase mentioned in the lecture. + +--- + +Long-term Goal To Maintain. + +### --feedback-- + +This is a common approval phrase mentioned in the lecture. + +--- + +Looks Good To Me. + +--- + +Let's Go Through More. + +### --feedback-- + +This is a common approval phrase mentioned in the lecture. + +## --video-solution-- + +3 + +## --text-- + +When a maintainer proposes specific changes through GitHub's UI, what can you do to efficiently handle multiple suggestions? + +## --answers-- + +You must implement each suggestion manually in your local environment. + +### --feedback-- + +Think about the most efficient way to handle multiple suggestions without creating numerous commits. + +--- + +You can add all suggestions to a "batch" and commit them together. + +--- + +You need to create a new pull request for each suggestion. + +### --feedback-- + +Think about the most efficient way to handle multiple suggestions without creating numerous commits. + +--- + +You must accept each suggestion individually with separate commits. + +### --feedback-- + +Think about the most efficient way to handle multiple suggestions without creating numerous commits. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829101d909657350cd80af.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829101d909657350cd80af.md new file mode 100644 index 00000000000..22f67b4abfa --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829101d909657350cd80af.md @@ -0,0 +1,158 @@ +--- +id: 68829101d909657350cd80af +title: How Do You Use GitHub Pages to Deploy a Project? +challengeType: 19 +dashedName: how-do-you-use-github-pages-to-deploy-a-project +--- + +# --description-- + +GitHub Pages is a really solid option for deploying static sites, or applications that do not require a back-end server to handle logic. That is, applications that run entirely client-side, or in the user's browser, can be fully deployed on this platform. + +Additionally, GitHub Pages are completely free for open source projects. There are plenty of good reasons to make your project open source, and Pages adds yet another. + +But how do you actually deploy to GitHub Pages? Well, that depends on how your application works. + +Let's start with a basic HTML page. Here's one you can add to your existing repo if you'd like: + +```html + + + + freeCodeCamp + + + +

Welcome to freeCodeCamp's Lecture!

+

Let's have some fun learning about Git and GitHub!

+ + +``` + +Now we need to visit our repository and click the "Settings" tab to go to the repository settings. Then we need to select "Pages" from the sidebar. + +There's only a few options initially, but that's going to change as we start configuring the settings. First, we need to tell GitHub what to deploy from. + +We'll want to leave this as "Deploy from a branch", because we aren't using a framework and have not configured any GitHub actions at all. You'll learn more about what those are in an upcoming lecture. + +Next, set the branch that we are deploying from to `main` to deploy what's on that. + +You'll then get a choice to deploy from your project's root folder or from a `docs` folder. This feature is used by projects like freeCodeCamp - we used to bundle documentation with our app, so we could deploy just the documentation onto GitHub pages via the `docs` folder. For now, leave it as the `/` (root) folder and hit the "Save" button next to this drop down to save your changes. + +One you've saved, you'll see a new input to configure a custom domain. If you have one already, and would like to use it, you can follow the link to the docs to do so. For this lecture, however, we are going to leave this blank. + +You can also see the domain that your new GitHub Pages site has been deployed to. Without a custom domain, this defaults to `.github.io`, where `` is the name of your account (or the organization's account if you are deploying from an org-owned repository). And repository will be served on a path matching the repository's name, `.github.io/`, for instance. If you visit the URL, you will see your site! + +Now, when you push new changes to your `main` branch, GitHub Pages will automatically update our deployed site with the latest changes. This process can take a few minutes, depending on server load - and you may need to do a hard refresh to clear the cache. + +And with that, we have successfully deployed a basic web application to GitHub Pages. You can also include CSS and JavaScript files in your Pages deployment, so you can build beautiful and interactive sites. And once you learn a framework like React or Angular, you can even deploy those on GitHub Pages too! + +# --questions-- + +## --text-- + +What type of applications can be deployed on GitHub Pages? + +## --answers-- + +Only documentation websites. + +### --feedback-- + +Think about where the application logic runs - on a server or in the browser? + +--- + +Applications that require server-side processing. + +### --feedback-- + +Think about where the application logic runs - on a server or in the browser? + +--- + +Static sites and client-side applications. + +--- + +Database-driven applications. + +### --feedback-- + +Think about where the application logic runs - on a server or in the browser? + +## --video-solution-- + +3 + +## --text-- + +If your GitHub username is `johndoe` and your repository is named `my-portfolio`, what URL would your GitHub Pages site be deployed to? + +## --answers-- + +`johndoe.github.io` + +### --feedback-- + +Remember that repositories not matching the `username.github.io` pattern are served on a path. + +--- + +`my-portfolio.github.io` + +### --feedback-- + +Remember that repositories not matching the `username.github.io` pattern are served on a path. + +--- + +`github.io/johndoe/my-portfolio` + +### --feedback-- + +Remember that repositories not matching the `username.github.io` pattern are served on a path. + +--- + +`johndoe.github.io/my-portfolio` + +## --video-solution-- + +4 + +## --text-- + +When configuring GitHub Pages deployment, which of the following options do you need to specify? + +## --answers-- + +The programming language used. + +### --feedback-- + +Consider what GitHub needs to know to find and serve your static files. + +--- + +The branch to deploy from and the folder location. + +--- + +The server specifications. + +### --feedback-- + +Consider what GitHub needs to know to find and serve your static files. + +--- + +The database connection string. + +### --feedback-- + +Consider what GitHub needs to know to find and serve your static files. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829116a80ecd73681261b1.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829116a80ecd73681261b1.md new file mode 100644 index 00000000000..ca74eaa9c29 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829116a80ecd73681261b1.md @@ -0,0 +1,174 @@ +--- +id: 68829116a80ecd73681261b1 +title: What Are Good Practices for Remaining in Sync with Your Remote Counterparts? +challengeType: 19 +dashedName: what-are-good-practices-for-remaining-in-sync-with-your-remote-counterparts +--- + +# --description-- + +We've talked a bit about using branches to work on isolated changes to avoid soiling your `main` branch. But what does that mean, and why is it important? + +If you commit changes directly to your `main` branch, and the upstream repository accepts other changes that are not yours, you will end up with something called a "divergent history". This means that the commits on your `main` branch are no longer aligned with the commits on the upstream `main` branch. And it makes syncing the upstream changes a nightmare. + +So, let's say you've been following good branching practices, and this isn't an issue. If you followed along with our previous lectures, you should have a fork of a repository that you've cloned locally, and you should have an upstream remote that points to the original repository. + +If you did not do this, here's a quick reminder. You'll want to fork a repository, clone your fork locally, and run this command: + +```sh +git remote add upstream +``` + +Replace `` with the SSH URL for the original repository, NOT your fork. + +With a properly configured upstream, you can run the following series of commands to pull in the latest upstream changes: + +```sh +git checkout main +git fetch upstream +git merge upstream/main +``` + +What do these do? Well, you've learned about `git checkout`, so the first command ensures that you are on your `main` branch locally. + +The second command, `git fetch upstream`, tells Git to go get the latest changes that are on your upstream remote (which is the original repo). However, unlike a pull, Git will not automatically update your branch. This is important, because your `main` branch locally is connected to the `main` branch on your fork - not the `main` branch on the original repo! Performing a git pull may result in unexpected behavior. + +The final command, `git merge upstream/main`, tells Git to merge the latest changes from the `main` branch in the upstream remote into your current branch - which is your local `main` branch, because that's what we checked out. + +But what if the merge fails? What if you've accidentally committed to `main`, and Git cannot merge the divergent histories? Well... assuming you have not made any pull requests from your `main` branch, you can do a hard reset to force Git to update your branch. + +```sh +git reset --hard upstream/main +``` + +The `git reset` command allows you to reset the current state of a branch. Passing the `--hard` flag tells Git to force the local files to match the branch state. This ensures that you have a clean slate to work from. And passing `upstream/main` tells Git you want your current branch (which is `main`) to match the `main` branch of the upstream remote. Be cautious with this command - any time you forcibly update a Git history, weird and unfortunate things may happen. + +Once you've got your local `main` branch updated correctly, it's important to push that state up to your remote fork (which should be `origin`, if you have followed our lectures). To do this, you can run: + +```sh +git push +``` + +This will push the current state up to your remote fork. But if you've had to do a hard reset to clean up the history, it's possible your remote fork also has a divergent history and the push will fail. + +You can rectify that by forcing the push: + +```sh +git push --force +``` + +**Be careful with this command**. Doing a force push effectively rewrites your remote history, and if you've done something incorrectly then a forced push becomes a nightmare to untangle. + +Pushing the synced changes up to your remote fork is important because it helps you ensure that you can safely clone the fork with the latest changes if you've lost your existing local repository. + +And once you've got your `main` branch synced, you are free to create a new branch from that state to start working on another contribution - with the latest version of the original codebase! + +# --questions-- + +## --text-- + +What's the main reason you should avoid committing changes directly to your `main` branch when working with forked repositories? + +## --answers-- + +It creates duplicate commits. + +### --feedback-- + +Think about what happens when your branch and the original repository evolve separately. + +--- + +It causes a "divergent history" making it difficult to sync with upstream. + +--- + +Git doesn't allow commits to the main branch. + +### --feedback-- + +Think about what happens when your branch and the original repository evolve separately. + +--- + +It automatically deletes your local changes. + +### --feedback-- + +Think about what happens when your branch and the original repository evolve separately. + +## --video-solution-- + +2 + +## --text-- + +Which series of commands will correctly update your local `main` branch with changes from the original repository? + +## --answers-- + +`git checkout main`; `git pull upstream` + +### --feedback-- + +Consider the step-by-step process needed to get upstream changes without disrupting your fork. + +--- + +`git pull upstream main` + +### --feedback-- + +Consider the step-by-step process needed to get upstream changes without disrupting your fork. + +--- + +`git checkout main`; `git fetch upstream`; `git merge upstream/main` + +--- + +`git fetch upstream/main`; `git merge` + +### --feedback-- + +Consider the step-by-step process needed to get upstream changes without disrupting your fork. + +## --video-solution-- + +3 + +## --text-- + +If you've accidentally committed to your `main` branch and can't merge upstream changes, what command can you use to forcibly reset your `main` branch to match the upstream (assuming you haven't made any pull requests)? + +## --answers-- + +`git checkout upstream/main` + +### --feedback-- + +Which command completely resets your branch to match another branch's state? + +--- + +`git reset --hard upstream/main` + +--- + +`git rebase upstream/main` + +### --feedback-- + +Which command completely resets your branch to match another branch's state? + +--- + +`git clean upstream/main` + +### --feedback-- + +Which command completely resets your branch to match another branch's state? + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882913b2b58c2738eaaa2d1.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882913b2b58c2738eaaa2d1.md new file mode 100644 index 00000000000..bee9635e7a7 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882913b2b58c2738eaaa2d1.md @@ -0,0 +1,264 @@ +--- +id: 6882913b2b58c2738eaaa2d1 +title: What Is a .gitignore File, and What Are Some Items That Should Be Included Inside It? +challengeType: 19 +dashedName: what-is-a-gitignore-file-and-what-are-some-items-that-should-be-included-inside-it +--- + +# --description-- + +We have briefly touched upon the `.gitignore` file in a previous lecture. But what exactly is this file, and what should you put in it? + +The `.gitignore` file is a special type of file related to Git operations. The name suggests that this file is used to tell Git to ignore things, and that's the common use case. But what it actually does is it tells Git to stop tracking a file. This distinction is important, and will be clarified later. + +What should you actually put in this file? Well, you should list things that you don't want committed. + +The first would be your secrets files. This may be something like a `.env` file, where you've stored your API keys for your application to consume. It may be a private GPG key file that your app needs to use for authentication. Anything that contains sensitive information you would not want leaked to the public should be ignored with `.gitignore`. Even if your repository is private, you should act as if it is public - treat it like anyone can see it, and take care not to commit secrets. + +Let's take a look at what our file might look like right now: + +```sh +# Secrets +.env +github.key +``` + +We've told Git to ignore the `.env` file, where we are keeping our secrets. We've also told Git to ignore a `github.key` file, which contains a private GPG key. + +The next thing to consider are the packages, or dependencies, that your project uses. As an example, when you are working with a Node.js project, you probably install packages from npm. These packages go into a `node_modules` folder in your project, so your code can import and consume them. + +But the `node_modules` folder gets prohibitively massive, and you definitely don't want to commit all of those packages and track the changes each time you update one. Instead, you commit your `package.json` file, and the relevant lockfile (e.g. `package-lock.json`, `pnpm-lock.yaml`). These files tell npm what packages and versions to install, so a contributor can install the same dependencies you are using without having to commit them to the repository. + +Let's go ahead and add `node_modules` to our `.gitignore` file: + +```sh +# Secrets +.env +github.key + +# Packages +node_modules +``` + +Now, let's touch on an important syntax thing for `.gitignore` files. When you add an entry like `node_modules`, Git will ignore anything that matches that pattern. This means it will ignore the `node_modules` directory in the root of your project, but would also ignore the `node_modules` in the `client` directory of your project. + +If you only want to ignore something at the root, you can prefix the line with a forward slash. `node_modules` would become `/node_modules`. This would ignore the root `node_modules` directory, but not the `client/node_modules` directory. We do not want that, so let's leave our entry as just `node_modules`. + +The next thing you want to consider ignoring are your build outputs. For example, compiling a TypeScript project might result in a `dist` folder for the JavaScript output. You don't want to commit that output, because it bloats the Git history. Instead, you want to ignore that output - contributors can reproduce it for themselves by running the same build command. + +Let's go ahead and ignore the `dist` folder: + +```sh +# Secrets +.env +github.key + +# Packages +node_modules + +# Outputs +dist +``` + +Sometimes, a misplaced file can cause the TypeScript compiler to break, which results in our JavaScript output ending up all over the place. Since we are exclusively writing TypeScript, let's go ahead and use glob syntax to ignore all JavaScript files: + +```sh +# Secrets +.env +github.key + +# Packages +node_modules + +# Outputs +dist +*.js +``` + +Some other common outputs you might ignore are the `coverage` directory, for the results of unit test coverage, an `.angular` directory if you are using Angular, a `.next` directory if you are using NextJS, and so on. + +For now, we can stick with what we have here. If you're using a framework that generates files, you should confirm in their documentation what you need to add to the `.gitignore`. + +The fourth batch of things to ignore are IDE files. Jetbrains products, for example, might use an `.idea` folder for IDE-specific configurations. Visual Studio Code uses a `.vscode` folder. + +These are often good to ignore, because they'll contain files specific to your local environment that other contributors won't need (because they use their own configurations). Let's go ahead and add the Visual Studio Code directory, since that is what we are using as our IDE. + +```sh +# Secrets +.env +github.key + +# Packages +node_modules + +# Outputs +dist +*.js + +# IDE +.vscode +``` + +But our `.vscode` folder does contain a `settings.json` file, which includes some workspace-specific stuff that might be useful for our contributors - this file allows them to configure their extensions and environment to better mirror our own. + +So let's go ahead and use negation syntax to "unignore" that file: + +```sh +# Secrets +.env +github.key + +# Packages +node_modules + +# Outputs +dist +*.js + +# IDE +.vscode +!.vscode/settings.json +``` + +If you are on MacOS, you may be familiar with the `.DS_STORE` file. This file contains metadata that Finder uses to determine things like how to render the directory (e.g. with thumbnails, or as a list). Similarly, Windows users might see a hidden `Thumbs.db` file, which caches thumbnails for the directory. + +It's generally a good idea to ignore these files, since they're a personal setting that have no impact on the project. Let's add both of them: + +```sh +# Secrets +.env +github.key + +# Packages +node_modules + +# Outputs +dist +*.js + +# IDE +.vscode +!.vscode/settings.json + +# System Files +.DS_STORE +Thumbs.db +``` + +A quick note about ignoring previously committed files. Say you've accidentally committed your `dist` directory earlier, but now you want to remove it and ignore it. You cannot just add it to your `.gitignore` file - this does not make previously committed content disappear, it tells Git to stop tracking the file. So if you ignore a file that's already committed, Git won't track any changes but it also won't track the deletion of the file. + +Instead, you'll first need to delete the file. Create a commit with that deletion. Then you can add the item to your `.gitignore` and create a second commit with that update. Going forward, when that file is created again, Git will ignore it and it won't show up in your commits. + +Finally, if you're working on a project in a different language, such as Python, the items you need to ignore will be different than what we've covered here. GitHub maintains a very helpful repository of `.gitignore` templates for various languages and frameworks. You can find that list at https://github.com/github/gitignore. + +With that, you're now ready to avoid committing files you don't want in your repositories! + +# --questions-- + +## --text-- + +What is the primary purpose of a `.gitignore` file? + +## --answers-- + +To delete files from your repository. + +### --feedback-- + +Think about what the `.gitignore` file prevents from happening during Git operations. + +--- + +To tell Git to stop tracking specific files. + +--- + +To encrypt sensitive data in your repository. + +### --feedback-- + +Think about what the `.gitignore` file prevents from happening during Git operations. + +--- + +To compress large files before committing them. + +### --feedback-- + +Think about what the `.gitignore` file prevents from happening during Git operations. + +## --video-solution-- + +2 + +## --text-- + +If you've already committed a file to Git and later add it to `.gitignore`, what will happen? + +## --answers-- + +The file will be automatically deleted from the repository. + +### --feedback-- + +Consider what the lecture said about ignoring previously committed files. + +--- + +The file will remain in the repository but future changes won't be tracked. + +--- + +Git will throw an error until you resolve the conflict. + +### --feedback-- + +Consider what the lecture said about ignoring previously committed files. + +--- + +The file will be hidden but still tracked by Git. + +### --feedback-- + +Consider what the lecture said about ignoring previously committed files. + +## --video-solution-- + +2 + +## --text-- + +What syntax would you use in a `.gitignore` file to ignore all files in a directory, but then make an exception for one specific file? + +## --answers-- + +Use glob wildcards (`*`) and then negate (`!`) the specific file. + +--- + +Use comments (`#`) to manually specify exceptions. + +### --feedback-- + +Remember the example with the `.vscode` directory and `settings.json` file. + +--- + +Use a slash (`/`) to indicate directory structures. + +### --feedback-- + +Remember the example with the `.vscode` directory and `settings.json` file. + +--- + +Use brackets (`[]`) to create pattern exclusions. + +### --feedback-- + +Remember the example with the `.vscode` directory and `settings.json` file. + +## --video-solution-- + +1 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882915386c73273ac489f38.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882915386c73273ac489f38.md new file mode 100644 index 00000000000..991ddb91d31 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/6882915386c73273ac489f38.md @@ -0,0 +1,148 @@ +--- +id: 6882915386c73273ac489f38 +title: What Are Some Best Practices for Developing a Git Branching Strategy? +challengeType: 19 +dashedName: what-are-some-best-practices-for-developing-a-git-branching-strategy +--- + +# --description-- + +We've talked a bit about branches in the previous lectures. You've learned how to create branches, why you shouldn't commit directly to `main`, and similar. But when and why should you actually create branches? + +First, let's talk about why you shouldn't just push a bunch of commits to `main`. Your default branch should be reliably stable - that is, at any given time I should be able to pull down your current `main` branch and build, run, and test your application. If you are pushing up partially completed features, or WIP commits, then this may not always be true. + +Additionally, it is very common to work on multiple features in tandem. If you're pushing partial work to `main` for multiple features simultaneously, it becomes much more challenging to debug a potential issue since you do not have isolated changes. On top of that, context switching (or changing which tasks you are working on) is nowhere near as clean. + +So when should you create a branch? A general rule of thumb is to create a branch for every isolated unit of work. That is, if you are working on a new OAuth feature, that work should be on a dedicated branch. If you then need to fix a bug in your password authentication, that work should be on its own dedicated branch. Need to redesign the user profile page? That's another branch. + +Note that you should always create your branches off of `main`. So, if you are working on a branch for your OAuth feature, you would checkout `main` before creating a new branch for your password authentication fix. Otherwise, if you create a branch for the password fix directly from your OAuth branch, you'll end up with the commits from your OAuth work and the history will be muddied. + +But how should you name your branches? Well, that's entirely up to you (or the project you are contributing to), but here are a few common conventions: + +`scope/description` - where `scope` is something like `feat` or `fix`, and `description` is a very short explanation of the branch's changes. For example: `feat/oauth-support`. + +`scope/issue/description` - similar to the previous convention, but including the number associated with the related issue. For example: `fix/25/password-auth`. + +`username/scope/description` - For projects where you all work off of branches in the original repository instead of forking it (this is common with private internal repositories), it can be helpful to include your username at the start of the branch. For example: `naomi-lgbt/feat/profile-redesign`. + +Let's cover a few other notes about branching strategies. + +For long-lived feature work, such as a beta feature that requires significant developer-hours, you may want to use a feature flag to selectively enable the logic rather than a branch. The longer a branch remains unmerged, the more likely you are to encounter conflicts. + +You may, however, wish to maintain dedicated branches for deployment environments or releases. For example, the freeCodeCamp repository uses `prod-staging` and `prod-current` to trigger deployments to staging and production servers, respectively. This can free up the team to iterate faster, merging as things are ready and approved without having to trigger a deployment for every merge. Instead, deployments are created by merging the latest `main` into those production branches. + +You may also want to maintain "release branches", or branches that represent a major version of your product. This allows you to have a clean state for each major release, so if you need to backport a critical security patch to an earlier release version you can do so without having to include any of the new version's changes. + +And finally, you should avoid merging your branches into `main` using the local CLI. Instead, create a pull request with your changes and merge through that flow. This gives you a chance to ensure any tests pass in your CI (which you will learn about in a future lecture), and to double check the diff view to make sure you have included only the changes you want merged. + +With these tips, you can start branching your way to success! + +# --questions-- + +## --text-- + +Why should you avoid committing directly to the `main` branch? + +## --answers-- + +Because Git doesn't allow direct commits to `main`. + +### --feedback-- + +Think about the stability and reliability requirements of the default branch. + +--- + +Because the `main` branch should remain reliably stable at all times. + +--- + +Because commits to `main` are permanently locked and can't be changed. + +### --feedback-- + +Think about the stability and reliability requirements of the default branch. + +--- + +Because `main` branches have slower performance than feature branches. + +### --feedback-- + +Think about the stability and reliability requirements of the default branch. + +## --video-solution-- + +2 + +## --text-- + +Which of the following is a best practice when creating a new branch? + +## --answers-- + +Create new branches from your current feature branch. + +### --feedback-- + +Think about keeping branch histories clean and avoiding unintended code inclusion. + +--- + +Always create new branches from `main`. + +--- + +Only create branches for major features. + +### --feedback-- + +Think about keeping branch histories clean and avoiding unintended code inclusion. + +--- + +Limit yourself to one branch per week. + +### --feedback-- + +Think about keeping branch histories clean and avoiding unintended code inclusion. + +## --video-solution-- + +2 + +## --text-- + +What is a recommended approach for handling long-lived feature work? + +## --answers-- + +Create one massive branch that contains all related work. + +### --feedback-- + +Consider the potential for merge conflicts with branches that remain unmerged for long periods. + +--- + +Use feature flags rather than long-lived branches. + +--- + +Always merge directly to `main` using the local CLI. + +### --feedback-- + +Consider the potential for merge conflicts with branches that remain unmerged for long periods. + +--- + +Create a new repository for each major feature. + +### --feedback-- + +Consider the potential for merge conflicts with branches that remain unmerged for long periods. + +## --video-solution-- + +2 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829162a7f96d73c8505d3d.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829162a7f96d73c8505d3d.md new file mode 100644 index 00000000000..2ad81b779fd --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/68829162a7f96d73c8505d3d.md @@ -0,0 +1,212 @@ +--- +id: 68829162a7f96d73c8505d3d +title: What Are Merge Conflicts, and How Can You Resolve Them? +challengeType: 19 +dashedName: what-are-merge-conflicts-and-how-can-you-resolve-them +--- + +# --description-- + +If you've been around experienced developers, whether in an online community or in person, you have probably heard about the "dreaded merge conflicts". But what exactly are they? + +Well, when you are using a proper branching strategy like we've discussed in previous lectures, you may be working on two different features on two different branches at the same time. Or maybe you're working on something, and a colleague is working on another branch. Either way, you have two independent changes going on. But sometimes, both of those branches will edit the same file. And if the other branch gets merged into `main` first, your branch's changes are now behind. + +Most of the time, this can be fixed by merging `main` back into your feature branch. But when the changes from the other branch conflict with your branch, Git cannot tell which changes you want to keep during a merge. This is called a "merge conflict". + +But how can you fix it? Well, for smaller and simpler conflicts, GitHub will give you a web UI to fix it. A "Resolve conflicts" button will show up at the bottom of a PR if there's conflicts. If you click it, you will see the file with conflicts that includes your code and the conflicting code. Git will add "merge conflict markers" around your code and the conflicting code to help identify the issue. It looks something like this: + +```sh +1 <<<<<<< feat/conflict +2 Here's some code from my first PR :) +3 ======= +4 Here's some code that was merged to main that conflicts with the code on my PR +5 >>>>>>> main +``` + +The opening marker is the `<<<<<<< feat/conflict`, and indicates the start of the changes that our current branch is making. Then we see the `Here's some code from my first PR :)`. After that is the `=======` marker, which indicates the end of our changes and the start of the `main` branch's changes. We can see that the changes made on `main` are the line `Here's some code that was merged to main that conflicts with the code on my PR`. And after that is the closing `>>>>>> main` marker to show the end of the conflicts. + +But how do we fix it? Well, you need to decide which changes you want to keep as part of the merge conflicts. If you want to keep both changes, you could remove just the conflict markers and leave the changes unchanged. Alternatively, if you want to keep the changes from only one branch, you would delete the conflict markers and the changes from the other branch (those that you do not wish to keep). And finally, if you don't like any of the changes at all, you can remove everything from the opening marker to the closing marker (inclusive). + +Let's remove the `main` branch changes, but keep ours. Here's what we have now: + +```sh +1 Here's some code from my first PR :) +``` + +Click the "Mark as resolved" button, which tells GitHub you are satisfied with your resolution. If there were additional files, GitHub would switch to the next one. But since this is our only conflicted file, you'll see a "Commit merge" button appear. Click that button and GitHub will create a merge commit for you. You'll be taken back to the pull request, where you'll see your new merge commit and the conflicts resolved. And we're all set! + +But what if you can't edit the conflicts directly on GitHub, because they are too complex? + +Well, if your branch has few commits, or only a couple of commits modify that file, you may be able to merge `main` into your branch: + +```sh +git checkout feat/conflict +git fetch origin +git merge origin/main +``` + +As Git processes this merge, you'll get conflicts to resolve manually. Git will notify you of which files need to be fixed. When we open the files with conflicts in our editor, we get the same conflict markers, with some helpful UI additions thanks to VSCode. Go ahead and fix the conflicts in the file in the same way. But this time, we'll need to manually create the commit. It's the same as creating any other commit: + +```sh +git add . +git commit -m "chore: resolve conflicts" +``` + +After running these commands, we can see Git has accepted our resolution. + +Sometimes, when you have many commits or conflicts, a rebase can be helpful. Instead of merging changes, a rebase takes all the commits on your branch and reapplies them so they come after the latest changes on `main`. In Git terms, this effectively "resets" the base of your branch to the most recent commit on `main`. + +In order to experiment with this, we need a new branch: + +```sh +git checkout main +git pull +git checkout -b feat/rebase +``` + +Let's go ahead and generate a bunch of commits for our branch, so we can practice rebasing: + +```sh +echo "change one" > README.md +git add . +git commit -m "change one" +echo "change two" > README.md +git add . +git commit -m "change two" +echo "change three" > README.md +git add . +git commit -m "change three" +``` + +Now, let's go make another change on `main` to create a conflict: + +```sh +git checkout main +echo "change four" > README.md +git add . +git commit -m "change four" +``` + +And checkout our rebase branch: + +```sh +git checkout feat/rebase +``` + +Next, run `git rebase -i main`. It will rebase our branch onto the current state of the `main` branch. The `-i` flag tells Git to perform a rebase in interactive mode. You will see your commits with the word `pick` next to them. `pick` tells Git to use the commit as-is for the rebase. Save and close the file, and we'll get an error message telling us there is conflicts. + +Our `change one` commit conflicts with the `change four` commit, and we need to resolve that. Open the file in your editor, and you'll see the same UI as we got with the conflicts earlier. Let's keep our `change one` changes. Then, you'll need to run `git add .` to add the changes, and `git rebase --continue` to tell Git we're ready to continue rebasing. Since we've resolved the conflict in the first commit, Git can automatically handle rebasing the rest of the commits. + +Now, just as a last bit of cleanup, let's squash our three change commits into one single commit for a cleaner history. Run `git rebase -i main` again to get to the editor. Then, leave the first command as `pick` but change the next two to `squash`. You may run in to the same conflict again. If you do, resolve it the same way you did before. Once you've resolved and continued the rebase (or immediately, if you had no conflict), you'll see a new commit message editor pop up. This message will be your new commit, containing the changes from the three commits we've squashed. Let's name this one `change three complete`. Save and close the editor, and Git will finalize the rebase. + +If we check your commit history now, we can see that we now have our single `change three complete` commit, and it's correctly based on the `change four` commit. That means you've successfully completed a rebase with squashed commits! And now you've got the tools you need to become a merge conflict champion! + +# --questions-- + +## --text-- + +What are the merge conflict markers that Git adds to help identify conflicting changes? + +## --answers-- + +`<<< current branch`, `=== separator`, `>>> other branch` + +### --feedback-- + +Think about the specific syntax Git uses to mark the beginning, middle, and end of conflicts. + +--- + +`[[ current branch`, `|| separator`, `]] other branch` + +### --feedback-- + +Think about the specific syntax Git uses to mark the beginning, middle, and end of conflicts. + +--- + +`<<<<<<< current branch`, `======= separator`, `>>>>>>> other branch` + +--- + +`--- current branch`, `+++ separator`, `--- other branch` + +### --feedback-- + +Think about the specific syntax Git uses to mark the beginning, middle, and end of conflicts. + +## --video-solution-- + +3 + +## --text-- + +After manually resolving a merge conflict in your local repository, what commands do you need to run to complete the merge? + +## --answers-- + +`git push origin main` and `git rebase -i origin/main` + +### --feedback-- + +After fixing conflicts, you need to stage and commit the resolved changes just like any other commit. + +--- + +`git add` and `git commit` + +--- + +`git merge --abort` and `git commit` + +### --feedback-- + +After fixing conflicts, you need to stage and commit the resolved changes just like any other commit. + +--- + +`git reset --hard` and `git push -f` + +### --feedback-- + +After fixing conflicts, you need to stage and commit the resolved changes just like any other commit. + +## --video-solution-- + +2 + +## --text-- + +What is the main difference between merging and rebasing when dealing with branch conflicts? + +## --answers-- + +Merging creates a new commit, while rebasing rewrites history to place your commits after the other branch's commits. + +--- + +Rebasing is faster than merging. + +### --feedback-- + +Consider how each operation affects the commit history. + +--- + +Merging can only be done on GitHub, rebasing must be done locally. + +### --feedback-- + +Consider how each operation affects the commit history. + +--- + +There is no difference, they are the same operation. + +### --feedback-- + +Consider how each operation affects the commit history. + +## --video-solution-- + +1 diff --git a/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688291b65db00473e1136725.md b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688291b65db00473e1136725.md new file mode 100644 index 00000000000..ba8c728cee2 --- /dev/null +++ b/curriculum/challenges/english/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd/688291b65db00473e1136725.md @@ -0,0 +1,238 @@ +--- +id: 688291b65db00473e1136725 +title: What Is CI/CD, and How Does CI Work with GitHub Actions? +challengeType: 19 +dashedName: what-is-ci-cd-and-how-does-ci-work-with-github-actions +--- + +# --description-- + +CI stands for Continuous Integration, and CD stands for Continuous Delivery or Continuous Deployment. Together, these processes allow you to automatically deploy changes to your application after ensuring those changes are functional. + +In a CI pipeline, you might run your linter and tests against the code. CI pipelines typically run on pull requests to ensure the changes made aren't breaking the app, and also on the `main` branch to ensure it is ready to deploy. + +A CD pipeline might also run on pull requests, if you set up a preview environment so you can look at the changes live. But you'll also run it on your `main` branch to continuously deploy changes as they are accepted and merged. + +But how do these actually work with GitHub Actions? First, we need to understand what GitHub Actions actually are. GitHub Actions provides ephemeral runners (think like a temporary computer) that allows you to execute specific commands. + +Actions are configured with a YAML file. You can have multiple files to specify different actions to run. For example, you might have one file for your CI and another for your CD. + +Let's take a look at a basic CI example: + +```yml +name: Node.js CI +on: + push: + branches: + - main + pull_request: + branches: + - main + +jobs: + lint: + name: Lint and Test + runs-on: ubuntu-latest + + steps: + - name: Checkout Source Files + uses: actions/checkout@v4 + + - name: Use Node.js v22 + uses: actions/setup-node@v4 + with: + node-version: 22 + + - name: Setup pnpm + uses: pnpm/action-setup@v2 + with: + version: 10 + + - name: Install Dependencies + run: pnpm install + + - name: Lint Source Files + run: pnpm run lint + + - name: Verify Build + run: pnpm run build + + - name: Run Tests + run: pnpm run test +``` + +This is a lot, so let's break it down. Looking at the first section: + +```yml +name: Node.js CI +on: + push: + branches: + - main + pull_request: + branches: + - main +``` + +The `name` defines the name of the action itself. This appears in areas like the status checks section of a PR. The `on` properties define what's called "workflow triggers" - these are the events that will trigger your action to run. + +In this example, we run the action when commits are pushed to `main`, and when a pull request targets `main`. This means the CI runs when someone makes a pull request, and again when we merge it. + +The `jobs` section is where you define what your action actually does. The `lint:` key is an arbitrary key that defines the internal name for that job. The `name` property defines the external name for this particular job. And the `runs-on` property defines what kind of environment your action should run in - for this case, we're running it in the latest supported version of Ubuntu. + +The `steps` property is where the magic happens. This block defines the actual steps your action should take. Let's take a look at the first block there: + +```yml + - name: Checkout Source Files + uses: actions/checkout@v4 +``` + +This step has two properties, the `name` the step should have, and a `uses` property. This `uses` property is special, in that it tells the action runner to go get a public action from GitHub and run it, instead of running a command. The `actions/checkout` action handles cloning and setting up the repository within your runner. + +```yml + - name: Use Node.js v22 + uses: actions/setup-node@v4 + with: + node-version: 22 + + - name: Setup pnpm + uses: pnpm/action-setup@v2 + with: + version: 10 +``` + +The next two blocks also use third-party actions. These steps set up Node and the pnpm package manager. Both of them have a `with` key, which you can use to pass arguments to those third party actions. Think of this as like passing arguments to a function. + +The final four blocks are where the magic really happens. + +```yml + - name: Install Dependencies + run: pnpm install + + - name: Lint Source Files + run: pnpm run lint + + - name: Verify Build + run: pnpm run build + + - name: Run Tests + run: pnpm run test +``` + +We have an `Install Dependencies` block, which installs the npm packages. Our `Lint Source Files` block runs the linter, the `Verify Build` block ensures that the Typescript code can compile, and the `Run Tests` block runs the unit tests. + +The important thing to know about actions is, by default, if one of these steps fails the remaining ones will be skipped and the entire run will be marked as a failure. + +Where do you put your YAML files so you can run these actions? They need to go in a `.github/workflows` directory in your repository for GitHub to find and consume them. + +There are a lot of additional things actions can do, and I encourage you to read the documentation and explore existing actions in projects like the freeCodeCamp repository. But for now, you should have a decent understanding of the basics of GitHub Actions and CI/CD! + +# --questions-- + +## --text-- + +What does the on property define in a GitHub Actions workflow file? + +## --answers-- + +The name of the action. + +### --feedback-- + +Think about when you want your actions to automatically run. + +--- + +The events that trigger the workflow to run. + +--- + +The operating system to run on. + +### --feedback-- + +Think about when you want your actions to automatically run. + +--- + +The steps to execute. + +### --feedback-- + +Think about when you want your actions to automatically run. + +## --video-solution-- + +2 + +## --text-- + +Where should GitHub Actions workflow YAML files be placed in a repository? + +## --answers-- + +In the root directory. + +### --feedback-- + +GitHub looks for workflow files in a specific directory structure. + +--- + +In a `.github/actions` directory. + +### --feedback-- + +GitHub looks for workflow files in a specific directory structure. + +--- + +In a `.github/workflows` directory. + +--- + +In a `workflows` directory. + +### --feedback-- + +GitHub looks for workflow files in a specific directory structure. + +## --video-solution-- + +3 + +## --text-- + +What happens by default when a step fails in a GitHub Actions workflow? + +## --answers-- + +The workflow continues with a warning. + +### --feedback-- + +Consider how GitHub Actions handles errors in the workflow execution. + +--- + +Only that specific step is marked as failed. + +### --feedback-- + +Consider how GitHub Actions handles errors in the workflow execution. + +--- + +The workflow restarts from the beginning. + +### --feedback-- + +Consider how GitHub Actions handles errors in the workflow execution. + +--- + +Remaining steps are skipped and the run is marked as a failure. + +## --video-solution-- + +4 diff --git a/curriculum/structure/blocks/lecture-introduction-to-git-and-github.json b/curriculum/structure/blocks/lecture-introduction-to-git-and-github.json new file mode 100644 index 00000000000..a8097c3ce7b --- /dev/null +++ b/curriculum/structure/blocks/lecture-introduction-to-git-and-github.json @@ -0,0 +1,46 @@ +{ + "name": "Introduction to Git and GitHub", + "blockType": "lecture", + "blockLayout": "challenge-list", + "isUpcomingChange": true, + "dashedName": "lecture-introduction-to-git-and-github", + "helpCategory": "Backend Development", + "challengeOrder": [ + { + "id": "68828e965f70137025ec5031", + "title": "What Is Version Control, and Why Are These Systems Necessary?" + }, + { + "id": "688290189fecfe7206d22833", + "title": "What Is the Purpose of Sites Like GitHub and GitLab, and What Are Some Benefits of Using Them?" + }, + { + "id": "6882902bc844b1723da7eb13", + "title": "How Do You Install and Set Up Git?" + }, + { + "id": "68829061f03543726ea6f318", + "title": "What Is a Repository, and How Do You Create One?" + }, + { + "id": "6882904fd7063f7258c0aef3", + "title": "How Do You Handle Security Requirements Like SSH and GPG Keys?" + }, + { + "id": "68829079ab2abe728a822cc1", + "title": "How Do You Push a Local Repository to GitHub?" + }, + { + "id": "688290b7f7f46f72d3d4e73d", + "title": "How Do You Contribute to Other People's Repositories?" + }, + { + "id": "688290c998562972e953d34d", + "title": "How Do You Create a New Branch for Your Repository?" + }, + { + "id": "688290da3736c273009129d0", + "title": "What Is a Pull Request, and How Do You Create One?" + } + ] +} diff --git a/curriculum/structure/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd.json b/curriculum/structure/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd.json new file mode 100644 index 00000000000..3ad16709470 --- /dev/null +++ b/curriculum/structure/blocks/lecture-working-with-code-reviews-branching-deployment-and-ci-cd.json @@ -0,0 +1,38 @@ +{ + "name": "Working With Code Reviews, Branching, Deployment, and CI/CD", + "blockType": "lecture", + "blockLayout": "challenge-list", + "isUpcomingChange": true, + "dashedName": "lecture-working-with-code-reviews-branching-deployment-and-ci-cd", + "helpCategory": "Backend Development", + "challengeOrder": [ + { + "id": "688290ef85c79973321a23af", + "title": "What Does a Typical Code Review Process Look Like for Projects?" + }, + { + "id": "68829101d909657350cd80af", + "title": "How Do You Use GitHub Pages to Deploy a Project?" + }, + { + "id": "68829116a80ecd73681261b1", + "title": "What Are Good Practices for Remaining in Sync with Your Remote Counterparts?" + }, + { + "id": "6882913b2b58c2738eaaa2d1", + "title": "What Is a .gitignore File, and What Are Some Items That Should Be Included Inside It?" + }, + { + "id": "6882915386c73273ac489f38", + "title": "What Are Some Best Practices for Developing a Git Branching Strategy?" + }, + { + "id": "68829162a7f96d73c8505d3d", + "title": "What Are Merge Conflicts, and How Can You Resolve Them?" + }, + { + "id": "688291b65db00473e1136725", + "title": "What Is CI/CD, and How Does CI Work with GitHub Actions?" + } + ] +} diff --git a/curriculum/structure/superblocks/full-stack-developer.json b/curriculum/structure/superblocks/full-stack-developer.json index 74ffab7b5f7..154192a1ddc 100644 --- a/curriculum/structure/superblocks/full-stack-developer.json +++ b/curriculum/structure/superblocks/full-stack-developer.json @@ -820,6 +820,8 @@ "blocks": [ "lecture-working-with-nano", "workshop-castle", + "lecture-introduction-to-git-and-github", + "lecture-working-with-code-reviews-branching-deployment-and-ci-cd", "workshop-sql-reference-object", "lab-periodic-table-database", "lab-number-guessing-game",