Hỏi & Đáp
안녕하세요, 버터플라이 블랙님 :) 죄송합니다. 제가 질문을 너무 늦게 봤네요. (지금보니 그림이 다소 헷갈리는 부분이 있네요!) 파일 내용이 동일하더라도, 이 둘은 별개의 커밋으로 봐주시면 감사합니다. 따라서 로컬의 test브랜치가 리모트의 test 브랜치를 포함하지 못하는 상황이고, 이에따라 푸시도 불가능한 상황입니다. 또 궁금한 점 있다면 언제든 질문주세요. 감사합니다.
Hỏi & Đáp
안녕하세요, 창한님 🙂 콘플릭트를 해결할 때 나오는 에디터에서, 초록색을 지우지 않으시면 됩니다. 다시 말해, 초록색과 노란색 모두를 선택하는 방향으로 머지를 진행하시면 됩니다.
Hỏi & Đáp
안녕하세요. 😀 Q. 만약에 그 깃헙에 올라가있는 머지된 develop 브랜치를 제 로컬 레포로 가져와서 편집하려면 어떻게 해야하나요? ->리모트 레포지토리에 있는 develop 브랜치를 fetch하여 로컬 레포지토리를 최신 상태로 만들어 주신 이후에 feature 브랜치를 만드는 방법으로 편집하시면 됩니다. Q. 만약 실무에서 이런 상황이라고 가정하면 로그인 기능은 개발이 완료되어 브랜치도 삭제했으니 더이상 제 로컬 레포에 존재하는 로그인 브랜치는 필요가 없어졌다. 그러니 추가적인 작업이나 협업이 필요하면 로그인 기능이 추가된 develop 브랜치를 다시 fetch로 받아와 다른 feature 브랜치 생성해서 작업해주면 된다. 이렇게 이해하면 될까요? -> 네, 정확합니다.
Hỏi & Đáp
안녕하세요, 최승표님 😀 강의를 열심히 들어주셔서 저도 진심으로 감사드립니다. 말씀해 주신대로, -u 옵션이 빠지게 되면 "업로드 + 다운로드 + 트래킹 브랜치 생성" 과정이 동시에 발생하게 됩니다. 하지만 test 브랜치와 origin/test 브랜치가 서로 업스트림으로 연결되는 과정은 생략됩니다. 또 궁금하신 부분이 있다면 언제든 질문 주세요!!
Hỏi & Đáp
안녕하세요, JH P 님 😀 질문을 제가 제대로 이해하지 못했는데, 조금만 더 쉽게 설명해주실 수 있을까요? 🙏 🙏 🙏 감사합니다 :)
Hỏi & Đáp
안녕하세요 😀 어떤 이유로 staging area가 비워진다고 보셨는지 여쭤볼 수 있을까요? :)
Hỏi & Đáp
안녕하세요, dev.rudevico 님 😀 네, 적절합니다. 제가 강의에서 설명한 내용은 판단해주신대로 입니다. 강의를 만들면서 dev님과 비슷한 고민을 많이했던 터라, 저와 이야기가 잘 통할 것 같은 기분이 드네요 ㅎㅎ
Hỏi & Đáp
안녕하세요, Robbie 님 😀 저의 경우, 특별히 선호하는 방식은 없습니다. 상황에 따라 제일 좋은 방법을 사용하는게 최선이라고 봅니다. 예를 들어... (언급해주신대로...) 히스토리를 명확히 추적해야 하는 경우엔 기본 병합을 사용할 수 있겠죠. 기능 단위로 커밋들을 깔끔하게 정리하고 싶을 때도 있을 겁니다. 이때는 스쿼시 & 머지(squash & merge)를 사용할 수 있어요. 다른 상황에선, 커밋 히스토리를 깔끔하게 만드는게 좋을 때도 있습니다. 이러한 경우에는 리베이스 & 머지(rebase & merge)를 사용할 수도 있습니다. 협업하는 팀원 수, 만드는 기능, 기능의 중요도 등등에 따라 최선의 방법을 사용하시는게 BEST라고 봐요!
Hỏi & Đáp
안녕하세요, Siver.Jane 님 😀 혹시, 문제 상황을 스크린샷으로 보여주실 수 있을까요?
Hỏi & Đáp
안녕하세요, 정이경님 😀 Q1. 브랜치는 커밋을 가리키는 포인터입니다. 여러 브랜치가 동일한 커밋을 가리킬 수 있습니다. 그래서 여러 브랜치가 동일한 커밋을 담고 있다고 표현한 겁니다. 이에 대한 내용은 "브랜치 실제 모양 #HEAD "회차를 참고해주세요! Q2. 직관적인 그림 감사드립니다. 화살표로 가리키는 부분에서 "코드를 새롭게 수정 + 커밋을 새롭게 만들지는 않고," 머지하는 상황일까요? Q3. 네 맞습니다. H EAD가 가리키는 커밋(main : Merge branch 'test')의 부모 커밋은 test add blue to rect와 add green to rect 두 개입니다.
