Are your instructions consistent with the following lesson?

Using Git In The Real World
Ruby Course
Introduction
Git basics are very simple, but it sometimes feels like a bottomless pit when you find yourself on the wrong side of a confusing error situation. It’s doubly frustrating because you think that messing up or trying the wrong solution can lose data. It’s actually very hard to “lose” data with Git but it can certainly be hiding somewhere you wouldn’t think to look without an experienced dev poking around.

The thing about Git is that, unless you’ve got a seriously impressive memory, you can’t just learn it by reading about it up front… you need to do it. Find a problem you want to go back and fix, hit an error in your merge, etc. and Google the hell out of it, learning a new Git tactic in the process.

To help you out, come back and refer to this lesson again when you’re in trouble. We’ll first cover a real-world example of a GitHub workflow used on this very project. The Additional Resources section below should also help you find high quality resources for when you need them later on.

Lesson Overview
This section contains a general overview of topics that you will learn in this lesson.

Using Git to make open source contributions
A Git Workflow For Open Source Contribution
Let’s say you want to contribute to the web application that powers this website (it’s a different repo than our curriculum content, this is our site repo).

How do you contribute when you do not have write access to the repository? Below is a production-ready workflow that is actually used by contributors to this website. We’ll assume here that you have commented on an open issue on our repo and that it has been assigned to you.

The key players in this story will be the upstream (the original GitHub repository), the origin (your fork of that repo), and the “local” repository (your local clone of origin). Think of it as a happy triangle… except that “local” can only pull from upstream, not push.

Initial Setup
Read the contributing guide for the project.
Fork the original (“upstream”) repository into your own GitHub account by using the “fork” button at the top of that repo’s page on GitHub.
Clone your forked repository onto your local machine using something like git clone git@github.com:your\_user\_name\_here/theodinproject.git (you can get the url from the little widget on the sidebar on the right of that repo’s page on GitHub).
Because you cloned the repository, you’ve already got a remote that points to origin, which is your fork on GitHub. You will use this to push changes back up to GitHub. You’ll also want to be able to pull directly from the original repository on GitHub, which we’ll call upstream, by setting it up as another remote. Do this by using git remote add upstream git@github.com:TheOdinProject/theodinproject.git inside the project folder theodinproject.
Ongoing Workflow
We’ve got one main branch – main. main is for production-ready code. Any code deployed to main (on the original repo, not on your fork) will be tested in staging and shipped to production. You’ll be working in a feature branch and submitting your pull requests to the main branch.

