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 를 사용해야 할 필요가 있을까요?

안녕하세요 강사님섹션 39. 413강을 실습하던중 오류가 있어서 문의 드립니다,위와 같이 오류가 뜹니다.target이 dev는 이상없이 잘 실행됩니다.

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

저 이 화면에서 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는 따로 강의 계획이 없으실까요??

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

yumin020293@gmail.com 강의자료 부탁드립니다

깃에서 머지(Merge)를 되돌려 이전 상태로 돌아가려면 어떤 방법을 써야 하는지 궁금합니다. fast-forward 머지인 경우에는 git reset을 이용해야 한다는 건 알겠습니다.그런데 머지 커밋이 생성되는 일반 머지의 경우, 해당 머지 커밋에 대해 git revert를 적용해서 이전 상태로 되돌릴 수 있을 것 같은데 그렇다면 fast-forward 머지보다 머지 커밋을 생성하는 방식이 더 안전한 선택인지도 궁금합니다. 

안녕하세요 강사님 main 브랜치를 최상위 브랜치로 놓고 거기서 하위 브랜치인 dev 브랜치가 나오고 dev 브랜치에서 이걸 상위 브랜치로 갖는 다른 브랜치를 만드는 방법이 있나요? 로컬에서 여기서 설정 하는 거 말고 혹시 다른 방법이 있나요? 여기서 만들고 계속 동기화해서 올리고 있습니다.

안녕하세요!먼저 좋은 강의 제공해주셔서 감사합니다~!강의를 듣다가 조금 헷갈리는 부분이 있어서 질문드립니다. 강의에서 “git add 명령어는 워킹 디렉토리에 있는 파일을 staging area로 복사하거나 덮어쓴다” 라고 하셨는데, 제가 이해하기로는 git add를 실행했을 때 실제 파일이 복사되는 건 아니고, 해당 시점의 스냅샷 정보가 저장되는 게 맞을까요? 아마도 쉽게 설명하시려고 “복사”라는 표현을 쓰신 것 같은데, 복사를 하게 되면 파일이 2개 생기는 건지 등등 이 부분이 조금 혼동을 줄 수 있는 것 같아 질문드립니다.

추가 질문이 있는데요, git checkout [commit ID] 명령어는 현재 working directory의 tracked 파일들과 staging area 의 파일들을 해당 commit 의 상태로 되돌린다고 배웠는데요.만약... 최종 커밋 이후 working directory에서 작업을 수행하다가, 실수로 git checkout 을 입력해버리면, 다시 기존의 (커밋되지 않은) working directory는 복구할 수 없는 것일까요?

안녕하세요.git checkout [commit ID] 를 통해 예전의 커밋으로 되돌릴 수 있다고 배웠는데요.현재 working directory에 rectangle 및 circle 이 있고, 현재 커밋 버전이 3일 때,- rectangle 파일은 커밋 2로 되돌리고,- circle 파일은 커밋 1로 되돌리고 싶을 경우각각의 파일에 대하여 다른 버전의 커밋으로 되돌리는 것이 가능한지 궁금합니다.실무에서는 이런 일이 빈번하게 일어날 것으로 예상이 되어서요. 이를테면 a 파일에 버그가 난 걸 모른 채로 b 파일을 작업해서 커밋을 완료했는데, a 파일의 버그를 뒤늦게 발견하여 되돌리고자 하는데 이때 b 파일의 작업 내역은 되돌리고 싶지 않을 수 있으니까요.감사합니다.

안녕하세요 선생님 강의자료 요청드립니다.fhvmf444@naver.com 입니다.열심히 학습하겠습니다.좋은 강의 올려주셔서 감사합니다.

안녕하십니까? 강사님강의를 열심히 듣고 있는 중입니다.363강 Step #29 - Timer를 실습하던중 의문점이 생겨서 문의 드립니다.30초에 타이머가 일시정지하게끔 하거나 중지시키게 하면 항상 2-3초의 오차가 발생합니다.이게 소스상의 문제인지 아님 다른 문제인지 알수가 없어서 문의 드립니다.