GW사전강좌: Step 2 - Git 명령어 local 에서 수행해보기

[SangHee Kim]

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

GW 사전학습의 두 번째 과정을 방금 유튜브에 올렸습니다. 아래 링크을 확인하세요~

(참고: 유튜브 자체에서 초반에 동영상 처리가 꽤 오래 걸립니다. 따라서 아래 링크로 들어가면 동영상이 보이지 않을 수 있으므로, 30분 정도 기다렸다가 다시 접속하시기를 바랍니다.)

- 동영상 학습 : http://youtu.be/DlLEKFmuD84

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

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

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

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

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

그럼!

[SangHee Kim]

오늘 동영상 강좌는 어제와 달리 '이해가 쉽게 가지 않는 부분' 이 많이 존재할 수 있습니다. 강좌를 따라해보고 궁금하거나 '나는 이렇게 생각한다' 하는 점은 GW 그룹스 'GW사전강좌: Step 2 - Git 명령어 local 에서 수행해보기 ' 에 올려주세요.

2013년 5월 7일 화요일 오후 9시 19분 54초 UTC+9, SangHee Kim 님의 말:

[SangHee Kim]

오늘 강좌에 나온 링크를 첨부합니다.

- http://git-scm.com/doc

- http://gitref.org

- http://www.gitguys.com/topics/whats-the-deal-with-the-git-index

더불어 index 의 효용성에 대한 링크도 첨부합니다. Index 에 대한 효용성 논란이 꽤 있습니다.

http://gitolite.com/concepts/uses-of-index.html

2013년 5월 7일 화요일 오후 9시 19분 54초 UTC+9, SangHee Kim 님의 말:

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

[Brian Moon]

동영상 중간에 수천개의 파일을 변경한 후 add, commit 한 사례를 이야기 했습니다. 한꺼번에 많은 파일을 변경하고 하나의 커밋으로 처리하는 방식이 좋지 않음은 직관적으로 이해가 됩니다. 통상 하나의 커밋안에 변경된 파일의 수는 얼만큼으로 관리하는 것이 효과적인지 궁금하네요.

이 궁금증이 든 이유는 아래 index 효용에 대한 링크 내용 중에 규모가 큰 변경 작업을 한 이후에 이를 몇 개의 커밋으로 나누어 반영하는 설명이 나와서 입니다. (staging helps you split up one large change into multiple commits)

2013년 5월 7일 화요일 오후 10시 15분 16초 UTC+9, SangHee Kim 님의 말:

[김성균 (KIM Sungkyun)]

저의 경우 git 을 접할 때 처음 부딪혔던 벽이 이번 강의에 나온 index(staging area, cache) 개념을 이해하는 것이었습니다. 이 개념이 잘 안잡히니 git의 여러 명령어들의 수행 결과를 정확히 파악하는 것이 어렵더군요.

상희님이 강의에서도 잘 설명해주셨지만, 소개하신 링크 중 마지막 글이 왜 index라는 것을 git에서 채용했는지를 잘 드러내는 글 같네요. 

어렵지 않은 영어라 직접 읽어보시는 게 제일 좋겠지만, 시간이 부족하신 분들도 있으실 것 같아 제가 거칠게 초벌 번역을 하였습니다. (아직은 하는 중, 오늘 중으로 마무리하겠습니다) 

다음 진도를 나가기 전에 꼭 읽어보시면 좋을 것 같습니다. 

Why the index/staging area is so useful 

http://gitolite.com/concepts/uses-of-index.html 

https://docs.google.com/document/d/1ts2e_c6_HrgNXQvKWlnFdTCKYcZsx9-8I4DADVhlR3g/edit?usp=sharing

2013년 5월 8일 오전 12:19, Brian Moon <ggm...@gmail.com>님의 말:

--
Google 그룹스 'git and workflows' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 git-and-workfl...@googlegroups.com에 이메일을 보내세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.
 
 

[Brian Moon]

@성균님, 번역 글 덕분에 index 개념을 좀 더 이해하는데 도움 받을 분들이 늘어날 것 같습니다.

