[링크] http://ljs93kr.tistory.com/44

[링크] http://ljs93kr.tistory.com/43

안녕하세요. 오늘도 신선한 '기업 커뮤니케이션' 관련 소식을 전해드리러 온 정은킴입니다 :D

여러분들은 업무를 볼 때 팀원들과 의견을 나누고, 파일을 공유하기 위해 어떤 '메신저' 를 사용하시

나요? 이번 주, 혹은 다음 주에 해야 할 업무와 계획 등을 효과적으로 관리해주는 'To do list' 로는 

어떤 것을 사용하고 계신가요? 우리는 이렇게 우리의 업무를 보다 빠르게, 성공적으로 마치기 위해

다양한 '비즈니스 커뮤니케이션 툴'을 사용하고 있습니다.

'비즈니스 커뮤니케이션 툴' 시장은 최근 몇 년 사이 비약적으로 성장해 좀 더 특별한 강점을 내세운 다양한 도구들이 출시되고 있습니다. 특히 업무를 볼 때, 내가 '해야 할 일'을 효과적으로 관리해주는 GTD(Getting Things Done) 기반의 '할 일' 관리 툴은 요즘 같이 각자의 업무가 많아지고, 복잡한 

업무 상황 속에서 모든 직장인들에게 꼭 필요한 툴이라고 볼 수 있습니다. 이미 해외 시장을 비롯, 

국내에서도 다양한 '업무 관리 툴'들이 등장하고 있는데, 그래서 저는 오늘부터 매주 화요일마다 

'비즈니스 커뮤니케이션 툴'에 대해 하나씩 살펴보는 특집 기사를 포스팅 하려고 합니다. 

지난 8월, 사진 공유 사이트로 유명한 '플리커(flikr)'의 공동 창업자인 스튜어트 버터필드가 업무용 

커뮤니케이션 툴인 '슬랙(slack)'을 공개했습니다. 슬랙은 '느슨한, 늘어진'이라는 의미로, 과중한 

업무를 한 시라도 빨리 처리하려는 현대인들에게 슬랙을 사용함으로써 '느슨한' 여유를 가질 수 있게

하자는 뜻을 내포하고 있습니다. 사용자들은 웹을 포함해 모바일에서도 슬랙을 사용할 수 있는데, 웹에서든, 모바일에서든, 동일한 환경으로 쉽게 슬랙을 사용할 수 있어 언제, 어디서든 사용자의 업무 

반경을 넓혀줍니다. 그럼 이제, 슬랙만이 가지고 있는 색깔을 확인해볼까요?

《 '느슨한' 여유를 가지다 》

[Good Point] 저는 이번에 슬랙을 체험하면서 슬랙이 가지고 있는 많은 기능들 중, 특히 자주 사용

했던 두 가지 기능이 있습니다. 그 첫 번째 기능은 바로 '파일 전송' 기능입니다. 슬랙은 웹에서든 

모바일에서든 자유롭게 대화를 나눌 수 있는 메신저 기반의 '비즈니스 커뮤니케이션 툴'인데요, 이

성격에 맞춘 슬랙의 파일 전송 기능은 사용자들이 쉽고 빠르게 다양한 업무용 파일을 공유할 수 

있게 해줍니다. 웹에서 슬랙을 실행했을 때, 웹 브라우저 창의 왼쪽 영역에서는 팀원들과 대화를 

나누는 동시에, 오른쪽 영역에서는 내가 보냈거나, 찾고자 하는 파일을 바로 찾을 수 있습니다. 

또한, 파일의 제목과 확장자명 등으로도 쉽게 파일 검색이 가능하고, 이미지나 PDF 등이 파일 속성 별로도 내가 찾고자 하는 파일을 바로 찾을 수 있습니다. 아이디어 회의 같은 간단한 회의를 슬랙에서 진행했을 때, 팀원들과 대화를 나누며 다양한 이미지나 업무와 관련된 기사를 공유할 수 있어 편리합니다. 슬랙의 '파일 전송' 기능은 모바일에서도 동일한 구성으로 이용할 수 있어서 사용자들이 

