[교육] Git & GitHub 초급 교육

준비

SourceTree

http://www.sourcetreeapp.com

Sourcetree | Free Git GUI for Mac and Windows

참고영상

NHN Forward 2019

https://forward.nhn.com/2019/seoul/presentation-session

NHN FORWARD

https://www.youtube.com/watch?v=etnFe2tBD5I&feature=youtu.be

실습파일

 

github-example.zip

0.00MB

규칙

Look

슬라이드 내용에 집중합니다.

20191010_파킹클라우드_Git 교육.pptx

3.06MB

D.I.Y

직접 실습합니다.

버전 관리 시스템

버전 관리 시스템 [Look]

• Version Control System; VCS
• 파일의 변화를 시간에 따라 기록하여 과거 특정 시점의 버전으로 다시 불러올 수 있는 시스템
• 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리기
• 시간에 따른 변경 사항을 검토
• 문제가 되는 부분을 누가 마지막으로 수정하였는지 찾기
• 파일을 잃어버리거나 무언가 잘못되어도 대개 쉽게 복구 가능

로컬 버전 관리 시스템 [Look]

• 대부분의 사람들이 버전 관리를 위해 쓰는 방법은 파일을 다른 디렉토리, 다른 이름으로 복사하는 것
• 이 방법은 간단하지만 실수가 발생하기 쉬움
  • 파일을 덮어쓰거나 의도하지 않은 위치로 복사
• 이 문제를 해결하기 위하여 오래전 프로그래머들은 간단한 데이터베이스에 파일의 변경 사항을 기록하는 로컬 버전 관리 시스템을 만듦
  • ex) RCS

중앙집중식 버전 관리 시스템 [Look]

• 여러 개발자들과 함께 작업하려면?
• 중앙집중식 버전 관리 시스템(Centralized Version Control System; CVCS) 탄생
  • ex) CVS, Subversion, Perforce
• 파일을 저장하는 하나의 서버
• 중앙 서버에서 파일을 가져오는 다수의 클라이언트

장점

• 누구나 다른 사람이 무엇을 하고 있는지 알 수 있음
• CVCS를 관리하는 것은 수많은 클라이언의 로컬 데이터베이스를 관리하는 것보다 쉬움

단점

• 중앙 서버가 잘못되면 모든 것이 잘못된다
• 서버가 다운될 경우 다시 복구할 때까지 다른 사람과 협업도 진행 중이던 작업을 버전 관리하는 것도 불가능

분산 버전 관리 시스템 [Look]

• Distributed Version Control System; DVCS
  • Git, Mercurial, Bazaar, Darcs
• 클라이언트가 저장소를 통째로 복사
• 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구됨

Git 기초

Git 역사 [Look]

• 리눅스 커널은 패치 파일와 단순 압축 파일로 관리
• 2002년 BitKeeper라는 상용 DVCS를 사용
• 2005년에 BitKeeper의 무료 사용이 제고됨
• 리눅스 개발 커뮤니티가 자체 도구를 만드는 계기
• 목표
  • 빠른 속도
  • 단순한 구조
  • 비선형적인 개발 (수천 개의 동시 다발적인 브랜치)
  • 완벽한 분산
  • 리눅스 커널 같은 대형 프로젝트에도 유용할 것(속도나 데이터 크기 면에서)
• 2005년 Git 탄생

델타가 아니라 스냅샷 [Look]

Subversion이나 비슷한 VCS

• 각 파일의 변화를 시간순으로 관리

Git

• Git의 데이터는 파일의 스냅샷
• 파일이 달라지지 않으면 이전 버전의 링크만 저장

거의 모든 명령을 로컬에서 실행 [Look]

• 거의 모든 명령이 로컬 파일과 데이터만 사용
• 프로젝트의 모든 히스토리가 로컬 디스크에 있기 때문에 모든 명령을 순식간에 실행
  • ex) 프로젝트의 히스토리를 서버 없이 조회 -> 빠른 조회 가능
• 비행기나 기차 등에서 작업하고 네트워크에 접속하고 있지 않아도 커밋 가능

Git의 무결성 [Look]

• 모든 데이터를 저장하기 전 체크섬(해시)을 구하고 그 체크섬으로 데이터를 관리
• SHA-1 해시 사용
• 40자 길이의 16진수 문자열
  • ex) 24b9da6552252987aa493b52f8696cd6d3b00373
• 파일을 이름으로 저장하지 않고 해당 파일의 해시로 저장

세 가지 상태 [Look]

• Committed
  • 데이터가 로컬 데이터베이스에 안전하게 저장 됨
• Modifed
  • 수정한 파일을 아직 로컬 데이터베이스에 커밋하지 않음
• Staged
  • 수정한 파일을 곧 커밋할 것이라고 표시

