geek

안녕하세요. 😀 Q. 만약에 그 깃헙에 올라가있는 머지된 develop 브랜치를 제 로컬 레포로 가져와서 편집하려면 어떻게 해야하나요? ->리모트 레포지토리에 있는 develop 브랜치를 fetch하여 로컬 레포지토리를 최신 상태로 만들어 주신 이후에 feature 브랜치를 만드는 방법으로 편집하시면 됩니다. Q. 만약 실무에서 이런 상황이라고 가정하면 로그인 기능은 개발이 완료되어 브랜치도 삭제했으니 더이상 제 로컬 레포에 존재하는 로그인 브랜치는 필요가 없어졌다. 그러니 추가적인 작업이나 협업이 필요하면 로그인 기능이 추가된 develop 브랜치를 다시 fetch로 받아와 다른 feature 브랜치 생성해서 작업해주면 된다. 이렇게 이해하면 될까요? -> 네, 정확합니다.

깃헙 작업 완료된 develop 브랜치 질문

안녕하세요, 최승표님 😀 강의를 열심히 들어주셔서 저도 진심으로 감사드립니다. 말씀해 주신대로, -u 옵션이 빠지게 되면 "업로드 + 다운로드 + 트래킹 브랜치 생성" 과정이 동시에 발생하게 됩니다. 하지만 test 브랜치와 origin/test 브랜치가 서로 업스트림으로 연결되는 과정은 생략됩니다. 또 궁금하신 부분이 있다면 언제든 질문 주세요!!

upstream연결하기

안녕하세요, JH P 님 😀 질문을 제가 제대로 이해하지 못했는데, 조금만 더 쉽게 설명해주실 수 있을까요? 🙏🙏🙏 감사합니다 :)

gitignore관련 질문

안녕하세요 😀 어떤 이유로 staging area가 비워진다고 보셨는지 여쭤볼 수 있을까요? :)

staging area

안녕하세요, dev.rudevico 님 😀 네, 적절합니다. 제가 강의에서 설명한 내용은 판단해주신대로 입니다. 강의를 만들면서 dev님과 비슷한 고민을 많이했던 터라, 저와 이야기가 잘 통할 것 같은 기분이 드네요 ㅎㅎ

3-way merge에서의 conflict를 해소할 수 있는 4가지 방법

안녕하세요, Robbie 님 😀 저의 경우, 특별히 선호하는 방식은 없습니다. 상황에 따라 제일 좋은 방법을 사용하는게 최선이라고 봅니다. 예를 들어... (언급해주신대로...) 히스토리를 명확히 추적해야 하는 경우엔 기본 병합을 사용할 수 있겠죠. 기능 단위로 커밋들을 깔끔하게 정리하고 싶을 때도 있을 겁니다. 이때는 스쿼시 & 머지(squash & merge)를 사용할 수 있어요. 다른 상황에선, 커밋 히스토리를 깔끔하게 만드는게 좋을 때도 있습니다. 이러한 경우에는 리베이스 & 머지(rebase & merge)를 사용할 수도 있습니다. 협업하는 팀원 수, 만드는 기능, 기능의 중요도 등등에 따라 최선의 방법을 사용하시는게 BEST라고 봐요!

브랜치 병합 전략에 대한 지식공유자님의 생각이 궁금합니다.

안녕하세요, Siver.Jane 님 😀 혹시, 문제 상황을 스크린샷으로 보여주실 수 있을까요?

git pull merge 요청 시 draft

안녕하세요, 정이경님 😀 Q1. 브랜치는 커밋을 가리키는 포인터입니다. 여러 브랜치가 동일한 커밋을 가리킬 수 있습니다. 그래서 여러 브랜치가 동일한 커밋을 담고 있다고 표현한 겁니다. 이에 대한 내용은 "브랜치 실제 모양 #HEAD "회차를 참고해주세요! Q2. 직관적인 그림 감사드립니다. 화살표로 가리키는 부분에서 "코드를 새롭게 수정 + 커밋을 새롭게 만들지는 않고," 머지하는 상황일까요? Q3. 네 맞습니다. HEAD가 가리키는 커밋(main : Merge branch 'test')의 부모 커밋은 test add blue to rect와 add green to rect 두 개입니다.

궁금해요

안녕하세요, yuntae.kang 님 😀 rebase는 동료와 협업할 때 특히 유용합니다. 왜냐하면 커밋 히스토리를 단순하게 유지할 수 있기 때문이에요. 이에 대한 내용은 "동료와 협업할 때 conflict 해결하기 #github #rebase" 회차를 참고해주세요!

rebase 와 3-way merge 의 근본적인 차이

안녕하세요, info님!제가 따로 락을 걸어두지는 않았지만, 확인해보고 바로 댓글 남기겠습니다.&nbsp;불편 끼쳐드려 죄송합니다!

geek

投稿