웹과 모바일 등의 디바이스에 상관 없이 쉽게 사용하기 좋습니다. 내가 찾고자 하는 파일의 속성과 제목 등을 검색할 수 있는 세부 검색 아이콘도 상단바에 달려 있어 사용자들의 눈에 익숙합니다.

슬랙은 '비즈니스 커뮤니케이션 툴'답게 업무의 흔적을 남길 수 있는 기능이 존재합니다. 제가 두 번째로 많이 사용했던 '별표 대화(Starred Items)' 기능인데요, 상대방의 아이디 옆에 있는 별 모양

을 누르면, 해당 대화가 별표 처리되어 웹 브라우저의 오른쪽 영역에서 별표 친 대화만 골라서 볼 수 있습니다. 다른 팀과의 협조가 필요한 업무를 진행하거나, 상사의 중요 공지 사항을 한 데 묶어서 볼 수 있어서 편리합니다. 이 기능은 내가 어떤 대화창에서 업무와 관련해 어떻게 말했는지 확인할 수 있기 때문에 향후 업무 상 커뮤니케이션에 문제가 생겨 '나'와 상대방이 어떻게 대화를 나누고, 어떤 방식으로 업무를 처리하기로 했는지 확인할 수 있습니다. 이는 곧 서로간의 업무 기록이 되어 보다 책임감있게 업무를 처리할 수 있는 작은 도움이 되기도 합니다. 

[Bad Point] 슬랙은 '웹 메신저'의 성격을 띄는 업무 관리 도구인만큼, 왠만한 기능 사용에 있어서 

모든 사용자가 동일하게 쓸 수 있습니다. 하지만, 대화방 생성을 아무나 할 수 있고, 각 대화방의 

주제를 설정하는 것도 권한에 상관 없이 바꿀 수 있는 점은 보안에 민감한 회사들이 사용하기에 적당

한 것 같지 않습니다. 또, 대화방 및 파일함 내에 너무 많은 아이콘과 텍스트(첨부 파일 설명 문구, 

댓글 문구)들이 있어 화면이 정돈되어있지 않다는 느낌이 드는 것도 슬랙이 가진 단점이라고 할 수 있겠습니다.

《 '친절함'을 입히다 》

[Good Point] 슬랙은 타 업무 관리 도구와는 다르게, 세세한 기능에도 신경을 많이 써 사용자들이 

최대한 많은 기능들을 많이 써볼 수 있도록 했습니다. 그래서 사용자들이 많이 클릭하는 메뉴 세 개의 하위 메뉴에 'Help&Feedback'이라는 도움말 기능을 넣어 사용자들이 느낀 불편함을 곧바로 찾을 수 있도록 배려했습니다.

사실 슬랙과 비슷한 업무 관리 도구들을 보면, 도움말 기능이 환경설정 메뉴에만 있거나 그 제품의 

해당 홈페이지로 이동해야 도움말을 볼 수 있는데, 슬랙은 세 곳에 있는 주 메뉴에 도움말 기능을 

동일하게 둠으로써 어떤 기능을 사용하더라도 사용자가 도움말을 접할 수 있는 빠른 환경을 제공합니다.

여러분, 여러분들께서는 현재 사용하고 있는 웹메신저를 처음 사용했을 때를 기억하시나요? 상대방과 대화를 나누려면 어떤 아이콘을 눌러야 하고, 어떤 버튼을 눌러야 파일이 전송되는지 조금은 헤매셨을 것입니다. 하지만, 슬랙에서는 사용자가 처음 슬랙을 실행했을 때부터 헤매지 않게 도와주는 '친절한' 기능이 있습니다. 이 기능은 슬랙의 주요 메뉴 세 곳(대화방 개설, 사용자 정보, 대화 전송)에서 '살아 움직이는' 버튼으로 사용자들의 시선을 끕니다. '살아 움직이는' 동그라미 모양의 이