• Git으로 하는 기본적인 일
  • 워킹 디렉토리에서 파일을 수정
  • Staging Area에 파일을 Stage해서 커밋할 스냅샷을 만듦
  • Staging Area에 있는 파일들을 커밋해서 Git 디렉토리에 영구적인 스냅샷으로 저장

기초 설정

SourceTree 설치 [D.I.Y]

https://www.sourcetreeapp.com

macOS

• 다운로드한 파일을 실행 후 Move to Applications Folder 클릭
  

  

• 다음 사항에 동의합니다에 체크, 계속 클릭
  

  

• 기존 계정 사용 클릭
  

  

• 로그인 혹은 가입
  

  

• My Atlassian으로 가기 클릭 (오번역 같습니다)
  

  

• 설정 건너뛰기 클릭
  

  

Windows

• 동의합니다에 체크, 계속 클릭
  

  

• 기존 계정 사용 클릭
  

  

• (UI가 좀 깨지지만) 로그인 혹은 가입
  

  

• 계속 클릭
  

  

• 설정 건너뛰기 클릭
  

  

• SSH 키를 불러오시겠습니까?에 No 클릭
  

  

• 단일 SourceTree용 내장 Git를 다운로드 받으세요 클릭 후 git 설치
  

  

• Mercurial을 사용하지 않겠습니다 클릭
  

  

• 실습 노트북에 이미 SourceTree가 설치되어 있으면 이전 사람들의 인증 정보를 지워줍니다.
• [도구] - [옵션] - [인증] 탭의 계정 / 저장된 비밀번호를 모두 지우세요.
  

  

GitHub 가입 [D.I.Y]

• https://github.com/

• 가입

  • 첫 화면에서 바로 가입 가능
  • ID, 이메일, 비밀번호를 입력 후 가입
    

    

• 플랜 선택

  • Unlimited plublic repositories for free 선택
    

    

• 설문은 Submit

• 중요!!

  • 가입 시 입력한 이메일 수신함에서 이메일 유효성 검사를 꼭 하도록 함
    

    

Git 기초 사용법

저장소 생성 [Look]

• GitHub에서 Start a project 클릭

• 혹은 상단 + 기호의 New repository 클릭

  

• Repository name에 calculator 입력

• Initialize this repository with a README 체크

  

저장소 생성 [D.I.Y]

calculator라는 이름의 저장소를 하나 생성하세요
꼭 README 생성에 체크

저장소 복제 [Look]

저장소 주소 복사

• Clone or download 클릭 후 클립보드 아이콘 클릭
  

  

SourceTree에서 저장소 추가

macOS

• 저장소 브라우저의 + 새 저장소 - URL에서 복사

  

• Source URL 입력 후 Tab키 입력하면 나머지 자동으로 입력

• 클론 클릭

  

• 복제 완료

  

Windows

• 메인 윈도우의 Clone 클릭

• 소스 경로 / URL 입력 후 Tab키 입력하면 나머지 자동으로 입력

• 클론 클릭

  

• 복제 완료

저장소 복제 [D.I.Y]

calulator 저장소를 로컬로 복제하세요

사용자 정보 설정 [Look]

Windows

• 처음 설치하면 복제한 직후 사용자 정보 설정 화면이 표시 됨

  

• 이후에는 도구 - 옵션

  

• 기본 사용자 정보에 이름과 이메일 주소 설정

  

macOS

• SourceTree - 설정...

  

• 기본 사용자 정보에 이름과 이메일 주소 설정

  

사용자 정보 설정 [D.I.Y]

사용자 정보를 설정하세요

파일 수정과 상태 변경 [Look]

• 워킹 디렉토리의 파일은 Tracked와 Untracked로 나뉨
• Tracked
  • 이미 스냅샷에 포함
  • Unmodified
  • Modified
  • Staged
• Untracked

파일 수정

• 저장소가 복제된 폴더로 이동하여 README.md 파일을 수정해 봅시다

• macOS

  

• Windows

  

• 파일 내용을 변경하였습니다.

  

• SourceTree의 파일 상태 항목을 보면 README.md 파일이 스테이지에 올라가지 않은 파일에 추가되었고 오른쪽에서는 Diff를 확인할 수 있습니다.

  

   

  

• 파일상태 창이 위/아래로 나눠져 있지 않으면 햄버거 메뉴에서 스테이지 뷰 나누기를 선택합니다.

  • Git 개념과 1:1로 매치되는 뷰 (Staged 상태 / Modified 상태)
    

    

Stage 하기

• 스테이지에 올라가지 않은 파일에 있는 README.md 파일을 체크하면 스테이지에 올라간 파일로 추가됩니다.
  

  

  
  

  

• 이제 커밋을 위한 준비가 완료되었습니다.
  

  

Staged 파일의 수정

• 그런데 아차! '기술교육'을 잊었네요. 파일을 다시 수정하였습니다.

  

• README.md가 스테이지에 올라가지 않은 파일/스테이지에 올라간 파일 양쪽에 모두 있습니다.

  

• Staged 파일을 수정하면 Staged 상태에서 수정된 Unstated 상태가 됩니다.

• 커밋을 위해서는 다시 체크하여 Staged 상태로 변경하여야 합니다.

  

파일 수정과 상태 변경 [D.I.Y]

README.md 파일을 수정하여 커밋 준비를 하세요.

• 한번 수정한 후 Unstage 상태가 되는 것을 확인하세요.
• Stage 상태로 만드세요.
• 다시 수정하여 Stage/Unstage 상태의 차이를 확인하세요.
• 최종적으로 Stage 상태로 만들어 커밋 준비를 하세요.

커밋 [Look]

• 파일 상태 화면의 하단에서 커밋 메시지를 작성하고 커밋 버튼을 클릭해서 커밋할 수 있습니다.

  

• master 브랜치(이후 설명)에 커밋이 추가된 것을 확인할 수 있습니다.

  

커밋 [D.I.Y]

워킹 디렉토리의 변경사항을 커밋하세요.

• 두 번 이상 커밋해 보시기 바랍니다.

.gitignore [Look]

• 빌드 결과물 혹은 임시 파일 등은 굳이 버전관리를 할 필요가 없습니다.

• 이런 파일들은 Stage에 추가하지 않는 식으로 관리할 수도 있겠지만 git이 해당 파일들을 무시하도록 할 수 있습니다.

• .gitingore라는 텍스트 파일을 만들어서 한줄 씩 무시할 파일 이름의 패턴을 적어주면 됩니다.

• https://www.gitignore.io/

  • 주요 운영체제, 언어에 대한 .gitignore 패턴을 자동으로 생성해주는 사이트
    
    

• SourceTree를 이용하여 파일을 무시하는 방법을 알아 봅시다.

• 무시해야할 파일이 있다고 가정하고 파일을 하나 만듭니다.

  

• 해당 파일을 오른쪽 클릭한 후 무시를 선택

  

• 일치하는 파일명 무시

• 현재 저장소에 추가를 선택

  

• 패턴 옵션

  • 일치하는 파일명 무시: 정확히 현재 파일만 무시
  • 이 확장자를 가진 모든 파일 무시: 해당 확장자인 파일 모두 무시
  • 이하 모든 걸 무시: 폴더일 경우 폴더를 포함 하위 파일 모두 무시
  • 커스텀 패턴 무시하기: 직접 파일 패턴을 작성하여 무시

• 무시 항목을 다음에 추가

  • 전역 무시 목록: 현재 컴퓨터의 모든 저장소에 적용되는 설정으로 추가
  • 현재 저장소: 현재 저장소에만 설정 적용

• .gitignore 파일도 하나의 파일로써 버전 관리 대상입니다.

• 스테이지에 올린 후 커밋을 합니다.

이미 버전 관리된 파일을 무시하기 [Look]

• 이미 커밋되어 버전관리가 되는 파일은 이후에 .gitignore에 추가해도 무시되지 않습니다.
• 이 경우 해당 파일을 삭제한 후 커밋하고해야 합니다.
  • 무시할 파일의 경우 저장소에 들어 있지 않아도 빌드 과정에서 다시 만들어지는 파일이므로 삭제해도 무방합니다.

## .gitignore [D.I.Y]

불필요한 파일을 하나 생성한 후 무시하도록 설정해보세요.

• gitignore.io 사이트에서 여러 환경에 대한 .gitignore 파일 내용 복사하기
• .gitignore 파일을 생성하여 붙여넣기
• 불필요한 파일을 하나 생성
• 해당 파일을 무시하도록 설정
• .gitignore파일을 커밋

브랜치 [Look]

• 브랜치를 왜 만들고 사용해야 하는지 알아 봅시다.
• 실제 개발 과정에서 겪을 만한 예제
  1. 작업 중인 웹사이트가 있다.
  2. 새로운 이슈를 처리할 새 브랜치를 하나 생성한다.
  3. 새로 만든 브랜치에서 작업을 진행한다.
• 중요한 문제가 생겨서 해결하는 hotfix를 만들어야 한다면
  1. 새로운 이슈를 처리하기 전의 운영 브랜치로 이동한다.
  2. hotfix 브랜치를 새로 생성한다.
  3. 수정한 hotfix 테스트를 마치고 운영 브랜치로 머지한다.
  4. 다시 작업하던 브랜치로 옮겨가서 하던 일을 진행한다.
• 브랜치란 가상의 작업 공간

Git이 데이터를 저장하는 방법 [Look]

• Git이 브랜치를 어떻게 다루는지 알려면 Git이 데이터를 어떻게 저장하는지 살펴봐야 합니다.

