안녕하세요~ 혹시 실무에서는 하나의 topic branch를 따서 1) 한번의 커밋, 푸쉬, 승인후 머지하는게 보통적인 프로세스인가요? 2) 아님 커밋을 여러번하고 다른명령어로 하나의 커밋으로 합친 뒤 푸쉬, 승인 후 머지하는게 보통인가요? 3) 아님 개발자 개인의 성향에 따라 푸쉬전에 커밋횟수는 다른가요? 개념이 부족해서 질문이 두서가 없는거 같아 죄송합니다. 최근에 협업을 하고있는데 저같은 경우 커밋을 여러번하니 나중에 rebase를 해야하더라구요. 그래서 실무에서는 어떤 관습같은게 존재하는지 궁굼해서 질문 남겨봅니다^^
좋은 질문 감사해요 👍 “Git 브랜치 전략”으로 검색해보세요. 참고하실 만한 글이 많이 있습니다. 저는 그 중에 git flow방식을 선호합니다. 개인적으로는 하나의 commit으로 합치는 건 불필요하다고 생각하고 각자 브랜치애서 여러번 작업흐름에 따라 커밋한 것도 중요한 기록이라 생각하기에 그 여러 커밋을 그대로 유지하는 것을 저는 권합니다. 이런 경유 merge할 때는 fast forward merge가 가능한 상황이라도 새로운 커밋이 생성되는 merge를 하여 해당 브랜치의 커밋들을 나중에 쉽게 구분할 수 있게 하는 것이 좋습니다.
강의 너무 감사합니다^^ git 3편도 기대하고, 기다리고 있습니다. 질문도 한가지 있습니다. head가 master 를 가르치다가 둘이 다른 곳을 가르킬때 부터 이해가 되지 않아서요. head는 현재 commit 된 것이 무엇인지 알려 주는 포인터로 명확히 이해했는데, master에 대한 정확한 이해가 안되서요! master가 어떤 걸 가르치는지 궁금합니다!
응원 댓글 및 질문 모두 감사해요! head는 현재 위치가 어디인지가 저장되어 있는 변수라 생각하시면됩니다. 이 변수에는 commit id나 branch 이름을 저장할 수 있습니다. 같은 맥락에서 branch는 특정 commit id를 저장할 수 있는 변수라 생각하면 됩니다. 따라서 commit을 생성할 때와 같이 git이 현재 바라 보고 있는 커밋 을 알아야하는 header 변수부터 뒤져서 해당하는 commit id를 찾게됩니다. header 에는 master값이 들어 있고 master에는 abc123 id가 들어 있다면 현재 바라보고 있는 commit의 id는 abc123이 됩니다. 만약 develop이라는 branch는 cde456이라는 commit id가 자정되어 있을 경우 사용자가 develop으로 checkout하면 head에는 develop이라는 branch명이 저장되고 현재위치를 찾을 때 head -> develop -> cde456 단계를 거쳐서 현재 바라보는 commit id를 찾게 됩니다.
![[10분 테코톡] 오리&코린의 Merge, Rebase, Cherry pick](http://i.ytimg.com/vi/b72mDco4g78/mqdefault.jpg)
태그가 AB9C7 이라고 되어있는데 AB978 로 되어야 맞는거죠?
jungpyo lee 앗! AB9C8 입니다. 꼼꼼하게 봐주시고 알여주셔서 감사합니다.
@@codejong 빠른댓글 멋져요!!♥♥♥
깃에 대한 내용을 제가 유튜브랑 블로그 돌아다니면서 본 그 어떤 자료보다 제일 이해하기 쉽고 기억에 남게 알려주시네요.. 인터넷에 대부분이 복붙자료라 해결이 안되고 답답했는데 정말 감사합니다. 전달을 정말 잘하시네요.
도움이 된 것 같아 기쁘네요. 힘나는 피드백 감사합니다.
깔끔한 강의 감사합니다~
피드백 감사합니다👍
설명이 너무 좋아요 감사합니다!
도움이 되셨다니 다행입니다.
가장 명료하고 단순화 되어서 이해하기 좋아요. 감사합니다
도움이 되었다니 다행이고 감사합니다. 😁
제발 ㅠㅠ 영상 더 올라왔으면 좋겠어요 ㅠㅠ 너무 명료하고 명확하게 잘 가르쳐주셔서 좋아여 ㅠㅠㅠ
감사합니다! 제가 개인적인 사정으로 한동안 영상을 만들지 못했습니다. 곧 다시 인사드릴게요. 제 영상관련 부족하거나 궁금하신 점 있으면 언제든지 알려주세요~
async 강의로 들어와서 코드종님 동영상 전부 다 봤네요... 영상 업로드는 안하신 지 꽤 된 거 같은데 그래도 구독하고가요! 좋은 소식 기다리겠습니다 ㅎㅎㅎ
응원 감사합니다! 댓글 질문에 대한 답변은 꾸준히 하고 있으니 궁금하시거나 의견 있으면 댓글로 알려주세요. 2020년에 새로운 영상들로 인사드릴게요!
와 대박 코드종님 강의 다 들었어요! 입문자들에게 정말 좋은 강의인거 같아요! 적게 일하고 돈 많이 버세요^^^^^^
최고의 덕담이네요 ㅎㅎㅎ
코드종 교장 선생님.
으하하하하핳~ 최근 늘어난 흰머리는 웬만한 교장 선생님보다 많을 겁니다.
너무 잘봤습니다. git series 얼른 보고 싶습니다ㅠㅠ
김형근 감사합니다! Git 시리즈는 js보자 인기가 없다보니 시간날 때 js를 먼저하게 되네요.
많이 공유해주세요. git관련해서도 조금 더 다뤄보겠습니다.
영상 정말 감사합니다. git을 이해하는데 많은 도움이 되었어요!
도움이 되었다니 너무 기쁩니다. ㅎ
얼굴 그려지는거 왜케 귀엽죠 ㅋㅋㅋㅋ 그림이랑 같이 보니까 이해하기 쉬워요! git 맨날 쓰던것만 썼는데 보면서 연습 해봐야겠어요. 감사합니다 👨💻👩💻
kwonkwon 님, 코드종이 도움이 되었다니 기뻐요. 앞으로 나올 영상들도 기대해주세요~ :) 감사해요!
I dont understand a word and it is still better explained then in my course I paid for, thank you
Thank you for watching my video. 🙏
깃 시작하기 넘 어려웠는데 넘 잘 이해되네용!
이창환 시청해주시고 댓글까지 모두 감사합니다. 궁금하신 점이나 헷갈리는 점은 언제든지 알려주세요.
좋아요!!
저도 좋아요 ㅎㅎ 🥰
안녕하세요~ 혹시 실무에서는 하나의 topic branch를 따서
1) 한번의 커밋, 푸쉬, 승인후 머지하는게 보통적인 프로세스인가요?
2) 아님 커밋을 여러번하고 다른명령어로 하나의 커밋으로 합친 뒤 푸쉬, 승인 후 머지하는게 보통인가요?
3) 아님 개발자 개인의 성향에 따라 푸쉬전에 커밋횟수는 다른가요?
개념이 부족해서 질문이 두서가 없는거 같아 죄송합니다. 최근에 협업을 하고있는데 저같은 경우 커밋을 여러번하니 나중에 rebase를 해야하더라구요. 그래서 실무에서는 어떤 관습같은게 존재하는지 궁굼해서 질문 남겨봅니다^^
좋은 질문 감사해요 👍
“Git 브랜치 전략”으로 검색해보세요. 참고하실 만한 글이 많이 있습니다. 저는 그 중에 git flow방식을 선호합니다.
개인적으로는 하나의 commit으로 합치는 건 불필요하다고 생각하고 각자 브랜치애서 여러번 작업흐름에 따라 커밋한 것도 중요한 기록이라 생각하기에 그 여러 커밋을 그대로 유지하는 것을 저는 권합니다. 이런 경유 merge할 때는 fast forward merge가 가능한 상황이라도 새로운 커밋이 생성되는 merge를 하여 해당 브랜치의 커밋들을 나중에 쉽게 구분할 수 있게 하는 것이 좋습니다.
@@codejong 상세한 답변 감사합니다~
질문을 남기고 최근 깃에대해 공부하면서 git flow란 전략이 있다는걸 알게됬는데, 코드종님도 말씀하는걸 보니 알아보고 적용하면 좋을거같네요^^ 늦은밤에 감사드리고 다음주도 즐거운 한주 보내세요!!
영상 항상 감사합니다 ㅎㅎ Git pull/merge와 rebase의 차이가 궁금합니당!!
깃 다음 주제로 말씀하신 내용 다뤄보겠습니다. 의견 감사합니다!
주근깨 얼굴 나오는 남자애 애니메이션 효과 어덯게 하신건가요?
안녕하세요~ 아이폰 iOS 12부터 추가된 memoji 기능을 이용하고 있습니다. 별도로 영상 캡쳐 후 컴퓨터 화면이랑 편집하고 있어요.
@@codejong 답글 감사해요! 요즘 제가 코딩에 빠져서.. ..다양한 분들.채널에서 공부중입니다. 영상에 재밌는 애니메이션이 있길래 ㅎㅎ
코드종님 채널도 많은 도움 되고 있어요 감사해요!
강의 너무 감사합니다^^ git 3편도 기대하고, 기다리고 있습니다. 질문도 한가지 있습니다.
head가 master 를 가르치다가 둘이 다른 곳을 가르킬때 부터 이해가 되지 않아서요.
head는 현재 commit 된 것이 무엇인지 알려 주는 포인터로 명확히 이해했는데,
master에 대한 정확한 이해가 안되서요!
master가 어떤 걸 가르치는지 궁금합니다!
응원 댓글 및 질문 모두 감사해요! head는 현재 위치가 어디인지가 저장되어 있는 변수라 생각하시면됩니다. 이 변수에는 commit id나 branch 이름을 저장할 수 있습니다. 같은 맥락에서 branch는 특정 commit id를 저장할 수 있는 변수라 생각하면 됩니다. 따라서 commit을 생성할 때와 같이 git이 현재 바라 보고 있는 커밋 을 알아야하는 header 변수부터 뒤져서 해당하는 commit id를 찾게됩니다. header 에는 master값이 들어 있고 master에는 abc123 id가 들어 있다면 현재 바라보고 있는 commit의 id는 abc123이 됩니다. 만약 develop이라는 branch는 cde456이라는 commit id가 자정되어 있을 경우 사용자가 develop으로 checkout하면 head에는 develop이라는 branch명이 저장되고 현재위치를 찾을 때 head -> develop -> cde456 단계를 거쳐서 현재 바라보는 commit id를 찾게 됩니다.
이번버전의 페이스를 브런치로 등록하지 않은 상태에서 이전버전으로 체크아웃하기위해서는 어떻게 해야하나용??
이남수 댓글 남겨주셔서 감사합니다. 체크아웃은 대상(target)을 branch, tag, commit id로 할 수 있어요.
“git checkout 커밋id” 이렇게요.
궁금하신 사항은 언제든지 물어보세요.