rebase 이해

네 맞습니다. 제가 이해하기로는 "feature를 master위로 올린다" == " feature의 시작점을 rebase 당시 선택한 브랜치의 최종 커밋 위치로 변경하는 것" 라고 생각이 되어서 잘 이해하신 것 같네요. 끝까지 화이팅입니다.

merge를 쓰지않더라도

안녕하세요 루라님, 가정을 해주신게 상대와 나 모두 같은 브랜치에서 작업 하는 것을 가정하신게 맞나요? pull 의 경우 기본 옵션이 git merge FETCH_HEAD로 작동하기 때문에 따로 merge 명령어를 사용하지 않아도 merge가 된 것이 맞습니다. merge의 경우는 보통 브랜치에서 파생된 브랜치를 원래의 브랜치로 합칠 때 사용합니다. 예륻들어 보겠습니다. develop이라는 브랜치가 있고, develop에서 철수는 feature/a를 생성하여 작업을 하고 영희는 develop에서 feature/b를 생성하여 작업을 합니다. 철수와 영희가 각각 작업(커밋)들을 한 뒤에 작업물들을 하나로 모아야겠죠? 이 때 develop 브랜치로 합쳐야 하는데 이때 merge(혹은 rebase)를 사용하게 됩니다. develop브랜치로 체크아웃 -> git merge feature/a 를 통해서 철수의 작업들을 develop으로 합치고, git merge feature/b를 통해 영희의 작업들을 develop으로 합치는 것이지요. 조금 내용이 길지만 해당 자료도 같이 보시면 도움이 되실 것 같네요! 감사합니다.

머지 하지않은 상태에서 -d 로도 delete

안녕하세요 루라님 예시로 들어주신 상황은 master에서 test/3 브랜치를 생성 후 바로 test/3을 -d 옵션으로 지우셨는데, 이는 가능합니다. master에서 test/3 브랜치를 생성한 후 test/3 브랜치에서 커밋을 1개 이상 만든 후에 master로 머지하지 않은 상태에서 test/3을 -d 옵션으로 지우려고 하면 안될 거에요. 이렇게 한번 테스트 해보시면 좋을것 같네요. 감사합니다~

pull과 push 후 결과 메시지

안녕하세요? 딱히 git에서만 뭐라고 정해진 이름은 없는 것 같습니다. 일반적인 커맨드 입력에 대한 결과? 정도로 보시면 될거 같습니다. pull, push 후 메시지의 해석은 적어주신 내용이 맞습니다. 여러 실습을 해보시면서 테스트 해보시면 도움이 되실 것 같습니다. 감사합니다.

HEAD-> master, .... 의미

안녕하세요? origin/HEAD는 말 그대로 origin(= 리모트)의 브랜치가 현재 기본으로 가리키고 있는 commit이라고 보시면 됩니다. 아래 명령어를 사용하면 master가 아닌 브랜치를 리모트의 HEAD를 변경 할 수도 있습니다. > git remote set-head origin some_branch 사실 크게 중요한 내용도 아니고 실무에서 많이 사용하실 일은 없을 것 같습니다. (경험상) 감사합니다.

깃허브 혹시 지금은 무료가 됬나요 ?

인텔리제이 기반 강의는 사정상 일시 중단된 상태이긴 합니다.ㅠ 강의 내용은 준비된 상태이며 가능한한 노력해 복도록 하겠습니다. 오픈되면 공지를 통해 알려드리도록 하겠습니다. 기대와 관심 감사드립니다 :)

깃허브 혹시 지금은 무료가 됬나요 ?

안녕하세요 김태희님? 제가 회사 엔터프라이즈 깃헙을 주로 사용하고, 일반 깃헙 private 저장소를 여러명에서 잘 사용하지 않아서 확인을 못했던 부분이네요. 지금 저도 찾아봤는데 제가 강의 제작하고 한 달 뒤에 정책이 바뀌었나 봅니다. 현재는 private 저장소도 인원 제한이 없네요! 강의 수업노트에 해당 부분 추가했습니다. 말씀해 주셔서 감사합니다. https://docs.github.com/en/github/getting-started-with-github/faq-about-changes-to-githubs-plans https://github.com/settings/billing/plans

딱 커밋에 포함된 내용만 가져오는건가요?

안녕하세요 준또님 네 맞습니다. 한 커밋에 포함하는 모든 변경들을 가져옵니다. 만약 a 커밋에서 1.html의 3번째 줄도 고치고, 1.css의 10번째 줄을 고쳤다면 a 커밋을 cherry-pick 하면 1.html에서 고친것, 1.css에서 고친것 모두 가져오게 됩니다. 직접 실습해 보시면 쉽게 느껴보실 수 있으실 겁니다.

스테이지에 올리는 add 이후 머지를 하면 안되는 이유 알 수 있을까요?

안녕하세요 준또님? 제가 절대 commit을 하지 말라고 한 부분 확인했습니다. 관련해서 제가 테스트를 해보았습니다. 상황: rebase 중 conflict가 났고, 수정을 한 후에 add를 함 이 상황에서 말씀해 주신 것처럼 rebase --continue가 아닌 commit을 해보았습니다. 그리고 난 뒤에 rebaes --continue를 했더니 정상적으로 진행이 되지 않고 아래와 같은 메시지가 나왔습니다. "stage에 아무것도 남은게 없다(이미 commit을 임의로 해버렸죠?), rebase --skip이나 --abort를 해라"라고 합니다. 그래서 이 상황에서 continue는 하지 못하고 skip이나 abort를 해서 rebase를 마무리 해야 합니다. (사진)

3:20 에나오는 echo와 '>>'에대해 알고싶습니다

안녕하세요? 이미 구글링으로 잘 찾아보신 것 같습니다. 질문1 echo는 기본적으로 linux에서 화면에 문자를 출력하는 명령어 입니다. 그런데 >나 >>를 이용해서 파일을 생성하면서 내용을 넣을 수도 있습니다. 질문2 네 맞습니다. >는 이전 내용에 상관없이 새로 쓰는 것이고 >>는 기존 내용은 그대로 두고 그 뒤에 append 합니다. 질문3 강의 뒤에 commit 파트에서 다룹니다. 먼저 말씀드리자면 commit 메시지를 뒤에 값으로 줄 수 있는 옵션입니다. "GitHub에 코드 올리기" 강의에서는 일부러 자세히 다루지 않고 전체적인 흐름만 다루어 보았습니다. 강의를 듣다 보시면 이해가 되실거라 생각됩니다. 추가로 아래 블로그 참고하시면 도움이 되실 것 같습니다. 감사합니다. https://m.blog.naver.com/PostView.nhn?blogId=audiendo&logNo=220775822302&proxyReferer=https:%2F%2Fwww.google.com%2F