• 커밋을 하면 Git은 커밋 개체를 생성

  

  • 데이터의 스냇샷에 대한 포인터
  • 메타 데이터: 저자, 커밋 메시지 등
  • 이전 커밋에 대한 포인터

• 다시 파일을 수정하고 커밋하면 이전 커밋이 무엇인지도 저장

  

• Git의 브랜치는 커밋을 가리키는 포인터

  

브랜치 생성 [Look]

• SourceTree의 브랜치 클릭

  

• 새 브랜치에 브랜치 이름을 적고 브랜치 생성을 클릭

  

• testing이라는 브랜치가 생성되고 체크아웃(워킹 디렉토리에 반영)된 것을 확인(동그라미 표시)할 수 있습니다.

• testing과 master는 둘다 d317204라는 커밋을 가리키고 있는 것을 확인할 수 있습니다.

  

브랜치 이동 [Look]

• 특정 브랜치로 이동한다는 것은 다른 말로 나의 워킹 디렉토리를 브랜치가 가르키는 커밋의 내용으로 변경한다는 의미입니다.
  • 워킹 디렉토리를 특정 커밋의 내용으로 변경하는 것을 체크아웃한다고 합니다.
• 브랜치를 이동하려면 이동할 브랜치 명의 컨텍스트 메뉴에서 체크아웃을 클릭하거나 간단히 브랜치 명을 더블클릭합니다.
  

  

   

  

브랜치 생성과 이동 [D.I.Y]

브랜치를 생성하고 이동해보세요.

• master 브랜치에서 testing 브랜치를 생성해보세요.
• testing 브랜치가 체크아웃된 상태에서 다시 master 브랜치를 체크아웃해 보세요.

브랜치의 갈라짐 [Look]

• testing 브랜치에서 커밋을 한번해 보겠습니다.

• testing 브랜치는 새로운 커밋 84ed3b8을 가리키지만 master 브랜치는 그대로 있는 것을 확인할 수 있습니다.

  

• master로 체크아웃한 후 커밋을 한번해 보겠습니다.

• 이제는 master와 testing이 갈라졌습니다.

  

머지 [Look]

• 한 브랜치의 내용을 다른 브랜치에 합치는 것을 머지라고 합니다.

• testing 브랜치를 master 브랜치로 머지해 보겠습니다.

• 먼저, master 브랜치를 체크아웃합니다.

  • Git은 항상 변경사항이 발생하는 브랜치로 체크아웃한 후 무엇이든 합니다.
  • 지금은 master 브랜치가 testing 브랜치의 변경사항들을 받아 들이기 때문에 master를 체크아웃합니다.

• testing의 컨텍스트 메뉴에서 Merge testing into master(현재 브랜치로 testing 병합)를 클릭합니다.

  

   

  

• 확인을 클릭합니다.

  

   

  

• master 브랜치에 testing 브랜치의 변경사항을 받은 머지 커밋이 생성되는 것을 확인할 수 있습니다.

• 머지 커밋은 부모 커밋을 두개 가지고 있습니다.

  

브랜치 삭제 [Look]

• 머지된 브랜치를 삭제해 봅시다.

• testing의 컨텍스트 메뉴에서 testing 삭제를 클릭합니다.

  

   

  

• 확인을 클릭합니다.

  

   

  

브랜치에서의 작업 [D.I.Y]

• testing 브랜치에서 커밋을 해보세요.
  • testing 브랜치가 master 브랜치보다 앞서는 것을 확인하세요.
• master 브랜치에서 커밋을 해보세요.
  • master와 testing이 갈라지는 것을 확인해보세요.
  • 주의 충돌이 발생하지 않도록 testing과 master는 서로 다른 파일을 수정하세요. (빈 파일 생성 추천) 충돌 해결법은 뒤에 설명합니다.
• master에 testing을 머지해보세요.
• testing 브랜치를 삭제해보세요.

Fast-forward [Look]

• master에서 testing2 브랜치를 생성하고 커밋을 해봤습니다.

  

• 이 상태에서 master에 testing2를 머지해보겠습니다.

  

  • e8d5bb3 커밋을 master와 testing2가 둘다 가리킵니다.
  • master에 testing2를 머지한다는 건 이 경우 단순히 master가 가리키는 커밋만 변경하면 되기 때문입니다.
  • 이렇게 머지 시에 머지 커밋을 생성하지 않고 브랜치 포인터만 옮기는 것을 fast-forward라고 합니다.

Fast-forward [D.I.Y]

• master로부터 testing2 브랜치를 생성하고 커밋을 해보세요.
• master에 testing2를 머지해보세요.
  • FF로 머지되는 것을 확인하세요.

git-flow [Look]

• 브랜치 관리 모델 중 하나로 Vincent Driessen이 주장

메인 브랜치