Create a new feature branch for whatever feature you want to build, and add commits following the same practices that you learned about in the branching section of our Revisiting Rock Paper Scissors lesson.
When you’re done with your feature, odds are that someone has made changes to the upstream repository in the meantime. That means that your main branch is probably out of date. Fetch the most updated copy using git fetch upstream.
Now merge the upstream’s changes into your local version of main using git merge. Specifically, you’ll first want to make sure you’re on your main branch using git checkout main and then git merge upstream/main to merge in those upstream changes that we just fetched.
Note that a git fetch upstream followed by a git merge upstream/some\_branch is the EXACT same thing as doing a git pull upstream/some\_branch. We prefer to split it up here so that we can explicitly walk through the steps.
Now that your main branch is up-to-date with upstream, you need to merge it into your feature branch. Yes, that is correct and it seems odd at first. Don’t you want to merge the feature branch into the main branch instead? Yes, you do, but not yet. Your feature branch is dirty. You don’t know if it has any conflicts which might creep up. Any time you are merging in more “senior” branches (e.g. merging the feature into main), you want it to be a clean and conflict-free merge if possible. So you first merge the “senior” branch into your dirty branch to resolve those conflicts. Run git checkout your\_feature\_name to jump back onto your feature branch, then git merge main to merge main into it.
You may have merge conflicts… resolve those using the skills you learned in the Deeper Look at Git lesson! (JS Course Link)
Sending Your Pull Request
Now that your feature branch is squeaky clean and you know it’ll merge cleanly into main, the hard part is all over. All that’s left is to make the Pull Request (often abbreviated as PR) against our upstream repo on GitHub!
Now you want to send your feature branch back up to your origin (your fork of the upstream repository). You can’t send directly to upstream because you don’t have access, so you’ll need to make a pull request. Use git push origin your\_feature\_name to ship your feature branch up to your fork on GitHub.
If you have been following along with the above steps to get familiar with this workflow, you should stop at this point. If you have completed an assigned issue, the final step is to submit a pull request to merge your feature branch into the original upstream repository’s main branch. This can be done using GitHub’s interface.
Shake your moneymaker, you’re an OSS contributor!
다음 단원과 지침이 일치하나요?실제 환경에서 Git 사용하기루비 코스소개Git의 기본은 매우 간단하지만, 가끔 혼란스러운 오류 상황에 처했을 때 바닥이 보이지 않는 구덩이처럼 느껴질 때가 있습니다. 엉망으로 만들거나 잘못된 해결책을 시도하면 데이터가 손실될 수 있다고 생각하면 두 배로 실망스럽습니다. 실제로 Git에서 데이터를 '잃어버리는' 것은 매우 어렵지만, 숙련된 개발자가 자세히 살펴보지 않으면 생각지도 못한 곳에 숨어 있을 수 있습니다.Git의 장점은 대단한 기억력을 가진 사람이 아니라면 미리 읽어보는 것만으로는 배울 수 없고, 직접 해봐야 한다는 것입니다. 다시 돌아가서 수정하고 싶은 문제, 병합에서 오류가 발생한 문제 등을 찾아 Google을 검색하면서 그 과정에서 새로운 Git 전략을 배우세요.문제가 생겼을 때 다시 돌아와서 이 강의를 다시 참조하면 도움이 될 것입니다. 먼저 이 프로젝트에 사용된 GitHub 워크플로우의 실제 사례를 다루겠습니다. 아래의 추가 리소스 섹션에서는 나중에 필요할 때 고품질의 리소스를 찾는 데 도움이 될 것입니다.레슨 개요이 섹션에는 이 단원에서 배우게 될 주제에 대한 일반적인 개요가 포함되어 있습니다.Git을 사용하여 오픈 소스 기여하기오픈 소스 기여를 위한 Git 워크플로이 웹사이트를 구동하는 웹 애플리케이션에 기여하고 싶다고 가정해 보겠습니다(커리큘럼 콘텐츠와는 다른 리포지토리로, 사이트 리포지토리입니다).리포지토리에 대한 쓰기 권한이 없는 경우 어떻게 기여하나요? 아래는 이 웹사이트의 기여자가 실제로 사용하는 프로덕션 준비 워크플로입니다. 여기서는 사용자가 리포지토리의 미결 이슈에 댓글을 달았고 해당 이슈가 자신에게 할당되었다고 가정하겠습니다.이 이야기의 핵심 주체는 업스트림(원본 GitHub 리포지토리), 오리진(해당 리포지토리의 포크), "로컬" 리포지토리(원본의 로컬 복제본)입니다. "로컬"은 업스트림에서 끌어올 수만 있고 밀어올 수는 없다는 점을 제외하면 행복한 삼각형이라고 생각하면 됩니다.초기 설정프로젝트에 대한 기여 가이드를 읽어보세요.GitHub의 해당 리포지토리 페이지 상단에 있는 "포크" 버튼을 사용하여 원본("업스트림") 리포지토리를 자신의 GitHub 계정으로 포크합니다.git@github.com:your\_user\_name\_here/theodinproject.git과 같은 명령어를 사용하여 포크된 리포지토리를 로컬 컴퓨터에 복제합니다(GitHub의 해당 리포지토리 페이지 오른쪽 사이드바에 있는 작은 위젯에서 URL을 얻을 수 있음).리포지토리를 복제했으므로 이미 GitHub의 포크인 오리진을 가리키는 리모컨이 생겼습니다. 이 리모컨을 사용하여 변경 내용을 GitHub로 다시 푸시할 수 있습니다. 또한 다른 리모컨으로 설정하여 업스트림이라고 부르는 GitHub의 원본 리포지토리에서 직접 끌어올 수 있도록 하고 싶을 것입니다. 프로젝트 폴더 theodinproject 내에서 git remote add upstream git@github.com:TheOdinProject/theodinproject.git 을 사용하여 이 작업을 수행합니다.진행 중인 워크플로메인 브랜치가 하나 있습니다. 메인 브랜치는 프로덕션에 사용할 수 있는 코드를 위한 브랜치입니다. 메인 브랜치에 배포된 모든 코드(포크가 아닌 원래 리포지토리에)는 스테이징에서 테스트되고 프로덕션에 배포됩니다. 기능 브랜치에서 작업하고 풀 리퀘스트를 메인 브랜치에 제출하게 됩니다.빌드하려는 기능에 대해 새 기능 브랜치를 만들고, 가위바위보 다시 보기 레슨의 브랜치 섹션에서 배운 것과 동일한 방법으로 커밋을 추가합니다.기능이 완성되면 그 사이에 누군가 업스트림 리포지토리를 변경했을 가능성이 높습니다. 즉, 메인 브랜치가 최신 버전이 아닐 가능성이 높습니다. 업스트림에서 git fetch를 사용하여 가장 업데이트된 사본을 가져옵니다.이제 git merge를 사용하여 업스트림의 변경 내용을 로컬 버전의 메인 브랜치에 병합합니다. 구체적으로, 먼저 git checkout main을 사용하여 메인 브랜치에 있는지 확인한 다음 git merge upstream/main을 사용하여 방금 가져온 업스트림 변경 내용을 병합해야 합니다.업스트림에서 git fetch를 한 다음 업스트림/일부\_브랜치에서 git merge를 하는 것은 업스트림/일부\_브랜치에서 git pull을 하는 것과 정확히 동일하다는 점에 유의하세요. 단계를 명시적으로 안내하기 위해 여기서 분할하는 것을 선호한다.이제 메인 브랜치가 업스트림으로 최신 버전이 되었으니, 이를 피처 브랜치에 병합해야 한다. 네, 맞습니다. 처음에는 이상하게 보일 수 있습니다. 대신 기능 브랜치를 메인 브랜치에 병합하고 싶지 않으신가요? 예, 그렇지만 아직은 아닙니다. 피처 브랜치가 더럽습니다. 어떤 충돌이 발생할지 알 수 없습니다. 상위 브랜치에서 병합할 때마다(예: 피처를 메인 브랜치에 병합) 가능한 한 깔끔하고 충돌이 없는 병합이 되기를 원합니다. 따라서 먼저 "상위" 브랜치를 더티 브랜치에 병합하여 이러한 충돌을 해결한다. git 체크아웃\_feature\_name을 실행하여 피처 브랜치로 이동한 다음, git merge main을 실행하여 메인 브랜치를 메인 브랜치에 병합한다.병합 충돌이 있을 수 있습니다... Git 자세히 살펴보기 레슨에서 배운 기술을 사용하여 해결하세요! (JS 강좌 링크)풀 리퀘스트 보내기이제 