1.Git

Git

• 지금은 워낙 많이 쓰이기도 하고
• opensource랑 엮여서 없으면 안되기도하고
• 쓰다보니 편하기도하고 좋고
• 자체에 대한 설명은 찾으면 쉽게 나오니 따로 안쓸생각인데 생각이 바뀌면 이 줄이 지워지고 항목이 추가되겠지..
• 일단은 내가 이걸 왜썼는지, 쓰면서의 그 과정을 정리하고 그간 다른 수업받으면서 썼던 수업자료좀 첨가하고 다른 좋은 자료들있으면 스까쓸생각.

시작은

• 이런 소스 관리해주는 것들을 VC 또는 VCS라 하는데 무튼 그런걸 처음부터 쓰고 있던건 아님. 그런게 있는지 알지도 못했고.. 지금도 몇몇 이름만 들어봤지 까보지도 않음
• 별 그지같은 상황이 많이 생김
  1. 수정사항이 짤짤이로 많이 생길때 근데 그 짤짤이가 한번에 들어오는게 아니라 시간마다, 날마다 들어옴 도트뎀이 상당히 귀찮음
  2. 이미 굴러가고있는애를 테스트 하려고 바꾸기가 좀 부담스러움 또는 해봐야 또 복사본만들어 하는건데 이게 좀 심해져서 실제 도는거 보다 이후 버전이 많아지면 ㄹㅇ 헷깔림.
  3. 위 사항때문에 복사본이 많이 생긴다해도, 일단은 한곳에 모아두고 한꺼번에 관리하고 싶었는데 집이나 회사나 같이보려면 서버가 있던지 클라우드를 쓰던지해야함.
     • 그래서 외장하드랑 nas를 생각했는데 nas가 illamatic의 영향으로 이제 좀더 마음이 기울었고 그 외 방법이 있나 이런거 저런거 알아보는 중에 usb에 일단 임시로 갖고 다녔는데…
     • 특별하게 일이 많은게 아니면 usb를 꽂고 콤퓨타는 켜놓고 다녔는데 어느날 누전으로 콤퓨타가 꺼지면서 usb 내용이 날아감. 다행이 복구 프로그램으로 살리긴했는데 이날 맨탈이 형태없이 박살나고 결심함 ‘분명 소스 관리해주는 무언가 있을것이다. 찾아보자’ 하고.
• 위처럼 불편한 점이 있었는데 vcs존재 자체를 모르기도 했고 그당시 주변에서는 쓰는사람이 없었거나 써봤는데 그냥 복사해 관리하는게 편하다고 하고 중구난방이었음.
• 확실한건 위와 같은 난리가 나기전에 피난처거 확실히 있어야 했고 이 전까지의 방법은 그 피난처가 절대 아닌건 확실했음.

PTSD

• 간단해 보이고 해결하기 쉬워보이는 위 사례들을 좀 더 보자.