• 아래 두 브랜치는 항상 존재하는 메인 브랜치입니다.
  • master
    • master 브랜치는 배포된 소스가 있습니다.
  • develop
    • 다음 배포를 위한 소스가 있습니다.
    • 개발이 완료되면 일련의 과정을 통해 master로 머지합니다.

서포팅 브랜치

• master과 develop 외에 팀 멤버들이 병렬로 일할 수 있도록 도와주는 브랜치가 있습니다.
• 메인 브랜치와는 다르게 필요할 때 생성하였다가 삭제합니다.
  • feature 브랜치
  • release 브랜치
  • hotfix 브랜치

feature 브랜치

• 브랜치 생성: develop으로 부터
• 머지: develop으로
• prefix: feature/
• feature 브랜치는 특정 기능 하나에 대하여 develop으로부터 생성하여 개발하며 개발이 완료되면 다시 develop 브랜치로 머지합니다.
  

  

• 이때 각 기능 별로 개발한 커밋을 구별할 수 있도록 fast-forward를 사용하지 않습니다.
  

  

release 브랜치

• 브랜치 생성: develop으로 부터
• 머지: develop과 master로
• prefix: release/
• release 브랜치는 배포를 위한 준비를 할 수 있는 브랜치입니다.
• release 브랜치는 develop 브랜치에 다음 배포를 위한 기능의 개발이 모두 완료되어 머지된 후 develop으로부터 생성합니다.
• release 브랜치에서는 각종 메타 데이터 (버전 명 등)을 변경하거나 작은 버그를 수정합니다.
• 배포 준비가 완료되면 release 브랜치를 master와 develop에 각각 머지합니다.
• master에는 버전 태그를 붙입니다.
• release 브랜치를 따로 가져가기 때문에 develop 브랜치에서는 바로 다음 배포를 위한 기능 기능을 시작할 수 있습니다.
• 그리고 release 브랜치를 다시 develop으로 머지하기 때문에 release 브랜치의 변경 사항이 develop에 반영됩니다.
  

  

hotfix 브랜치

• 브랜치 생성: master로 부터
• 머지: develop과 master로
• prefix: hotfix/
• hotfix 브랜치는 배포된 버전에 긴급한 변경 사항이 있을 때 활용합니다.
• hotfix 브랜치는 master로부터 생성합니다.
• 긴급한 이슈가 해결되면 다시 master와 develop에 머지합니다.
• hotfix 브랜치 역시 따로 가져가기 때문에 develop 브랜치에서는 다음 배포를 위한 기능 개발을 계속 진행할 수 있습니다.
• hotfix 브랜치를 develop으로 머지하기 때문에 hotfix 브랜치의 변경 사항이 develop에 반영됩니다.
  

  

요약

원격 저장소 (remote) [Look]

• Git은 로컬 저장소만 사용할 수도 있지만 원격 저장소를 추가하여 사용할 수 있습니다.
• 우리가 GitHub의 저장소를 복제했을 때 git은 자동으로 GitHub에 있는 원격 저장소를 origin이라는 이름으로 추가하였습니다.

로컬 브랜치와 원격 브랜치

• 로컬 브랜치인 master와 원격 브랜치인 origin/master는 서로 별개의 브랜치입니다.
• Git이 origin/master를 체크아웃하여 로컬 브랜치인 master를 생성하였습니다.
• A라는 사람의 master와 B라는 사람의 master 또한 별개의 브랜치입니다.
• 이 개념을 이해하면 git에서 헷갈리던 많은 것이 해결됩니다.

Fetch

• 원격 저장소의 변경 사항을 내려 받는 것을 fetch라고 합니다.
• Fetch까지만 하면 변경 사항을 받았을 뿐 아직 로컬 브랜치에는 머지(반영)되지 않은 상태입니다.
• 로컬 브랜치에 원격 저장소의 변경 사항을 반영하고 싶다면 수동으로 원격 브랜치를 로컬 브랜치로 머지해야 합니다.

Pull

• Pull은 fetch + 머지입니다.
• 원격 브랜치의 변경 사항을 내려 받은 후 로컬 브랜치로 머지해줍니다.

Push

• 로컬 저장소의 변경 사항을 원격 저장소로 올리는 것을 push라고 합니다.

요약

• fetch/pull/push는 뒤에서 실제 실습해보도록 하겠습니다.

Git/GitHub/Dooray! Project를 이용한 프로젝트 관리

개요 [D.I.Y]

• 각 팀에서 하나의 저장소를 만들고 Dooray! Project를 통해서 계산기 v1.0을 릴리즈하는 과정을 따라해 보겠습니다.
• 조장을 결정해주세요.

새로운 규칙

조장

조장이 행동하고 조원이 지켜봅니다.

조원

조원이 행동하고 조장이 지켜봅니다.

Look

슬라이드 내용에 집중합니다.

