이 강의에서는 그러 github 코드를 클론에서 그거 토대로 그대로 실습해보는건가요? 저는 제로에서 혹은 next.kit프로젝트 폴더에 이어서 셋팅해서 연습하는 줄 알았는데.. 두서 설명없이 바로 넘어가니 조금 이상하네요. 전 처음부터 새로 해서 prd생성하고해서 이 프로젝트를 직접 완성해보는건줄알앗느데 그게 아니면 .이미 프롬프트로 만들어진 이걸 클론해서 따라해보는 용도인가요?
동일 폴더위치에서 각 수정을 했다는건 다른 팀원이 그 부분을 수정하고 나는 다른 브랜치에서 수정을 한건데, 그러면 둘 다 내용을 필요로 할텐데, 굳이 선택만을 설명한 이유를 모르겠네요. 이거를 모르는 사용자입장에서 본다면 아...꼭 선택을 해야되는구나라고 생각하지 않을까 싶습니다.
강의 8:16 에서 test 브랜치 쪽의 노란색 커밋을 cherry pick 해서 가져왔는데 main 브랜치 쪽의 초록색 커밋과 충돌되어서 둘 중에 하나를 선택한 상황인데 만약에 conflict가 발생하지 않으면서 노란색 커밋만 가져와서 최종적으로 main 브랜치에 [ 빨간색, 초록색, 노란색 ] 을 가진 커밋으로 만들 수 있는 방법은 없는 건가요? main 브랜치 쪽의 [ 빨간색, 초록색 ] 에서 노란색 커밋만 추가하고 싶은 경우도 있을 것 같아서 질문합니다.
안녕하세요, 강의 잘 듣고 있습니다. 궁금한 부분이 있습니다! 요즘 깃 워크트리라는 것이 있던데 깃 브랜치와의 차이점은 무엇일까요..? 에이전트를 병렬로 돌릴 때 깃 워크트리를 사용하라고 하던데, 브랜치랑 무슨 차이인지 활용방법과 차이는 무엇인지 궁금해서 문의드립니다.. ㅎ
[4주 완독 챌린지 / 영상 강의] 네이버 개발자 출신이 들려주는 AI 시대 개발자 취업 전략
책과 강의를 보면 작업 전, 후로 풀(pull)하시는 것을 말씀해주셨습니다! 혹시 풀(pull)을 어디서 어느 브랜치로 받는 것일까요? 원격 main <-> 로컬 v1.0 해당 브랜치를 대상으로 진행하면 로컬에서 병합 시도를 하는 것 같은데 병합해서 한 번에 원격으로 올리는 것이 맞을까요? 원격 v1.0 <-> 로컬 v1.0 동일한 브랜치에서 풀을받는다면 어찌보면 강의에서 말씀하셨던 main처럼 기준이 되는 브랜치에서 작업을 하는 것일텐데 맞을까요? 기준 브랜치에서 작업하는 것은 권장하지 않으시는 것 같아서 질문드립니다.
카운터 앱을 만드는 예시를 실제로 해 보았습니다. 앱 자체는 잘 동작합니다. 다만 자바스크립트 파일을 열어보았을 때, DOM 영역에서 강의와 실제 저의 예시가 다음과 같이 차이가 있습니다. 강의: 앱, 클래스 및 요소들을 querySelector 함수로 찾음. 제 케이스: getElementById함수로 찾음. 기대대로 동작을 하기 때문에 이 예시에서는 별다른 문제가 없겠으나, querySelector와 getElementById라는 두 함수간의 차이가 있을것 같아 이렇게 처리가 되어도 별다른 문제가 없을지 여쭙습니다. (혹은 두 함수의 공통점, 차이점을 설명해 주셔도 좋습니다.)
안녕하세요 강사님. 좋은강의 잘 듣고 있습니다. 이번 강의 들으면서 질문이 생겨서요. 만약 메인 브랜치 기반으로 깃헙에서 develop 브랜치를 생성한후, fetch로 로컬 레포로 가져와 checkout -t로 로컬 레포의 메인 브랜치로 가져오는 곳까지는 이해했습니다. 그 뒤, 로그인 브랜치를 로컬 레포에서 생성하여 git push로 로그인 브랜치를 깃헙으로 보낸후 풀리퀘스트를 완료하여 머지커밋 생성되는곳 까지는 잘 따라왔습니다. 그럼 만약에 그 깃헙에 올라가있는 머지된 develop 브랜치를 제 로컬 레포로 가져와서 편집하려면 어떻게 해야하나요? fetch 로 가져와서 트래킹 브랜치를 기존 브랜치로 머지나 리베이스 해주면 되는건가요? 만약 실무에서 이런 상황이라고 가정하면 로그인 기능은 개발이 완료되어 브랜치도 삭제했으니 더이상 제 로컬 레포에 존재하는 로그인 브랜치는 필요가 없어졌다. 그러니 추가적인 작업이나 협업이 필요하면 로그인 기능이 추가된 develop 브랜치를 다시 fetch로 받아와 다른 feature 브랜치 생성해서 작업해주면 된다. 이렇게 이해하면 될까요?
pull request는 그렇다면 협업과정에서는 필수로 협업에 들어가기 전 , 협업대상 repository을 fork하고 브랜치를 생성후 그 안에서 계속 작업을 해나아가면 되는걸까요? 아니면 협업과정중에 로컬저장소에 코드작업 했고, 원격저장소에도 코드가 변경된 경우에만 하면 되는걸까요? 협업과정에서 끊임없이 변경될 것 같은데 궁금합니다 ㅠㅠ
안녕하세요 강사님, 강의 재밌게 듣고 있습니다. 좋은 강의 감사합니다. 최근 실무에서 develop 브랜치에 A,B,C,D,E 순서로 merge 가 되어 있는 상황에서 배포를 A,D,E 기능만 배포해야 하는상황이 발생했었는데요? 보통 실무에서 어떤식으로 해결들을 하는지 궁금합니다. 1. main 브랜치에서 release 브랜치를 생성후에 develop 브랜치에서 필요한 merge 커밋들만 cherry-pick 하는 방식을 써도 되는지? develop 브랜치에서 release 브랜치를 생성후에 제외필요한 브랜치 merge 커밋을 revert ?
깊이있는 내용 쉽게 전달해주셔서 감사합니다. 업스트림 10:00근처 공부하다가, 그냥 test branch를 그전에 하던대로 -u옵션 없이 push 해버리면, 어쨌든 리모트에 생기면서, 동시에 거꾸로 origin/test 트래킹브랜치를 만들테고, (여기까지 맞나요?) 그러면 저절로 로컬의 test브랜치와 트래킹 브랜치연결이 되는것 아닌가...요? 아니면 -u옵션이 빠져서, 업로드/다운로드 동시에 실행되고 트래킹브랜치까지도 만들어지는데, test와 origin/test사이의 업스트림 연결만 빠지게 되는건가요?