걸스인텍: 협업에 반드시 필요한 Git? Github? (1)

걸스인텍과 깃허브에서 진행한 <협업에 반드시 필요한 Git? GitHub?> 세미나를 듣고 내용을 정리하였습니다.

Computational Thinking

• 사전적 정의:복잡한 문제를 효율적으로 다루고 해결하는 사고능력
• 프로그래밍: 그 내용을 바탕으로 step-by-step의 명령 작성

1단계: 문제 분해 (decomposition)

• 문제가 되는 요소가 여러가지가 있을 수 있음
• 예): 웹 서비스 다운
  • 하드웨어 문제
  • 인터넷 문제
  • 코드가 의존성을 가지고 있는 패키지(외부코드, 레고블럭) 문제
  • 최근 코드 변경으로 인한 버그
• 웹 서비스 다운이라는 문제 상황 자체만 보면 해결하기 막막하지만, decomposing을 할 경우 어디부터 어떻게 풀어야 할 지 확인이 된다.

2단계: 패턴 인식(pettern recognition)

• 과거에 대한 정보와 비교해서 같은 패턴이 있는지
• 예) 외부 패키지에서 문제가 생긴 경우가 많았다!

3단계: 추상화(abstraction)

중요한 정보만 보고 중요하지 않은 정보는 노이즈로 간주하고 무시하는 것.

• 예) 외부 패키지의 문제일 경우 아무리 시간과 노력을 들여도 당장은 우리가 해결하지 못한다. 따라서 문제가 발생했을 때 이 문제가 외부 패키지 문제인지, 다른 문제인지 판단하는 것이 가장 중요하다. 나머지 문제 판단은 다음 일이다.
• 외부 패키지 문제인지 판단하는 과정
  • 문제가 발생한 컴포넌트가 사용하는 외부패키지가 무엇인지 확인
  • 외부 패키지 공식 status page 확인
  • 공식 페이지에 확인되지 않는다면, 커뮤니티에 최근 비슷한 문제를 겪는 사람들이 있는지 확인
  • 일전에 known issue가 fix된 이력이 있는지 확인

4단계: 알고리즘 설계(algorithm)

• step by step 명령을 적어 내려가는 단계

git과 GitHub

Git을 사용해야 하는 이유(git이 없다면?)

• 문서와 달리 코드는 사소한 변경에도 프로그램의 작동 여부가 달라짐
• 압축파일(zip)로 버전 관리
• 누가 어떤 부분을 작성했는 지 추적이 불가능
• 과거의 특정 시점의 코드로 돌아갈 수 없음

GitHub의 장점

• 변경사항에 대한 의견을 주고받을 수 있다: 자유로운 토론의 장 형성
• git을 이용해 형상관리를 하기 때문에 어떤 부분이 어떻게 바뀌었는지 쉽게 추적할 수 있다.

Git과 GitHub의 차이점

• git: 형상관리 기술의 일종
  • 컴퓨터 파일의 변경사항을 추적, 여러 명의 사용자들 간에 협업하기 위한 분산 버전 관리 시스템
  • 깃 개발자: 리눅스 토발즈(리눅스 개발자): 리눅스라는 큰 프로젝트를 하다보니 형상관리할 기술이 필요성을 느껴 개발
• github: git을 기반으로 하는 서비스
  • GitHub는 분산 버전 관리 툴인 깃을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스

형상관리 시스템 개발 시 필요 요소

• 어느 단위로 변경된 사항을 저장해야 할지? => commit
• 같은 부분을 다른 사람이 동시에 변경하면 어떻게 처리할 것인지? => conflict
• 개별적인 버전을 관리하고 싶다면 어떻게 처리해야 하는지? => branch
• 개별적인 버전을 최종본에 합치고 싶을 땐 어떻게 해야 하는지? => merge
  • pull request: ‘저 합치고 싶어요~’

Git에서 형상관리를 위해 사용하는 개념 및 용어 정리

• commit: 변경 기록 단위
• conflict:같은 걸 여러명이 작업하다가 충돌
• branch: 각자의 작업 공간
  • master: 뼈대가 되는 브랜치
• Pull Request: 기존에 뼈대가 되는 가지에 합쳐줘
• merge: 마스터브랜치와 합쳐지는 과정

실습

맛있는 라면 만들기 레시피를 형상관리(version control) 해보자!

• README.md: 사용설명서
• repository: 업로드할 공간
• commit: 변경을 기록하는 단위(변경점)
  • 언제든지 과거 시점으로 돌아갈 수 있다.
• commit message: 소스코드는 여러개 버전을 관리하다보면 이 변경사항이 무엇인지 한눈에 파악하기 어렵다. 이를 위해 변경 사항에 대한 메시지를 남긴다.
• collaborator
  • 함께 작업할 사람 추가: ``Settings-> invite collaborater`
  • 초대 메일을 수락하면 추가된다.
  • 레퍼지토리 자체는 public으로 열려 있지만, collaborator 권한으로 더 많은 것을 할 수 있다.
• conflict: has commited since you commited
  • master 브랜치에서 각자 작업을 하다 보면 충돌이 일어난다.
  • => branch를 이용하여 작업하자!
• Branch: 가지
  • master 브런치를 복사해서 만들어지는 작업공간.
  • 각 branch에서 변경한 내용은 master브랜치에 나타나지 않는다.
  • master 브랜치에 합치고 싶으면 Pull Request 한다.
• pull request:당김 요청
  • master, 내 저장소를 당겨와주세요! 반영해주세요!
  • 그러면 master 브랜치 관리자는 변경사항을 확인하고 Comment를 남길 수도 있고, approve를 통해 요청을 승인할 수 있다.
• Insight -> network: branch 확인
• 실제 마스터 브랜치에서 시작했다가 별도 브랜치를 생성해서 작업을 한 다음에 merge할 수 있다.