D.I.Y

직접 실습합니다.

---

Git-flow 설정 [조장][Look]

• 저장소는 앞서 생성한 조장의 저장소를 사용하도록 하겠습니다.

• 도구모음에서 깃 플로우...를 클릭

  

• 기본값으로 두고 확인 클릭

  

• develop 브랜치가 생성된 것 확인

  

• 만약 도구모두에 깃 플로우가 보이지 않으면 도구모음 컨텍스트 메뉴에서 도구 막대 사용자화 클릭

  

• 깃 플로우를 도구모음으로 드래그

  

develop 브랜치 push [조장][Look]

• 도구모음에서 푸시 클릭
  

  

• develop에 체크한 후 확인 클릭
  

  

• 아이디와 비밀번호를 물어보면 Github 아이디와 비밀번호를 입력합니다.

기본 브랜치 변경 [조장][Look]

• GitHub의 저장소 페이지로 이동한 후 Settings를 클릭합니다.
• Default branch를 develop으로 선택합니다.
  

  

Git-flow 설정 [조장][D.I.Y]

• Git-flow 설정을 합니다.
• develop 브랜치를 push합니다.
• 기본 브랜치를 develop으로 변경합니다.

협업자 추가 [조장][Look]

• 저장소 페이지의 상단 Settings - 왼쪽 메뉴의 Collaborators 클릭

  

• 조원을 검색하여 추가해 줍니다.

  

협업자 추가 [조장][D.I.Y]

• 조원을 협업자로 추가합니다.
  • Settings - Collaborator
  • 아이디로 검색 후 추가

초대 수락 [조원][Look]

• 조원은 메일로 온 초대를 수락합니다.
  

  

  
  

  

저장소 복제와 git-flow 설정 [조원][Look]

• 각 조원은 조장의 저장소를 복제한 후 git-flow설정까지 완료합니다.
• 이때 git-Flow 초기설정은 develop과 master 브랜치가 모두 로컬에 있어야 가능합니다.
• Remotes-origin의 master를 체크아웃 받습니다.
  • develop은기본 브랜치이기 때문에 복제 시 체크아웃됨
    

    

초대 수락/저장소 복제/git-flow 설정 [조원][D.I.Y]

• 조장의 초대를 수락하고 저장소를 복제합니다.
  • 메일의 링크 클릭
  • 저장소 주소 복사 후 SourceTree에서 복제
• git-flow 초기 설정을 합니다.
  • 이때 develop, master 모두 로컬에 존재하여야 합니다.

Dooray! Project 마일스톤 설정 [Look]

• 프로젝트 설정으로 진입합니다.

  

• 마일스톤 탭의 [마일스톤 추가]를 클릭합니다.

  

• 마일스톤명을 적고 적절한 기간을 선택한 후 [추가]를 클릭합니다.

  

• 마일스톤을 설정하면 프로젝트 대시보드에서 번다운차트를 확인할 수 있습니다.

  

Dooray! Project 마일스톤 설정 [조장][D.I.Y]

• 프로젝트에 계산기 v1.0 마일스톤을 추가합니다.

업무 생성 [Look]

• 새 업무를 클릭

  

• 담당자, 제목, 본문을 적습니다.

• 마일스톤은 계산기 v1.0으로 선택합니다.

  

• 업무 생성 완료

  

• 하단의 댓글 입력창을 통해 댓글을 남길 수 있습니다.

  

   

  

• 나머지 업무 등록

  

업무 생성 [조장][조원][D.I.Y]

• 앞과 같이 업무를 등록하고 댓글을 통해 의견을 나누어 봅니다.

Dooray! Project와 GitHub 연동 [조장][Look]

• Dooray! Project 설정으로 진입합니다.

  

• [서비스 연동] - [서비스 추가] - [GitHub] - [연동 추가]를 클릭합니다.

  

• 연동 프로젝트에서 현재 프로젝트를 선택합니다.

• URL을 복사한 후 저장을 클릭합니다.

  

• GitHub 저장소 [Settings] - [Webhooks] - [Add webhook]을 클릭합니다.

  

• Payload URL에 복사한 URL을 붙여넣기 합니다.

• Content type을 application/josn으로 선택합니다.

• Let me select individual events를 선택합니다.

  

• Push를 해제하고 Pull request를 선택합니다.

  

• Add webhook을 클릭합니다.

  

• Webhook 주소에 초록 체크가 표시되면 정상입니다.

  

기능 개발 시작 [조장][Look]

• 스켈레톤 작성 업무를 시작해 봅시다.

• 이슈 담당자는 업무 진행하기를 클릭합니다.

  

• 도구모음에서 깃 플로우...를 클릭합니다.

• 새 기능 시작을 클릭합니다.

  

• Feature Name은 이슈번호와 간략한 설명으로 정합니다.

  