버튼은 사용자가 해당 메뉴를 누를 때까지 계속 움직입니다. 사용자들은 무심코 이 버튼을 눌렀다가

해당 메뉴를 어떻게 사용해야 하는지 학습하게 되는데, 해당 메뉴를 설명해주는 도움말을 읽고 난 후

'Done(마침)'이라는 버튼을 클릭하지 않으면 계속 움직이는 버튼이 사용자의 주의를 끕니다.

이 버튼은 사용자들에게 슬랙의 다양한 메뉴를 어떻게 사용하는지 익혀두고, 이를 업무 관리에 곧바로 도입할 수 있도록 했습니다.

슬랙은 웹메신저를 기반으로 하는 '업무 관리 도구'로서 특별한 기능이 하나 있습니다. 그것은 바로 '대화 내용 수정' 기능입니다. 이 기능에서는 상대방과 대화를 나눈 후, 내가 했던 대화 내용을 수정할 수 있는데, 타 웹메신저에서는 찾아볼 수 없는 특이한 기능입니다. 저는 처음에 이 기능을 써보 

고 의문이 들었습니다. 왜냐하면, 나중에 내 마음대로 대화 내용을 수정할 수 있기 때문입니다.  

사용자들은 수정하고 싶은 자신의 대화의 '설정' 아이콘을 누른 뒤, 'edit' 메뉴로 들어가 곧바로 

해당 대화 내용을 수정할 수 있습니다. 이렇게 대화 내용 수정이 끝나면 해당 대화 옆에 'edited'라는 문구가 뜨면서 언제 대화 내용을 수정했는지 날짜와 시간까지 구체적으로 확인할 수 있습니다. 

제가 슬랙에서 발견한 또 다른 '친절함'은 사용자의 프로필을 설정해주는 '슬랙봇'에서 찾을 수 있었습니다. 슬랙봇은 사용자의 대화자 리스트 내, 첫 번째로 위치하고 있는데 처음 슬랙을 쓰는 사용자 

들과 1:1로 대화를 하는 형식으로 사용자의 프로필을 설정할 수 있도록 도와줍니다. 이름을 비롯, 부서명, 프로필 사진 등을 슬랙봇과 대화하면서 입력할 수 있어 재미있게 프로필 설정을 할 수 있습니다. 웹 브라우저의 오른쪽 영역에서도 친절한 슬랙봇을 만날 수 있습니다.

[Bad Point] 제가 이번에 슬랙을 체험하면서 가장 아쉬웠던 점은 한국어 지원이 안 된다는 것이었습니다. 사용자 이름 및 닉네임, 대화방 이름까지 영어로만 설정이 가능해 조금 불편합니다. 물론 우리나라에 정식 출시되거나, 한국어 버전이 나온다는 말은 없지만, 우리나라의 '업무 관리 툴' 시장도 

더욱 넓어지고 있는 만큼 더 많은 사람들이 슬랙을 많이 사용해봄으로써 우리나라의 색깔에 맞는 

'업무 관리 툴'이 출시되었으면 좋겠습니다.

또 다른 슬랙의 단점으로는 IE(Internet Explorer)에서는 슬랙을 사용할 수 없다는 것입니다. 이 점은

슬랙이 가진 최대의 단점이라고 볼 수 있는데, 특히 우리나라에서는 IE를 기본 웹브라우저를 설정해

인터넷을 사용하는 사람들이 77%에 달하기때문입니다. (자료 출처: StatCounter, 10월 기준)  

IE에서 슬랙을 실행해서 메시지를 입력하고, 엔터를 누르는 순간 연결이 되지 않았다는 메시지가 

뜹니다. 사용자는 분명히 슬랙에 로그인되어있는데도, 슬랙은 오프라인 상태로 인식합니다. 크롬

이나 파이어폭스 등의 다른 웹브라우저들을 사용하지 않는 사람들에게는 큰 불편함을 초래할 것 같네요.

여러분, 슬랙을 자신의 회사에 도입한 고객들은 3일 만에 이메일 수신량이 75%나 감소했다는 놀라운 결과를 얻었다고 합니다. 그만큼 시간이 오래 걸리고 불필요한 이메일 업무를 깔끔하게 정리해

준 '착한' 도구가 되었다는 뜻이겠죠? 과연 슬랙은 점점 더 치열해지고 있는 '비즈니스 커뮤니케이션 툴' 시장에서 선두 자리를 차지할 수 있을까요? 마냥 '착한' 도구로만 있기에는 '비즈니스 커뮤니케이션 툴' 시장은 너무 냉정합니다.

[출처] http://blog.mailplug.com/391

처음에는 Rebase를 왜 해야 하고 언제 어떻게 해야 하는지 좀 헷갈린다. 헷갈리는 이유는 정답이 없고 미묘함이 있어서인데 그래도 대략적인 가이드가 있으면 좋겠다 싶어서 정리해보았다.

Social Coding Platform

svn이나 다른 VCS 도구 말고 git을 사용해야 하는 이유는 커뮤니케이션이다. 개발이라는 작업은 혼자 하는 게 아니라서 코드를 공유하고, 리뷰하고, 피드백을 받아야 하는데 Git으로 하면 일이 좀 쉬워진다(Git이 쉽다는 것은 아니다).

git과 github의 인기는 VCS 본연의 기능뿐만 아니라 커뮤니케이션을 원활하게 할 수 있는 플랫폼이 함께 필요하다는 것을 보여준다. git은 소스관리에도 뛰어난 도구지만 그게 Git만의 장점은 아니다.

git은 단순히 VCS가 아니다. 소스관리뿐만 아니라 커뮤니케이션에 필요한 모든 것이 들어 있다. 특히 코드를 공유하는 것은 정말 끝내 준다. Git 이외에 필요한 도구가 별로 없다. 나는 히스토리를 엉망으로 관리하는 프로젝트을 살펴보고자 gitx를 가끔 사용하고 차이를 살펴보고자 diffmerge를 아주 가끔 사용한다. 정말 아주 가끔이다. 한 달에 한 번도 실행하지 않는다.

그 외에는 항상 콘솔에서 작업한다. git은 아직도 발전 중이고 코드를 쉽게 공유하는 방법이 계속 통합될 것으로 생각한다. git에는 정말 필요한 모든 것이 통합되고 있어서 언젠가 git으로 문자 메시지로 코드를 보낼 수 있는 날이 올지도 모른다는 상상을 하고 있다.

배려

동료는 그녀와 같다. 배려 없이 초대에 응하는 그녀는 없다. 최대한 친절을 베풀어야 그녀를 내 저장소로 초대할 수 있다. 공포를 조장하거나 무턱대고 돈만 살포해서는 진심을 이끌어 낼 수 없다. 스스로 응할 때까지 배려하고 인내해야 한다.

코드는 당연히 잘 짜야 한다. 버그는 없을수록 좋고, 주석은 간략하고 명확해야 하고, 변수나 함수이름, 파일이나 디렉토리 구조나 이름 등등…. 중요하지 않은 것이 없다. 좋은 글에는 좋은 문장도 많은 법이다.

git도 마찬가지다. 변수 이름을 잘 짓듯이 브랜치 이름도 잘 지어야 한다. 커밋 메시지도 표준 포멧에 따라 잘 지어야 한다. 그리고 히스토리도 예쁘게 만들어야 한다.

Merge vs Rebase

Rebase는 히스토리를 단장하는 데 필요하다. 나 혼자 쓰는 저장소에서도 Rebase가 없으면 지저분해서 히스토리를 읽을 수가 없다.

잘 정리한 히스토리를 엿보고 싶다면 npm 저장소를 구경해보는 것이 좋다. @izs님은 완전 git타쿠:

히스토리가 정말 보기 좋다. github의 'pull request'도 사용하지 않고 죄다 손으로 Merge하는 것 같다.

커밋 vs Merge 커밋

Merge와 Rebase를 살펴보기 전에 커밋부터 다시 살펴보자.

커밋은 의미의 단위다. 지금 하는 일을 적당하게 한 조각으로 나눠서 커밋한다. 10줄, 100줄처럼 정량적인 단위가 아니다. 고기를 사듯이 '커밋 한 근 주세요.'라고 말할 수 없다. 커밋 하나는 의미 하나다.

커밋 하나하나에도 의미가 있지만 어떤 모듈을 개발한다면 여러 개를 하나로 묶어서 처리할 필요도 있다. 그러니까 여러 개의 커밋을 묶음으로 표현할 수 있는 커밋이 필요하다. 그게 Merge 커밋이다. Merge 커밋은 일종의 커밋 묶음이다

npm 저장소에 @izs님이 만들어 놓은 Merge 커밋을 보자:

1ecd0eb는 gyp를 구현한 커밋들을 묶어 놓은 Merge 커밋이다. gyp 브랜치를 만들어 gyp를 구현하고 master 브랜치로 Merge했다.

Merge 커밋은 사실 커밋 묶음 나타내는 것이 아니다. 보통 커밋은 Parent가 하나인데 Merge 커밋은 Parent가 여러 개다. 하지만, Parent가 여러 개인 점을 이용해서 커밋 묶음으로 다룰 수 있다:

C6는 Merge 커밋으로 Parent가 두 개다.

Merge 커밋을 Reset하면 관련 커밋이 전부 Reset된다:

C3와 C5가 같이 Reset되기 때문에 master 입장에서는 커밋 묶음이 Reset된 것이다.

npm 저장소에서 master 브랜치가 Merge 커밋인 1ecd0eb를 가리키는 상태에서 'HEAD~1'으로 Reset하면 gyp 브랜치가 통째로 Reset된다. 그래서 master는 c4eb2fd를 가리킨다.

Merge vs Rebase

다음과 같은 브랜치를 Merge, Rebase해보고 그 결과를 비교해보자:

git merge iss1 명령으로 iss1를 Merge한다. 노란색인 C1은 Merge Base이다:

git merge iss2 명령으로 iss2를 Merge한다:

git merge iss3 명령으로 iss3를 Merge한다:

iss1, iss2, iss3를 Merge 했다. C9, C10, C11은 Merge 커밋이다. 이 그림에서는 히스토리가 복잡하지 않다고 생각할 수 있지만, 이정도 되는 내용도 콘솔에서 보면 헷갈린다. 한눈에 들어오지 않는다. 이제 Rebase 후 Merge해보자.

헷갈릴 수 있으니 원본 브랜치를 다시 한번 보고:

git checkout iss1과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C1이 아니라 C4가 된다:

git checkout master과 git merge iss1를 차례대로 실행해서 Merge한다. Rebase를 하면 항상 Fast-Forward Merge가 가능해진다. 하지만, 무턱대고 Fast-Forward Merge를 하는 것이 아니라 앞서 얘기했듯이 커밋을 묶음으로 관리하고 싶지 않을 때만 Fast-Forward Merge한다. 이 경우는 커밋이 하나이므로 그냥 Fast-Forward Merge한다:

git checkout iss2과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3가 아니라 C2'가 된다:

git checkout master과 git merge --no-ff iss2를 차례대로 실행해서 Merge한다.--no-ff 옵션은 강제로 Merge 커밋을 남기려고 주는 것이다. iss2 브랜치는 커밋이 두 개고 이 커밋은 iss2를 처리한 결과이므로 커밋 묶음으로 처리하는 것이 낫다(물론, 내용상 --no-ff 옵션을 주는 게 틀릴 수도 있다.):

git checkout iss3과 git rebase master를 차례대로 실행해서 Rebase한다 그러면 Merge Base가 C3에서 C9이 된다:

git checkout master과 git merge --no-ff iss3를 차례대로 실행해서 Merge한다:

다음 그림은 위에서 Rebase 없이 Merge한 결과다. 한번 비교해보자:

Rebase를 하고 나서 Merge한 것이 훨씬 보기 좋다. 아무리 복잡한 과정을 거쳤어도 한눈에 들어오게 할 수 있다.

마치며

Git처럼 히스토리를 다중으로 관리하는 시스템에서 Rebase는 필수다. Mercurial도 Git의 영향을 받아 Rebase를 지원한다. 이글에서는 Rebase가 왜 필요하고 언제 어떻게 해야 하는지 알아봤다.

UPDATE: 20121122

Merge Commit은 Commit을 묶음으로 관리하는데도 유용하지만 Release Note에 넣을 만한 것을 미리 Merge Commit으로 만들어 놓으면 편리할 것 같다. 배포할 때 Merge Commit만 추려볼 수 있으니 Release Note를 따로 작성하지 않아도 된다.

6.6 Git 도구 - 서브모듈

$ git submodule add git://github.com/chneukirchen/rack.git rack
Initialized empty Git repository in /opt/subtest/rack/.git/
remote: Counting objects: 3181, done.
remote: Compressing objects: 100% (1534/1534), done.
remote: Total 3181 (delta 1951), reused 2623 (delta 1603)
Receiving objects: 100% (3181/3181), 675.42 KiB | 422 KiB/s, done.
Resolving deltas: 100% (1951/1951), done.

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#      new file:   .gitmodules
#      new file:   rack
#

$ cat .gitmodules
[submodule "rack"]
      path = rack
      url = git://github.com/chneukirchen/rack.git

$ git diff --cached rack
diff --git a/rack b/rack
new file mode 160000
index 0000000..08d709f
--- /dev/null
+++ b/rack
@@ -0,0 +1 @@
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433

$ git commit -m 'first commit with submodule rack'
[master 0550271] first commit with submodule rack
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 rack

$ git log -1
commit 0550271328a0038865aad6331e620cd7238601bb
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Apr 9 09:03:56 2009 -0700

    first commit with submodule rack
$ cd rack/
$ git log -1
commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433
Author: Christian Neukirchen <chneukirchen@gmail.com>
Date:   Wed Mar 25 14:49:04 2009 +0100

    Document version change

$ git clone git://github.com/schacon/myproject.git
Initialized empty Git repository in /opt/myproject/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
$ cd myproject
$ ls -l
total 8
-rw-r--r--  1 schacon  admin   3 Apr  9 09:11 README
drwxr-xr-x  2 schacon  admin  68 Apr  9 09:11 rack
$ ls rack/
$