• 

  • 지속적인 수정이 이루어 지는 경우
    • 보면 23일 전까지의 수정사항들은 직접 프로젝트 열어보기전까지는 모름.
    • 23일부터는 프로젝트 이름에 직접 쓰는방식인데 이게 가장 최고로 좋은 최악의 예를 우연히 본게 있는데
      • 
      • 이게 실존하더라…심지어 이게 ‘경로’가 아니라 그냥 폴더 하나 이름임.
    • 그래서 그날의 수정사항들은 txt같은 파일 만들어 거기 적어놓고 다음에 열때 확인하던가 함…
      프로젝트 일일이 열어서 확인하는시간만 줄어들지 해결책은 아님.
    • 전체 프로젝트의 크기가 얼마나 되나 다른건 잘 본적이 없어서 모르겠는데 위와 같이 계속 복사하는식이라면 용량을 무한정 잡아먹게됨 한줄 수정에도 하나의 복사본이 생기는데 이건 극한의 효율을 뿜어내는것같음 또, 수정사항을 따로 적은 파일을 각각 적었다는것도 문제였던것이 예를들어 언젠가 reconnect method를 만들었던 날의 버전을 찾고싶다 위의 예시는 몇일 없는데 이미 4-5개월 지난뒤라면..
  • 서로 다른 수정사항들을 원본에 합쳐야 하는 경우
    • 위의 예시처럼 23일 원본버전이 이미 돌고있고 그 뒤수정사항들이 생겨 테스트버전이 있다 가정함(net, log 수정)
      역시 24일에도 수정사항이 있었고
      심지어 25일에는 interface변경으로 25일꺼로 다 합쳐 다시 배포해야하는 상황이라면
      23일 원본에 log 모듈수정, net 모듈수정 한걸 합치고 그걸 24일에 합치고 거기에 25일 수정사항을 합쳐야 한다.
      그럼 아마 ‘25_통합’ 요딴거 하나 더 생길것임.
  • 접근성
    • 일단, 위 프로젝트를 다른 사람들과 공유하려면 공용서버에 올리던가 클라우드에 올리고 공유하던가… 문제는 또 위처럼 계속 복사하면 클라우드 용량도 쓸데없이 계속 잡아먹음.
    • 근데 서버건 클라우드건 생각보다 저 자잘한 수정사항들을 항시 올리기 너무 귀찮던가 의미가 없게 느껴짐. 자동업로드? 행복해질까?
  • 공동작업
    • 프로젝트 자체 공유야 그냥 좀 귀찮다라고 하면 그만인데 이건좀 문제가 커짐.
    • 위 모든 사례들이 혼자하는거면 그나마 이성적인 선에서 제어가 가능함. 근데 공동으로하면 행복회로가 다 타버림.
    • 공동으로 작업하는경우 위 사진에서 log는 A가, net는 B가 수정했다치자.
      이걸 A건 B건 다시 합쳐야 할꺼아님? 그럼 번경사항을 다 찾아가며 합쳐야함 winmerge같은거로 비교해가면서..
• 아무리 봐도 아무리 생각해봐도 행복회로 태워봐도 안쓰는게 이상함.
• 아무튼 중요한건 git은 이런 문제를 다 해결해준다. 세상은 아직 살만하다.

둥지

• 그래서 그런 툴이 없나 찾아보기 시작했는데 그 중 나온게 git이었음
  • 여러개 더 있어서 비교글, 나온이유 등등 그런걸 좀 찾아봤는데 git이 탄생 이유도 그런고 만든분도 그렇고 어마어마해보여서 이거다 함.
  • 써보려니 github가 많이보여 봤는데 대학때 탱크 게임 만들려고 이리저리 소스 찾아봤던게 여기서 봤던거더라..
  • 그니까 이미 오픈소스나 git의 맛은 보고 있었던거임 그게 포장지 맛이어서 그렇지.
• 보통 이런 일들을 몸소 겪기 전에 사람들은 다들 쓰고있더라 나도 기를쓰고 이거에 좀 익숙해지려는게 다시는 위와같은 상황들을 마주치기 싫어서.
• 근데 github는 내가 찾아볼 당시만해도 ms에 인수되기 전이었고 모든 repo는 public일때 무제한 업로드 가능이었나 그랬을꺼임… 살짝 고민을 했던게 떠다니는 설명상으론 git이라는게 참 좋은것같긴한데 막상 써본적도없고 일단 지르자니 자주 안쓰거나 다른 더 좋은 대안이 있으면 어쩌나 싶기도하고.
• 더 큰건 사실 회사 소스를 public으로 올리는것도 문제였고.
• 근데 gitlab는 똑같은데 private project도 무료임 일단 써보고 좋으면 다들 많이쓰는 github로 옮기던가 해볼생각으로 여길 거점으로 잡음.
• 지금 이걸 쓰고있는 날 기준으로 둘은 거의 다른점이 없음 gist도 gitlab에 snipet로 있었고 지금 쓰고있는 github pages도 gitlab pages로 같은 서비스가 있다한다. 뭘 쓰던 다 같아서 편한걸 쓰면 되는것같은데 나는 지금 쓰다보니 private project는 다 gitlab에 가있고 github에는 public만 올라갈듯?
  • 사실 다른점이 있다면 gitlab가 사이트 반응이 좀 느림 외국섭으로 겜할때 살짝 밀리는 딱 그느낌.

참고

• 읽어볼만한 것들임.
• 깃 (소프트웨어)
• 오픈소스의 승리
• git
  • Book
• opentutorials GIT