• feature/iss1-create-skeleton 브랜치가 생성되고 checkout된 것을 확인할 수 있습니다.

  

기능 개발 [조장][Look]

• main.c를생성합니다.

  

• 커밋 로그를 작성하고 커밋합니다.

  

기능 푸시 [조장][Look]

• 푸시할 브랜치를 선택한 후 푸시합니다.
  

  

기능 개발 [조장][D.I.Y]

계산기 프로그램의 스켈레톤을 개발한 후 푸시하세요.

• 깃 플로우 버튼을 통해 새 기능을 시작합니다.
• 실습 파일의 main-1.c 파일 내용을 복사해서 main.c로 저장합니다.
• 커밋 로그를 작성하고 커밋합니다.
• feature 브랜치를 푸시합니다.

Pull Request [조장][Look]

• 기능 개발이 완료된 후에는 깃 플로우 버튼의 기능 마무리를 이용하여 feature 브랜치를 develop으로 머지할 수도 있습니다.
  

  

• 하지만 이렇게 하지 않고 GitHub에서 Pull Request를 생성하는 방법을 알아봅니다.
  • 이런 방식을 GitHub Flow라고 부릅니다.
  • 본 교육에서는 Git Flow와 GitHub Flow를 조합한 workflow를 안내 합니다.

PR 생성 [조장][Look]

• 저장소페이지의 상단 Pull Requests 클릭

• 오른쪽상단의 New pull request 클릭

  

• compare에서 base로머지하는 풀리퀘스트를 만듭니다.

• 우리는 feature/iss1-create-skeleton을 develop으로 머지할 것이기 때문에 그림과 같이 선택합니다.

  

• 다시 Create pull request 버튼을 클릭합니다.

  

• 정보를 입력하고 Create pull request 버튼을 클릭합니다.

  

• 이때 PR 제목에 #{프로젝트 업무 번호}를 적어주면 해당 업무에 PR 정보가 자동으로 댓글로 달립니다.

• 해당 업무와 관련된 코드 변경 사항을 서로 링크시켜 줄 수 있기 때문에 매우 유용합니다.

  

PR 정보 [Look]

• Conversation 탭은 타임라인과 같이 이 PR의 시간 별 경과를 볼 수 있으며 댓글로 논의를 할 수도 있습니다.
  

  

• Commits 탭에서 PR에 포함된 커밋을 볼 수 있습니다.
  

  

• Files changed 탭에서 Diff를 확인할 수 있습니다.
  

  

PR 만들기 [조장][D.I.Y]

• feature 브랜치를 develop에 머지하기 위한 풀리퀘스트를 만드세요.
• base와 compare에 각각 지정하는 브랜치에 유의하세요.

코드리뷰 [Look]

• 변경된 라인에 마우스 오버하면 +아이콘이 나타납니다.

  

• 해당 라인에 댓글을 추가할 수 있습니다.

  

• 이렇게 추가한 댓글은 Conversation 탭에도 표시됩니다.

  

   

  

• 의견을 받았기 때문에 해당 부분에 대한 수정을 시작합니다.

  • 혹은 댓글을 통해 토의합니다.
    

    

• 첫번째 의견에 대한 수정 사항을 커밋합니다.

• 되도록 커밋은 작은 변경 사항들을 자주 하도록 합니다.

  

• 두번째의견에 대해서도 변경 후 커밋합니다.

  

   

  

• 다시 푸시합니다.

  

• 다시 PR 페이지를 확인하면 이전의 댓글은 X 표시되고 푸시한 커밋들이 반영된 것을 확인할 수 있습니다.

• 이 과정을 코드가 머지할 수 있는 수준이 될 때까지 계속 반복합니다.

  

• 머지를 해도 되겠다 판단이 되면 

  

  로 엄지 표시를 입력합니다.

  • 각 팀의 나름의 싸인을 이용하세요
    

    

• 나름의 룰을 정하여 머지 시점을 결정합니다.

  • 예) 모두의 엄지, 과반수의 엄지 등등

PR을 이용한 코드리뷰 [조장][조원][D.I.Y]

풀리퀘스트의diff기능을 이용하여 코드 리뷰를 하고 리뷰 의견을 해결한 후 머지 결정까지진행해보세요.

• 조원은 diff 화면에서 특정 라인에 대한 의견을 작성
• 조장은 전달받은 의견을 토대로 코드를 수정
  • main-2.c 파일을 복사해 main.c 내용을 변경한 후 커밋
  • main-3.c 파일을 복사해 main.c 내용을 변경한 후 커밋
• 조원은 최종적으로 머지해도 좋을지 판단

feature 브랜치 머지 [조장][Look]

• GitHub 상에서 바로 머지를 할 수 있습니다.

• Merge pull request 클릭

  

• Confirm merge 클릭

  

• Delete branch 클릭

  

• 최종 결과

  

• 내 로컬 저장소에는 아직 원격 저장소과 로컬 저장소에 브랜치가 남아 있는 것으로 나옵니다.

  

• 도구모음에서 페치를 클릭합니다.

  

• 원격 서버들의..에 체크한 후 확인 클릭

  

• 원격 저장소의 브랜치 정보가 사라졌습니다.

  

• develop으로 체크아웃한 후 머지된 브랜치를 삭제합니다.

  

• 마지막으로 담당 업무를 완료합니다.

  

feature 브랜치 머지 [조장][조원][D.I.Y]

풀리퀘스트 페이지의 머지 버튼을 이용하여 feature 브랜치를 develop브랜치로 머지하고 로컬의 feature 브랜치 정보를 정리합니다.
조원은 develop의 변경사항을 pull 받습니다

기능 개발 연습 [조장][조원][D.I.Y]

스켈레톤 소스의 각 메소드를 나눠서 개발하고 PR을 생성하여 리뷰를 받고 머지하세요.
주의 충돌은 뒤에 알아봅니다. 충돌이 발생하지 않도록 동일한 라인을 수정하지 마세요.

충돌 [Look]

• 충돌 해결 방법을 알아보기 위해 일부러 충돌을 만들어 봅시다.

• 동일한 커밋으로부터 조장은 conflict1로 feature 브랜치를 생성하고 조원은 conflict2로 feature 브랜치를 생성했다고 가정해봅시다.

• feature/confilict1

  

• feature/confilict2

  

• 두 feature 브랜치의 풀리퀘스트를 생성할 때는 두 풀리퀘스트가 모두 머지 가능하게 표시될 것입니다.

• 하지만, conflict1의 풀리퀘스트를 먼저 머지한 후에 conflict2의 PR 페이지를 보면 자동 머지가 안 되는 것을 확인할 수 있습니다.

  

충돌의 해결 [조원][Look]

• 조원은 develop으로 체크아웃한후 풀 받습니다.
• 다시 feature/conflict2로 체크아웃한 후 develop을 머지합니다.
  

  

• 당연히 충돌이 납니다.
  

  

• 충돌난 파일은 느낌표로 나타납니다.
  

  

• 충돌 영역은 아래와 같이 표시되며 HEAD가 내가 수정한 내용, develop이 해당 브랜치에서 수정한 내용입니다.
  

  

• 충돌 표시를 지우고 적절하게 두 변경사항을 반영하여 수정합니다.
  

  

• 충돌을 해결한 파일은 충돌 해결로 표시합니다.
  • stage에 추가하는 것과 동일
    

    

• 모든 충돌을 해결했으면 커밋/푸시
  

  

• 다시 PR 페이지를 확인하면 자동 머지가 가능합니다.
  

  

충돌의 해결 [조장][조원][D.I.Y]

충돌 상황을 발생시켜 충돌을 해결하는 법을 실습해봅시다.

• 시작하기 전 모두 develop을 pull
• 조장은 conflict1 feature 브랜치를 생성
• 조원은 conflict2 feature 브랜치를 생성
• 앞서 봤던 대로 코드를 수정하고커밋/푸시
• 조장이 먼저 conflict1에 대한 풀리퀘스트를 머지
• 조원의 conflict2 풀리퀘스트가 충돌난 것을 확인
• 조원은 충돌을 해결한 후 다시 머지

릴리즈 생성 [조원][Look]

• 릴리즈 준비가 되면 git flow로 릴리즈 브랜치를 생성합니다.
• Git flow 버튼에서 새 릴리즈 시작 클릭
  

  

• 적당한 이름으로 릴리즈 브랜치를 생성합니다.
  

  

• 이 릴리즈 브랜치를 이용하여 최종 테스트를 거치며 릴리즈할 수 있는지 검증합니다.
• 최종적으로 버전 등 메타 정보를 수정하여 커밋합니다.
  

  

• 릴리즈 브랜치에 대한 검증이 완료되었다면 Git Flow의 릴리즈 마무리를 클릭합니다.
  

  

• 릴리즈를 완료하면 릴리즈 브랜치가 develop과 master에 머지되고 tag가 생성됩니다.
  

  

• 그 후 develop과 master, tag까지 푸시해 줍니다.
  

  

릴리즈 생성 [조원][D.I.Y]

릴리즈를 생성해 봅니다.

• 릴리즈브랜치를 생성
• 릴리즈를 완료
• 결과를푸시

정리

• 버전 관리 시스템
• Git 기초
• 저장소 생성, 복제, 파일 상태 변경, 커밋
• 브랜치 관리
• Git-flow
• GitHub 협업자 설정
• 기능의 개발, GitHub flow
• Pull Request를 이용한 코드 리뷰
• 충돌 해결
• 릴리즈 생성