$ git submodule init
Submodule 'rack' (git://github.com/chneukirchen/rack.git) registered for path 'rack'
$ git submodule update
Initialized empty Git repository in /opt/myproject/rack/.git/
remote: Counting objects: 3181, done.
remote: Compressing objects: 100% (1534/1534), done.
remote: Total 3181 (delta 1951), reused 2623 (delta 1603)
Receiving objects: 100% (3181/3181), 675.42 KiB | 173 KiB/s, done.
Resolving deltas: 100% (1951/1951), done.
Submodule path 'rack': checked out '08d709f78b8c5b0fbeb7821e37fa53e69afcf433'

$ git merge origin/master
Updating 0550271..85a3eee
Fast forward
 rack |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
[master*]$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#      modified:   rack
#

$ git diff
diff --git a/rack b/rack
index 6c5e70b..08d709f 160000
--- a/rack
+++ b/rack
@@ -1 +1 @@
-Subproject commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
+Subproject commit 08d709f78b8c5b0fbeb7821e37fa53e69afcf433

$ git submodule update
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 2 (delta 0)
Unpacking objects: 100% (3/3), done.
From git@github.com:schacon/rack
   08d709f..6c5e70b  master     -> origin/master
Submodule path 'rack': checked out '6c5e70b984a60b3cecd395edd5b48a7575bf58e0'

$ git submodule update
fatal: reference isn’t a tree: 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Unable to checkout '6c5e70b984a60b3cecd395edd5ba7575bf58e0' in submodule path 'rack'

$ git log -1 rack
commit 85a3eee996800fcfa91e2119372dd4172bf76678
Author: Scott Chacon <schacon@gmail.com>
Date:   Thu Apr 9 09:19:14 2009 -0700

    added a submodule reference I will never make public. hahahahaha!

$ git checkout -b rack
Switched to a new branch "rack"
$ git submodule add git@github.com:schacon/rack.git rack
Initialized empty Git repository in /opt/myproj/rack/.git/
...
Receiving objects: 100% (3184/3184), 677.42 KiB | 34 KiB/s, done.
Resolving deltas: 100% (1952/1952), done.
$ git commit -am 'added rack submodule'
[rack cc49a69] added rack submodule
 2 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100644 .gitmodules
 create mode 160000 rack
$ git checkout master
Switched to branch "master"
$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#      rack/

$ rm -Rf rack/
$ git submodule add git@github.com:schacon/rack.git rack
'rack' already exists in the index

$ git rm -r rack
$ git submodule add git@github.com:schacon/rack.git rack
Initialized empty Git repository in /opt/testsub/rack/.git/
remote: Counting objects: 3184, done.
remote: Compressing objects: 100% (1465/1465), done.
remote: Total 3184 (delta 1952), reused 2770 (delta 1675)
Receiving objects: 100% (3184/3184), 677.42 KiB | 88 KiB/s, done.
Resolving deltas: 100% (1952/1952), done.

$ git checkout master
error: Untracked working tree file 'rack/AUTHORS' would be overwritten by merge.

$ mv rack /tmp/
$ git checkout master
Switched to branch "master"
$ ls
README  rack

출처 : http://git-scm.com/book/ko/v1/Git-%EB%8F%84%EA%B5%AC-%EC%84%9C%EB%B8%8C%EB%AA%A8%EB%93%88

[추가]

해놓고 보니 암호는 안넣고 편한 것 같긴한데..

작업관리자에 있는 Plink가 무슨짓을 하는지 Commit/Fetch/Pull/Push 등 서버와 통신이 필요한 짓을 하려고 하면 얼어버린 것 처럼 보일정도로 느려지는 현상이 생겨서 SourceTree를 껐는데도 컴퓨터 자체가 느림..

그래서 Plink를 끄니깐 그때서야 제 속도로 돌아왔다.

결국 그냥 OpenSSH로 쓰고 필요할 때 암호 넣는걸로 돌렸다.

암호 하나 안넣으려고 컴퓨터가 엄청 느려지는 걸 감수하기에는..;;

참조 : SourceTree for Windows with SSH key files 

잡설 

어쩔수 없이 회사에서 리눅스에 gitolite를 설치하고 윈도우 클라이언트에서 작업을 해야했다. 모든 것이 다 진행되다가 마지막에 가장 큰 문제점으로 나타난게 있다. ssh-key를 사용하여 비밀번호 없이 git에 접근 되게 설정을 해놨지만, 계속해서 Password를 요구하는 팝업 창이 나타났다. 삽을 들고 구글링을 해보았지만 제대로 나오는건 없었다. 그래서 포기하고 SVN으로 설정을 마치고 혹시나 하는 마음에 다시 삽을 들었는데 해결책은 정말 간단하였다. 

Private Key가 어디에서 사용되는지 몰라서 이것이 문제이겠거니라고 추측은 하고 있었는데 '어려운' 윈도우 때문에 알지 못했다. .ssh/ 가 있다면 참 좋을텐데. 

해결방법

해결책은 아주 간단하다. 우선 아래 그림과 같이 일단 PK를 PuTTY에서 만들거나, 아니면 ssk-keygen에서 만들어 진 키를 PuTTY 키로 변환을 한다. 

그리고 윈도우의 오른쪽 하단에서 pageant 에서 View Keys를 클릭한뒤, "Add Key" 버튼을 클릭해서 PK 를 추가하면 끝이다. 

그러면 아래와 같이 password 입력 팝업창이 뜨지 않고 ssh-key로 접속이 잘되는 것을 확인 할 수 있다.

출처 : http://www.appilogue.kr/2844475

링크 : http://ohgyun.com/402

링크 : http://capzzang.tistory.com/14