staging area

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

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

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

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

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

git pull merge 요청 시 draft

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

궁금해요

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

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

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

문서가 락이 걸어져있네요.

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

vscode에서의 github로의 푸시

안녕하세요, 조성찬님 😀근본깃 강의를 들으시면 어떤툴에도 금방 적응하실 수 있습니다.그래서 지금 당장은 vscode 강의를 진행할 계획은 없습니다. 😂하지만 git 과 github에 대한 것이라면 무엇이든 질문 바랍니다!vscode에 대한 내용도 환영입니다 :)

Git 머지 커밋 되돌리기(revert)와 머지 방식 선택의 안전성 질문

안녕하세요, Next 님 😀- 머지 커밋이 생기는 3-way 머지의 경우에도, reset 명령어로 머지를 되돌릴 수 있습니다 :)

git add 동작 원리에 대한 질문

안녕하세요, Next 님 😀네, 말씀하신대로 스냅샷 정보가 저장된다는 표현이 더 정확합니다.실제 내부 원리를 말씀드리자면... 파일이 복사되어 2개가 되는 것은 아니에요.파일이 복사된다고 설명드린 이유는, 많은 사례나 오류 상황에 대응하면서도 쉽게 이해하기 위함입니다.추가로 궁금하신 부분이 있다면 언제든 질문주세요!감사합니다.