git 사용법을 알려줄 때 다른 VCS(SVN, ClearCase 등) 사용법과 비교해가며 설명하면 더 좋지 않을까? 라고 지난 번에 상희님과 행아웃 때 잠시 이야기 나눴습니다.

상희님은 비교를 통한 이해보다 처음부터 새로 배운다는 생각으로 접근하는 것이 더 좋다는 의견이었습니다. 아마 index 개념이 이런 좋은 예가 될 듯 합니다. 이 개념을 다른 VCS와 비교해 이해하기 보다는 git 환경에는 이런 것이 있구나라고 이해하는 것이 덜 혼란스러울 듯 하네요.

마침 Git Reference 사이트에도 같은 권고를 하고 있네요. (http://gitref.org/)

HOW TO THINK LIKE GIT

The first important thing to understand about Git is that it thinks about version control very differently than Subversion or Perforce or whatever SCM you may be used to. It is often easier to learn Git by trying to forget your assumptions about how version control works and try to think about it in the Git way.

2013년 5월 8일 수요일 오전 4시 42분 31초 UTC+9, 김성균 님의 말:

[ddumbugie]

동영상은 보지 않았습니다.

제 경험은 변경된 파일의 수가 중요하지는 않으나, 논리적인 작업 단위로 쪼갤 수 있는 적당한 크기가 맞는 것 같습니다.

제가 최근에 작업한 작업을 예로 들면,

- 화면의 기본 구성 및 네비게이션 작업

- 관련 기능 #1 & 관련 TC #1 

- 관련 기능 #2 & 관련 TC #2

- 관련 TC #2의 수정 -> 요거는 --amend로 처리

- 커밋 후 코드가 cp949로 올라가는 것을 발견하고 패치...

이렇습니다.

저는 작업 논리 단위로 쪼개고, 동시에 여러개의 파일로 작업을 하더라도 커밋할 때에는 가능하면 쪼개서 커밋하고 하나의 커밋에는 하나의 설명가능한 변경들만 묶으려고 부단히 노력 중입니다.

2013년 5월 8일 수요일 오전 12시 19분 3초 UTC+9, Brian Moon 님의 말:

[ddumbugie]

더 대단한 것은, 한 파일의 부분적 변화만을 스테이지 하는 것도 가능하다. git gui의 오른쪽 페인에서 당신이 승인하려는 변화된 부분 위에 마우스 우클릭을 하고 “stage hunk”를 선택하라. (전체 파일이 아니라) 단지 그 부분만 이제 스테이지 되었다. 같은 파일 안에 언스테이지된 다른 변화들이 있다면 이제 그 파일이 두개의 왼쪽 페인들의 각가 위와 아래에 보이는 것을 알게 될 것이다.

요거는 안해봤네요.!! 설마하고 있다가 읽어보길 정말 잘한 것 같네요..

2013년 5월 8일 수요일 오전 4시 42분 31초 UTC+9, 김성균 님의 말:

저의 경우 git 을 접할 때 처음 부딪혔던 벽이 이번 강의에 나온 index(staging area, cache) 개념을 이해하는 것이었습니다. 이 개념이 잘 안잡히니 git의 여러 명령어들의 수행 결과를 정확히 파악하는 것이 어렵더군요.

[SangHee Kim]

하나의 커밋은 하나의 작업 단위라고 보통 말하는데 여기서 말하는 '작업 단위' 라는 말이 애매합니다. 그래서 하나의 커밋을 만들고 나서 아래와 같은 잣대를 이용해보면 좋은것 같습니다.

a. 하나의 기능만 추가되었나? (기능적, 논리적)

b. 커밋을 누군가에게 설명 할 때 명백하게 설명할 수 있는 단위인가? (너무 크다면 리뷰어가 상당히 힘들어합니다. 설명도 어렵고)

c. 독립적으로 빌드는 되는가? (예. b 라는 커밋을 빌드하려면 a도 필요합니다. a-b 라면 a와 b를 합친다)

d. 독립적으로 작동은 하는가?

e. 테스트에 문제를 주지 않는가?

예전에 AOSP (Android Open Source Project) Gerrit 에 모 전자회사에서 커밋을 하나 했는데 그 커밋 안에는

- 총 네 줄의 변경사항이 들어있었음

- 위에 있는 두 줄은 a라는 기능, 아래 있는 두 줄은 b 라는 기능이였음

- 구글에서는 커밋을 둘로 나누고 다시 테스트 해서 올리라고 함

위와 같은 예도 있었습니다.

2013년 5월 8일 수요일 오전 12시 19분 3초 UTC+9, Brian Moon 님의 말:

동영상 중간에 수천개의 파일을 변경한 후 add, commit 한 사례를 이야기 했습니다. 한꺼번에 많은 파일을 변경하고 하나의 커밋으로 처리하는 방식이 좋지 않음은 직관적으로 이해가 됩니다. 통상 하나의 커밋안에 변경된 파일의 수는 얼만큼으로 관리하는 것이 효과적인지 궁금하네요.

[SangHee Kim]

저 문서를 읽어서 하나라도 수긍이 간다면 index 에 가치를 두고 사용할 수 있을것 같습니다. 개인적으로는

- 리뷰를 몇 번 더 하거나

- 작업을 나눌 수 있는

이점이 있다는 것이 좋았습니다. 만약 필요 없다면 alias 기능을 이용해서 git add -A; git commit 을 한꺼번에 수행하는 명령어를 만들면 되겠죠.

2013년 5월 8일 수요일 오전 4시 42분 31초 UTC+9, 김성균 님의 말:

저의 경우 git 을 접할 때 처음 부딪혔던 벽이 이번 강의에 나온 index(staging area, cache) 개념을 이해하는 것이었습니다. 이 개념이 잘 안잡히니 git의 여러 명령어들의 수행 결과를 정확히 파악하는 것이 어렵더군요.

[김정훈]

우선 저같이 영어가 서투른 사람을 위해 번역을 해주신 성균님께 감사드립니다.

저도 동영상을 보다가 index가 왜 필요하지?라고 갑자기 생각이 들어서 이 쓰레드를 뒤져보게 되었습니다.

수정된 내용을 기능에 따라 여러개의 커밋으로 나눌 때에도 SVN에서처럼 커밋단계에서 나눠서 커밋하면 되지 않나 싶은 생각이 들어서

아직까지 딱 와닿진 않습니다. 다만 stage hunk는 저도 모르던 내용인데 괜찮은 기능 같습니다. 

저는 mac에서 SourceTree라는 GUI툴을 쓰는데 전에는 눈여겨보지 않았는데 수정사항이 부분별로 나눠져있고 stage hunk버튼을 누르면

해당부분만 스테이징이 되게 되어 있네요.(Discard hunk 라는 것도 있네요)

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

[SangHee Kim]

말씀하신데로 애초에 커밋을 나눠서 작업하면 됩니다. 다만 작업을 하다보면 하나의 커밋을 해체하는 경우가 생기게 되는데요 (예. 테스트 등) 이때 index 는 일종의 '좋은 작업대' 역할을 해줍니다. 말씀하신 stage hunk 가 좋은 예가 되겠네요.

덧. 제가 이 워크샵의 이름을 git and workflows 라고 지은 이유가 하나 있는데 그 이유는 git 명령어만 배운다고 해서 git 이 이해가 가지는 않고 오히려 어떤 면들은 어색하기 짝이 없습니다. git 에 맞는 workflow 들을 익혀가야만 git 을 이해할 수 있습니다. 그래서 git and workflows 라고 한거에요~

2013년 5월 9일 목요일 오전 11시 56분 10초 UTC+9, 김정훈 님의 말:

[ddumbugie]

실제로 해봤고, 동료들에게 알려줬는데, 눈의 휘둥그레졌습니다.

(오늘 못가게 되어서 정말 죄송합니다.)

2013년 5월 9일 목요일 오후 2시 46분 20초 UTC+9, SangHee Kim 님의 말: