vite를 사용하여 리액트를 생성하는 경우는 CRA를 통한 리액트 생성하는 방법과 다른것 같습니다.vite.config.js에서 옵션 추가하고 실행하면 정상적으로 동작합니다!import { defineConfig } from "vite"; import react from "@vitejs/plugin-react"; // https://vite.dev/config/ export default defineConfig({ plugins: [react()], server: { host: true, // start 옵션 추가 watch: { usePolling: true, }, // end 옵션 추가 }, });

안녕하세요, geek님. 강의 끝까지 잘 들었습니다.해당 강의가 근본깃-기초 편의 마지막 강의인데, 영상이 끝날 때 "다음 강의에서는 이를 활용하여 동료와 협업하는 방법에 대해서 배운다" 라고 언급하셨더라고요.이때의 '다음 강의'는 근본깃-완성 편으로 이해하면 될까요?

안녕하세요, geek님.영상 16:55~ 부분에서 설명해주시는 conflict를 해결할 수 있는 방법에 대해서 다음 네 가지를 설명해주셨습니다.main 브랜치 쪽 diff를 더한다. test 브랜치 쪽 diff를 더한다. (선택됨)둘 다 더한다.둘 다 더하지 않고, 아예 다른 내용을 적는다.그리고 예제에서는 2번 방식을 선택해주셨고, 이에 따라서 머지 커밋은 다음과 같이 계산됩니다.base(red) + main 최신 커밋과의 diff(green) + test 최신 커밋과의 diff(blue)즉, 3개가 더해져서 만들어지는 커밋인데요. 이로 인해 3-way merge라는 이름으로 불린다고 이해했습니다.여기서 질문이 생기는데요.만약 1번 방식을 선택한다면, 머지 커밋이 다음과 같이 계산됩니다.base(red) + main 최신 커밋과의 diff(green)즉, 2개가 더해져서 커밋이 만들어집니다.그런데 앞서 말씀하신 내용을 고려하면 머지의 세부 명칭(예를 들어 3-way merge같은)에 영향을 주는 요소는 '커밋 히스토리의 모양'입니다.따라서 2개가 더해져서 커밋이 만들어지는 이 상황도 여전히 3-way merge라고 부를 수 있습니다.그래서 처음 들었던 의문은 "1번 방식을 택했을 때는 2개가 더해지는 건데, 이때도 3-way라고 부르는 것은 그냥 관례적인 표현인가?" 입니다.그리고 질문을 작성하면서 제가 스스로 내린 답변은 "더하는 개수가 3개여야 하는 것이 아니고, 더할지 말지 고민하는 기준점이 3개인 상황이라 3-way라는 이름이 붙은 것 같다" 입니다.즉, 커밋 히스토리가 예제와 같은 상황에서는 다음 3가지를 기준점으로 사용하게 됩니다.두 브랜치의 공통 부모 (base)main 브랜치의 최종 커밋test 브랜치의 최종 커밋각 기준점에 대해 어떤 판단을 내리느냐에 따라 세 개를 더하는 2번 상황이 되거나 두 개를 더하는 1번 상황이 되거나, 또 다른 3번, 4번 상황이 될 수도 있습니다.하지만 '기준점이 3개'라는 사실을 모든 상황에서 동일하기 때문에 3-way merge라는 이름이 붙여진 것으로 판단했습니다.가르쳐주신 내용에 혼란을 느낀 부분을 서술하느라 글이 좀 길어졌는데, 결론적으로 '기준점이 3개라서 3-way merge라고 부른다'는 제 판단이 적절한지 여쭤보고 싶습니다.

안녕하세요, 강의 잘 듣고 있습니다.Git을 정리하는 데 큰 도움을 받고 있습니다.다름이 아니라 GitHub에서 브랜치를 메인 브랜치로 병합할 때 사용하는 전략에 대해 궁금합니다. 기본 병합(merge), 스쿼시 & 머지(squash & merge), 리베이스 & 머지(rebase & merge) 방식이 있는데, 어떤 방식을 선호하시는지 여쭤보고 싶습니다.개인적으로는 로컬에서 작업할 때는 리베이스 & 머지를 선호합니다. 히스토리를 깔끔하게 유지할 수 있기 때문입니다. 반면에 메인 계열 브랜치(dev, prod 등)로 병합할 때는 기본 병합을 사용해야 기능 추가 히스토리를 명확히 추적할 수 있다고 생각합니다.

민감한 정보를 포함하는 비공개(Private) GitHub 저장소의 보안을 강화하기 위해 조치가 있을까요

안녕하세요! 강의 너무 잘 듣고 있습니다.제가 이번에 git을 처음 써보면서 이것저것 시도해보고 있는데요!git pull merge 요청을 보낼 때 분명 한번에 merge를 시도 했는데 draft라고 남는 경우가 있더라구요!혹시 이건 제가 요청을 제대로 보내지 않아서 생기는 걸까요?

지금 코랩에서 실습자체가 불가합니다.!python -m pip install tensorflow==2.4.0ERROR: Could not find a version that satisfies the requirement tensorflow==2.4.0 (from versions: 2.16.0rc0, 2.16.1, 2.16.2, 2.17.0rc0, 2.17.0rc1, 2.17.0, 2.17.1, 2.18.0rc0, 2.18.0rc1, 2.18.0rc2, 2.18.0, 2.18.1, 2.19.0rc0, 2.19.0, 2.19.1, 2.20.0rc0, 2.20.0) ERROR: No matching distribution found for tensorflow==2.4.0이거 이렇게 오류 떠서 뭘 할 수가 없어요... 최신 버전으로 수정요청 드리니 빠른 처리 부탁드립니다.코랩말고 다른 개발환경에서 할 수 있는 법도 알려주시면 감사하겠습니다, 몇년 지난 자료라서 안돼는 게 너무 많아요ㅠㅠㅠ

코랩에서 말고 그냥 텐서플로우 자체 환경에서 하면 될까요??!python -m pip install --use-feature=2020-resolver .해당 코드 자체가 설치안되요...18,19강 자체에 이게 설치가 안되니 모듈도 없다고 하고 실습도 안됩니다... 이거 해결방안 없나요?따로 코랩 환경말고 통제가능한 텐서프로우 자체에서 실행하는 방법을 좀 알려주시면 좋을 것 같아요

강의 PPT 같은 자료 요청드립니다.skl509@naver.com여기로 보내주시면 감사하겠습니다

Q1. 브랜치 원리5세션 12에서 “main은 복사되는 게 아니라 동일한 커밋을 여러 브랜치가 담고 있다”는 설명이 직관적으로 잘 그려지지 않아요. (복사가 아니면 정확히 어떤 메커니즘일까?) Q2. 머지와 컨플릭트fast-forward 구조(예시 이미지)에서 빨간색 영역의 코드는 테스트 도중에 수정이 가능한건가요? 수정이 가능해서 수정 했다면 머지할 때 컨플릭트 가 나는거 아닌가요..? 왜 헷갈리냐면 강의에서 fast-forward 머지에서는 각각의 diff가 없기 때문에 conflict가 안 난다고 햇는데, 그럼 이런 구조는 fast-forward가 아닌 상황인건가요..? Q3. HEAD의 부모 커밋아래 예시이미지에서 HEAD가 가리키는 커밋(main : Merge branch 'test')의 부모 커밋은 test add blue to rect와 add green to rect 이렇게 두 개가 맞는지 확인을 하구싶어요.  

안녕하세요.rebase 단원(이전 강의)의 설명을 들으면서, rebase 란 fast-forward merge 를 수행할 수 있게끔 commit history 를 flatten 해 주는 작업으로 이해했는데요.rebase 과정에서도 conflict 가 발생하고, 이것을 처리해줄 필요가 있다면, 그냥 3-way merge 에서 conflict 를 처리하는 것과 근본적인 차이가 있을까요?제 생각으로는 rebase 과정에서는 branch 에서 떨어져 나간 commit 들이 생기고, 3-way merge 에서는 기존 commit 들이 병합된 branch 안에 들어있다, 는 차이 정도밖에 없는 것 같은데요.굳이 3-way merge 말고 rebase 를 사용해야 할 필요가 있을까요?

문서가 락이 걸어져있네요. 비번 알려주세요.  강의노트에도 없어서 문의 남깁니다.

저 이 화면에서 open with live server 를 눌렀는데이 화면이 떠요.. 저 그러고 혹시 강의 마지막 부분만 보고도 앱을 만들 수 있나요?

정상적으로 진도 뺀 사람이면 한번에 포크 안받아져야 정상인가요? The repository Boxiting already exists on this account이런메시지 뜹니다.

06:55 윈도우 사용자인데요 Boxiting-oct에서는 풀받을게 없다고 뜨지만 풀버튼을 누르니 고양이의 커밋 올린게 풀이 받아졌습니다. 이런경우도 있나요??

누르고 안누르고 어떤차이죠??

제가 지금 사이드 프로젝트에서 dev와 main 두개의 브랜치로 나누어 사용중인데보통 dev 브랜치를 이용해 git push origin dev 하고 풀리퀘스트 base를 main 브랜치로 한 후다시 프로젝트 터미널에서 git pull origin main 으로 작업하고 있습니다그러나 어느 날 git push origin dev 를 했는데 github에 Compare & Pull Request 버튼이 없어져서수동으로 base 를 main 으로 pull request 하고 merge 했는데 그러자 마자 main 브랜치에 대해Compare & pull request 버튼이 나타났습니다.이걸 다시 이전처럼 dev 브랜치를 push 했을때 Compare & pull request 가 나타나게끔 바꾸고 싶은데 어떻게 해야하나요?

vscode에서의 github로의 push는 따로 강의 계획이 없으실까요??

3:50서부터 질문인데요 강사님처럼 퍼센티지 뜨거나 그러진 않았는데  뭔가해서 다시명령어 입력하니  error:remote origin already exists 라네요  그리고 첨에 명령어 입력 했을때는  강사님처럼 %가뜨는게 아니라 새로운 팝업창이 떠서 username password 입력하라 뜨길래 다 닫았는데 이런 경우는 뭔가요?

만약에 협업을 진행하는 과정에서 제가 develop브랜치에서 feat1브랜치를 따서 작업을 한후 push한다음 pr을 만들었지만, 아직 merge되지 않은 상태에서 feat1 브랜치보다 늦게 다른 팀원이 feat2브랜치를 따서 작업을 해서 push한 후 pr에서 develop브랜치에 merge까지 된 상태인 경우. feat1브랜치 사용자는 git pull origin develop 해서 최신사항을 내려받은 후 남은 작업을 수행해야하는 것인지 궁금합니다.  또한 git pull origin develop한다고 가정했을 때, 커밋이력이 1개만 추가되는 것인지 develop 브랜치의 최신 커밋이력들을 전부 가져오는 것인지 궁금합니다.