GW사전학습: Step 3. Git branch, gitk and merge

[SangHee Kim]

안녕하세요. 김상희입니다.

GW 사전학습의 세 번째 과정을 방금 유튜브에 올렸습니다. 이번 단계는 두 파트로 나뉘어져 있습니다. (총 37분)

1. step 3-1 (전편) : git branch 및 gitk 의 이해 :http://youtu.be/18r-pHvs7E8

2. step 3-2 (후편) : git merge 기본 및 conflict 데모 : http://youtu.be/3KOTRd17Hoo

특히 두 번째 강좌에서 conflict 데모는 추후 강좌에서 자세한 설명과 함께 진행할 예정이니 한번 쭈욱 본다는 생각으로 진행하시면 되겠습니다.

동영상 학습 후 아래와 같이 해주시면 좋겠습니다.

1. 현황판 업데이트 : http://goo.gl/CAY3C

2. 궁금한 것이 있다면 여기에 질문을 올려주기 (or 피드백이 있다면 이야기 주세요)

더 자세한 참여방법은 아래 링크를 확인하세요.

- GW 학습 방법에 관하여 : 여기부터 시작하세요~ : http://goo.gl/UZXuO

그럼!

[Brian Moon]

Fast forward 머지 케이스에서 머지 후에 topic branch 제거했는데, recursive 머지 케이스에서는 머지 후에 topic branch 제거하지 않았습니다.

따로 어떤 기준이 있는지 궁금하네요. 이전 회사에서 사용하던 VCS 및 workflow에서는 한번 만든 branch를 삭제하는 일은 드물었습니다.

Branch 생성 비용 만큼 삭제 비용도 컸고, 나중에 작업 이력을 검토할 목적으로 남겨놨던 것으로 기억합니다.

덧글: 여전히 gitk가 보여주는 그래프는 직관적으로 이해하기 어렵네요.

2013년 5월 8일 수요일 오후 8시 12분 46초 UTC+9, SangHee Kim 님의 말:

[SangHee Kim]

안녕하세요.

2013년 5월 9일 목요일 오전 9시 0분 41초 UTC+9, Brian Moon 님의 말:

Fast forward 머지 케이스에서 머지 후에 topic branch 제거했는데, recursive 머지 케이스에서는 머지 후에 topic branch 제거하지 않았습니다.

따로 어떤 기준이 있는지 궁금하네요. 이전 회사에서 사용하던 VCS 및 workflow에서는 한번 만든 branch를 삭제하는 일은 드물었습니다.

Branch 생성 비용 만큼 삭제 비용도 컸고, 나중에 작업 이력을 검토할 목적으로 남겨놨던 것으로 기억합니다.

어떠한 브랜치를 머지한 후에는 해당 브랜치를 제거해도 되고 안해도 상관 없습니다. 즉, 동영상 예제에서는 궁금증 유발 차원에서 하나는 지워보고 하나는 지우지 않았습니다. 기준은

- 이 브랜치가 계속 필요한가?

정도로 생각하면 됩니다. Git 은 브랜치 생성 및 삭제 비용이 상당히 작기도 하거니와 FF 머지가 아닌 경우에는 하나의 브랜치를 기준으로 머지한 경우에는 머지 커밋에 '어느 브랜치를 머지했다' 고 커밋 메시지로 남기 때문에 딱히 이력 검토를 위해 남길 필요도 없습니다.

즉, master, release 등의 주요 브랜치는 지우면 안되겠죠. 그러나 topic 같은 일회성 브랜치들은 적절한 시기에 지워주면 됩니다. (예. 머지 완료 후, 테스트 완료 후, 릴리즈 완료 후)

 

덧글: 여전히 gitk가 보여주는 그래프는 직관적으로 이해하기 어렵네요.

저도 처음에는 gitk 의 문제인줄 알았습니다. 그런데 두 가지 펙터때문에 이해가 어려웠다고 생각합니다.

a. git 에서 사용하는 컨셉과 구조가 아직 익숙하지 않아서

b. gitk 모양새가 약간 조악해서

저는 예전에 ClearCase 를 사용했는데 (4년 정도) 거기 history 그래프도 처음에 약간 보기 어려웠던걸로 기억합니다. 자주 써보시면 딱 문제는 없습니다. 더불어 개인적으로 gitk 기준으로 학습을 해야 한다고 생각하는 이유는

- gitk 는 git 개발 환경 어디에서든지 사용할 수 있기 때문이다

정도가 아닐까 합니다. 다른 대체툴을 사용하면 남의 자리에 가서 작업을 도와줄 때 항상 새로운 툴을 깔아야 하거든요. ㅋㅋ

[Brian Moon]

사실 제가 제일 오랫동안 사용해 본 VCS는 ClearCase라서 그 때 기억을 더듬어 봤습니다.

ClearCase 버전 트리는 파일 또는 디렉토리 개별로 볼 수 있었습니다. 각 버전은 동그라미로 표시되고 머지된 버전 사이에는 빨간색 화살표를 표시해 줬습니다. (이 부분 가시성이 좋았던 것 같네요.)

그리고 상희님 코멘트를 보고 생각하니 브랜치를 남겨뒀던 이유는 check-in 하면서 코멘트를 자세히 남기지 않아서 였던 것 같습니다.

브랜치가 파일 또는 디렉토리 단위로 붙게되고, 이 브랜치 이름을 통해서 변경된 파일 또는 디렉토리 목록을 찾아 실제 변경된 내용을 비교할 목적으로 남겨놨던 셈이죠.

2013년 5월 9일 목요일 오전 9시 52분 23초 UTC+9, SangHee Kim 님의 말:

[SangHee Kim]

안녕하세요.

오랜만에 CC의 저 '눈동자' (view 마크) 를 보게되네요. 저는 저 눈을 보면서 '서양 여자겠다.' 라는 생각을 했었습니다. 제 경우 익숙함의 차이라고 생각합니다. 왜냐하면 저는 저 CC 의 버전 트리가 그때도 그리고 지금도 gitk 보다 산만해 보이더라구요. 한번 쭉 써보시고 한 달 뒤에 다시 한 번 생각해 보시면 좋겠습니다.

참고로 CC의 버전 트리를 처음 썼을때는 어떠셨나요?

덧. $ gitk [파일이름] 이라던가 $ gitk [폴더이름] 같은것도 한번 해보세요. gitk 에 의외로 필요한 기능들은 다 있답니다.

2013년 5월 9일 목요일 오전 10시 16분 1초 UTC+9, Brian Moon 님의 말: